From: Theodore Ts'o <tytso@mit.edu>
To: Jan Kara <jack@suse.cz>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>,
stable@vger.kernel.org
Subject: Re: [PATCH] ext4: block direct I/O writes during ext4_truncate
Date: Tue, 16 Jul 2013 12:49:42 -0400 [thread overview]
Message-ID: <20130716164942.GA6002@thunk.org> (raw)
In-Reply-To: <20130716154658.GE25632@quack.suse.cz>
On Tue, Jul 16, 2013 at 05:46:58PM +0200, Jan Kara wrote:
> and ext4_setattr() does (again under i_mutex):
> ext4_inode_block_unlocked_dio(inode);
> inode_dio_wait(inode);
> ext4_inode_resume_unlocked_dio(inode);
Ah, I missed this; thanks for pointing this out.
> So either DIO gets i_mutex first and then ext4_setattr() waits for it to
> complete, or truncate completes before unlocked DIO is able to get & drop
> i_mutex.
>
> OTOH unlocked DIO *read* might be vulnerable to a race with truncate. That
> never acquires i_mutex so if the DIO read arrives after ext4_setattr() goes
> through inode_dio_wait(), we can have the read and truncate racing and read
> possibly submitting read of a just truncated block (which can get
> reallocated in theory while the IO is running).
>
> So something like what you do in the patch is likely needed, just the
> justification is somewhat different and you should also rip out / adjust
> the other synchronizations we have in ext4_setattr(), ext4_ext_direct_IO()
> and ext4_ind_direct_IO().
Ok, I'll drop my current patch for now, and revisit this when I have a
bit more time. I agree with your analysis, but fortunately it sounds
like this race is going to be pretty hard to hit in practice ---
especially, since with the journal enabled, we won't allow the block
to get reused until the next commit boundary. The situation where we
would need to worry would be dioread_nolock combined with no journal
mode.
- Ted
next prev parent reply other threads:[~2013-07-16 16:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-15 4:11 [PATCH] ext4: block direct I/O writes during ext4_truncate Theodore Ts'o
2013-07-16 15:46 ` Jan Kara
2013-07-16 16:49 ` Theodore Ts'o [this message]
2013-07-17 18:27 ` Theodore Ts'o
2013-07-18 14:11 ` 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=20130716164942.GA6002@thunk.org \
--to=tytso@mit.edu \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=stable@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.