From: "Jan Beulich" <JBeulich@suse.com>
To: Jan Kara <jack@suse.cz>
Cc: Dave Chinner <david@fromorbit.com>,
linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] mm: Improve comment before pagecache_isize_extended()
Date: Tue, 04 Nov 2014 16:20:08 +0000 [thread overview]
Message-ID: <54590AC80200007800044E95@mail.emea.novell.com> (raw)
In-Reply-To: <20141104153343.GA21902@quack.suse.cz>
>>> On 04.11.14 at 16:33, <jack@suse.cz> wrote:
> On Tue 04-11-14 12:20:26, Jan Beulich wrote:
>> >>> On 04.11.14 at 12:43, <"jack@suse.cz".non-mime.internet> wrote:
>> > --- a/mm/truncate.c
>> > +++ b/mm/truncate.c
>> > @@ -743,10 +743,13 @@ EXPORT_SYMBOL(truncate_setsize);
>> > * changed.
>> > *
>> > * The function must be called after i_size is updated so that page fault
>> > - * coming after we unlock the page will already see the new i_size.
>> > - * The function must be called while we still hold i_mutex - this not only
>> > - * makes sure i_size is stable but also that userspace cannot observe new
>> > - * i_size value before we are prepared to store mmap writes at new inode
> size.
>> > + * coming after we unlock the page will already see the new i_size. The
> caller
>> > + * must make sure (generally by holding i_mutex but e.g. XFS uses its
> private
>> > + * lock) i_size cannot change from the new value while we are called. It
> must
>> > + * also make sure userspace cannot observe new i_size value before we are
>> > + * prepared to store mmap writes upto new inode size (otherwise userspace
> could
>> > + * think it stored data via mmap within i_size but they would get zeroed
> due to
>> > + * writeback & reclaim because they have no backing blocks).
>> > */
>> > void pagecache_isize_extended(struct inode *inode, loff_t from, loff_t to)
>> > {
>>
>> May I suggest that the comment preceding truncate_setsize() also be
>> updated/removed?
> But that comment is actually still true AFAICT because VFS takes i_mutex
> before calling into ->setattr(). So we hold i_mutex in truncate_setsize()
> even for XFS.
I doubt that, especially in the light of the WARN_ON() that
prompted all this:
[<ffffffff810053fa>] dump_trace+0x7a/0x350
[<ffffffff810050de>] show_stack_log_lvl+0xee/0x150
[<ffffffff810064fc>] show_stack+0x1c/0x50
[<ffffffff8138e4e3>] dump_stack+0x68/0x7d
[<ffffffff81042c82>] warn_slowpath_common+0x82/0xb0
[<ffffffff810d3831>] pagecache_isize_extended+0x121/0x130
[<ffffffff810d4689>] truncate_setsize+0x29/0x50
[<ffffffffa056705f>] xfs_setattr_size+0x12f/0x440 [xfs]
[<ffffffffa055cbf7>] xfs_file_fallocate+0x297/0x310 [xfs]
[<ffffffff81111b59>] do_fallocate+0x169/0x190
[<ffffffff8111206e>] SyS_fallocate+0x4e/0x90
[<ffffffff81392712>] system_call_fastpath+0x12/0x17
[<00007f0e6bdddf45>] 0x7f0e6bdddf45
I.e. truncate_setsize() is being called here without the mutex
held (or else the WARN_ON() wouldn't have got triggered in
the first place).
Jan
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2014-11-04 16:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-04 11:43 Jan Kara
2014-11-04 12:20 ` Jan Beulich
2014-11-04 15:33 ` Jan Kara
2014-11-04 16:20 ` Jan Beulich [this message]
2014-11-04 19:37 ` Jan Kara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54590AC80200007800044E95@mail.emea.novell.com \
--to=jbeulich@suse.com \
--cc=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox