All of lore.kernel.org
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Jan Kara <jack@suse.cz>
Cc: linux-ext4@vger.kernel.org, Weller.Huang@cn.bosch.com,
	stable@vger.kernel.org
Subject: Re: [PATCH 1/4] ext4: Fix data exposure after a crash
Date: Sat, 23 Apr 2016 23:48:13 -0400	[thread overview]
Message-ID: <20160424034813.GG20980@thunk.org> (raw)
In-Reply-To: <1459354767-8693-2-git-send-email-jack@suse.cz>

On Wed, Mar 30, 2016 at 06:19:24PM +0200, Jan Kara wrote:
> Huang has reported that in his powerfail testing he is seeing stale
> block contents in some of recently allocated blocks although he mounts
> ext4 in data=ordered mode. After some investigation I have found out
> that indeed when delayed allocation is used, we don't add inode to
> transaction's list of inodes needing flushing before commit. Originally
> we were doing that but commit f3b59291a69d removed the logic with a
> flawed argument that it is not needed.
> 
> The problem is that although for delayed allocated blocks we write their
> contents immediately after allocating them, there is no guarantee that
> the IO scheduler or device doesn't reorder things and thus transaction
> allocating blocks and attaching them to inode can reach stable storage
> before actual block contents. Actually whenever we attach freshly
> allocated blocks to inode using a written extent, we should add inode to
> transaction's ordered inode list to make sure we properly wait for block
> contents to be written before committing the transaction. So that is
> what we do in this patch. This also handles other cases where stale data
> exposure was possible - like filling hole via mmap in
> data=ordered,nodelalloc mode.
> 
> The only exception to the above rule are extending direct IO writes where
> blkdev_direct_IO() waits for IO to complete before increasing i_size and
> thus stale data exposure is not possible. For now we don't complicate
> the code with optimizing this special case since the overhead is pretty
> low. In case this is observed to be a performance problem we can always
> handle it using a special flag to ext4_map_blocks().
> 
> CC: stable@vger.kernel.org
> Fixes: f3b59291a69d0b734be1fc8be489fef2dd846d3d
> Reported-by: "HUANG Weller (CM/ESW12-CN)" <Weller.Huang@cn.bosch.com>
> Tested-by: "HUANG Weller (CM/ESW12-CN)" <Weller.Huang@cn.bosch.com>
> Signed-off-by: Jan Kara <jack@suse.cz>

Applied, thanks.

						- Ted

  reply	other threads:[~2016-04-24  3:48 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-30 16:19 [PATCH 0/4 v2] ext4: Fix data exposure after a crash Jan Kara
2016-03-30 16:19 ` [PATCH 1/4] " Jan Kara
2016-03-30 16:19   ` Jan Kara
2016-04-24  3:48   ` Theodore Ts'o [this message]
2016-04-24  4:55     ` Theodore Ts'o
2016-04-25 10:24       ` Jan Kara
2016-03-30 16:19 ` [PATCH 2/4] ext4: Remove EXT4_STATE_ORDERED_MODE Jan Kara
2016-04-24  3:48   ` Theodore Ts'o
2016-03-30 16:19 ` [PATCH 3/4] jbd2: Add support for avoiding data writes during transaction commits Jan Kara
2016-03-30 16:19 ` [PATCH 4/4] ext4: Do not ask jbd2 to write data for delalloc buffers Jan Kara
2016-04-13 13:32 ` [PATCH 0/4 v2] ext4: Fix data exposure after a crash 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=20160424034813.GG20980@thunk.org \
    --to=tytso@mit.edu \
    --cc=Weller.Huang@cn.bosch.com \
    --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.