From: "Verma, Vishal L" <vishal.l.verma@intel.com>
To: "ross.zwisler@linux.intel.com" <ross.zwisler@linux.intel.com>,
"jack@suse.cz" <jack@suse.cz>
Cc: "linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
"Williams, Dan J" <dan.j.williams@intel.com>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
"tytso@mit.edu" <tytso@mit.edu>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 3/7] ext2: Avoid DAX zeroing to corrupt data
Date: Tue, 17 May 2016 06:52:47 +0000 [thread overview]
Message-ID: <1463467967.3069.3.camel@intel.com> (raw)
In-Reply-To: <20160516152206.GC21714@quack2.suse.cz>
On Mon, 2016-05-16 at 17:22 +0200, Jan Kara wrote:
> On Thu 12-05-16 12:45:22, Ross Zwisler wrote:
> >
> > On Wed, May 11, 2016 at 11:58:49AM +0200, Jan Kara wrote:
> > >
> > > Currently ext2 zeroes any data blocks allocated for DAX inode
> > > however it
> > > still returns them as BH_New. Thus DAX code zeroes them again in
> > > dax_insert_mapping() which can possibly overwrite the data that
> > > has been
> > > already stored to those blocks by a racing dax_io(). Avoid
> > > marking
> > > pre-zeroed buffers as new.
> > >
> > > Reviewed-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> > > Signed-off-by: Jan Kara <jack@suse.cz>
> > > ---
> > > fs/ext2/inode.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/fs/ext2/inode.c b/fs/ext2/inode.c
> > > index 6bd58e6ff038..1f07b758b968 100644
> > > --- a/fs/ext2/inode.c
> > > +++ b/fs/ext2/inode.c
> > > @@ -745,11 +745,11 @@ static int ext2_get_blocks(struct inode
> > > *inode,
> > > mutex_unlock(&ei->truncate_mutex);
> > > goto cleanup;
> > > }
> > > - }
> > > + } else
> > > + set_buffer_new(bh_result);
> > >
> > > ext2_splice_branch(inode, iblock, partial,
> > > indirect_blks, count);
> > > mutex_unlock(&ei->truncate_mutex);
> > > - set_buffer_new(bh_result);
> > > got_it:
> > > map_bh(bh_result, inode->i_sb, le32_to_cpu(chain[depth-
> > > 1].key));
> > > if (count > blocks_to_boundary)
> > > --
> > > 2.6.6
> > Interestingly this change is causing a bunch of xfstests
> > regressions for me
> > with ext2 + DAX. All of these tests pass without this one change.
> Good catch. Attached patch fixes this issue for me. Preferably it
> should be
> merged before the above ext2 change.
>
> Honza
Hey Jan,
In my patch 3 of the error handling series, I have:
- err = dax_clear_sectors(inode->i_sb->s_bdev,
- le32_to_cpu(chain[depth-1].key) <<
- (inode->i_blkbits - 9),
- 1 << inode->i_blkbits);
+ err = sb_issue_zeroout(inode->i_sb,
+ le32_to_cpu(chain[depth-1].key), 1, GFP_NOFS);
Does this mean I have to change to send the sb_issue_zeroout for
'count' blocks.. i.e.
- err = dax_clear_sectors(inode->i_sb->s_bdev,
- le32_to_cpu(chain[depth-1].key) <<
- (inode->i_blkbits - 9),
- 1 << inode->i_blkbits);
+ err = sb_issue_zeroout(inode->i_sb,
+ le32_to_cpu(chain[depth-1].key), count, GFP_NOFS);
If so, I'll update my series tomorrow to include in both of these changes.
Thanks,
-Vishal
next prev parent reply other threads:[~2016-05-17 6:52 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-11 9:58 [PATCH 0/7 v4] DAX cleanups and fixes Jan Kara
2016-05-11 9:58 ` [PATCH 1/7] DAX: move RADIX_DAX_ definitions to dax.c Jan Kara
2016-05-11 9:58 ` [PATCH 2/7] dax: Remove complete_unwritten argument Jan Kara
2016-05-11 9:58 ` [PATCH 3/7] ext2: Avoid DAX zeroing to corrupt data Jan Kara
2016-05-12 18:45 ` Ross Zwisler
2016-05-16 15:22 ` Jan Kara
2016-05-17 6:52 ` Verma, Vishal L [this message]
2016-05-17 7:19 ` Jan Kara
2016-05-17 17:56 ` Verma, Vishal L
2016-05-11 9:58 ` [PATCH 4/7] dax: Remove dead zeroing code from fault handlers Jan Kara
2016-05-11 9:58 ` [PATCH 5/7] dax: Remove zeroing from dax_io() Jan Kara
2016-05-11 9:58 ` [PATCH 6/7] dax: Remove pointless writeback from dax_do_io() Jan Kara
2016-05-11 9:58 ` [PATCH 7/7] dax: Remove redundant inode size checks 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=1463467967.3069.3.camel@intel.com \
--to=vishal.l.verma@intel.com \
--cc=dan.j.williams@intel.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=ross.zwisler@linux.intel.com \
--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