public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Dmitry Monakhov <dmonakhov@openvz.org>
Cc: linux-ext4@vger.kernel.org, jack@suse.cz, tytso@mit.edu
Subject: Re: [PATCH] ext4: fix race aio-dio vs freeze_fs
Date: Tue, 24 Nov 2015 14:31:46 +0100	[thread overview]
Message-ID: <20151124133146.GH25232@quack.suse.cz> (raw)
In-Reply-To: <87a8q4k6xn.fsf@openvz.org>

On Mon 23-11-15 19:37:56, Dmitry Monakhov wrote:
> Dmitry Monakhov <dmonakhov@openvz.org> writes:
> 
> > After freeze_fs was revoked (from Jan Kara) pages's write-back completion
> > is deffered before unwritten conversion, so explicit flush_unwritten_io()
> > was removed here: c724585b62411
> > But we still may face deferred conversion for aio-dio case
> > # Trivial testcase
> > for ((i=0;i<60;i++));do fsfreeze -f /mnt ;sleep 1;fsfreeze -u /mnt;done &
> > fio --bs=4k --ioengine=libaio --iodepth=128 --size=1g --direct=1 \
> >     --runtime=60 --filename=/mnt/file --name=rand-write --rw=randwrite
> > NOTE: Sane testcase should be integrated to xfstests, but it requires
> > changes in common/* code, so let's use this this test at the moment.
> >
> > In order to fix this race we have to guard journal transaction with explicit
> > sb_{start,end}_intwrite()  as we do with ext4_evict_inode here:8e8ad8a5
> Fairly to say I'm not very happy with the fix because it continues bad
> practice of ad-hock fixes for generic journal vs freeze synchronization
> 
> Ideal fix would be to move sb_start_intwrite/sb_end_intwrite() to
> ext4_journal_start()/ext4_journal_stop() but this is not possible due to
> limitations introduced by nojournal mode (described here:8e8ad8a5)
> So let's fix nojournal instead. In order to do that we somehow have
> store ref_count and pointer to sb inside nojournal_handle.
> There are two possible ways to do that.
> 1) Embed second journal related field to task_struct and guard it with
>    compile macros definition.
> void *journal_info;
> + #ifdef CONFIG_EXTRA_JOURNAL_INFO
> +   void *journal_info2;
> + #endif
> 
> 2) Encode ref and sb in to single long. This can be done by aligning
>    ext4_sb_info pointer to 4096. So we can embed ref count to lower bits
>    like follows.
> #define EXT4_NOJOURNAL_SHIFT 12
> #define EXT4_NOJOURNAL_MAX_REF_COUNT 1 << (EXT4_NOJOURNAL_SHIFT-1)
> #define EXT4_NOJOURNAL_MASK  (1 << EXT4_NOJOURNAL_SHIFT) -1
> #define NOJOURNAL_SB(handle) (handle & ~EXT4_NOJOURNAL_MASK)
> #define NOJOURNAL_REF(handle) ((handle & ~EXT4_NOJOURNAL_MASK) >> 1)
> static int ext4_handle_valid(handle_t *handle)
> {
>         return !(handle & 0x1);
> }
> static handle_t *get_nojournal_handle(struct super_block *sb)
> {
>         handle_t *handle = current->journal_info;
>         struct super_block *old_sb  = NOJOURNAL_SB(handle);
>         unsigned long ref_cnt = NOJOURNAL_REF(handle);
>         BUG_ON(old_sb && old_sb != sb);
>         ref++;
>         current->journal_info = NOJOURNAL_SB(handle);
> }
> 
> What do you think about this? Are where any better way to fix this?

Well, we do have:

WARN_ON(sb->s_writers.frozen == SB_FREEZE_COMPLETE);

in ext4_journal_check_start() so we should get a warning for each
unexpected transaction started on frozen filesystem. The idea really is
there should be no write activity happening on frozen fs and the few cases
like MMP are handled by explicit sb_start_intwrite() calls. I'd prefer to
keep those cases special and don't add general freeze protection in
transaction handling code since that may only result in deadlocks instead
of the warning when starting transaction in unexpectected places...

								Honza

-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

  reply	other threads:[~2015-11-24 13:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-23 16:02 [PATCH] ext4: fix race aio-dio vs freeze_fs Dmitry Monakhov
2015-11-23 16:37 ` Dmitry Monakhov
2015-11-24 13:31   ` Jan Kara [this message]
2015-11-24 13:24 ` Jan Kara
2015-11-24 16:07   ` Christoph Hellwig
2015-11-25 10:25     ` Jan Kara
2015-11-24 16:55   ` Dmitry Monakhov
2015-11-25  9:19     ` 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=20151124133146.GH25232@quack.suse.cz \
    --to=jack@suse.cz \
    --cc=dmonakhov@openvz.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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