All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sahitya Tummala <stummala@codeaurora.org>
To: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [PATCH] f2fs: fix data corruption issue with hardware encryption
Date: Thu, 11 Oct 2018 09:15:09 +0530	[thread overview]
Message-ID: <20181011034509.GB24669@codeaurora.org> (raw)
In-Reply-To: <20181011030544.GA82403@jaegeuk-macbookpro.roam.corp.google.com>

On Wed, Oct 10, 2018 at 08:05:44PM -0700, Jaegeuk Kim wrote:
> On 10/10, Jaegeuk Kim wrote:
> > On 10/11, Sahitya Tummala wrote:
> > > On Wed, Oct 10, 2018 at 02:34:02PM -0700, Jaegeuk Kim wrote:
> > > > On 10/10, Sahitya Tummala wrote:
> > > > > Direct IO can be used in case of hardware encryption. The following
> > > > > scenario results into data corruption issue in this path -
> > > > > 
> > > > > Thread A -                          Thread B-
> > > > > -> write file#1 in direct IO
> > > > >                                     -> GC gets kicked in
> > > > >                                     -> GC submitted bio on meta mapping
> > > > > 				       for file#1, but pending completion
> > > > > -> write file#1 again with new data
> > > > >    in direct IO
> > > > >                                     -> GC bio gets completed now
> > > > >                                     -> GC writes old data to the new
> > > > >                                        location and thus file#1 is
> > > > > 				       corrupted.
> > > > > 
> > > > > Fix this by submitting and waiting for pending io on meta mapping
> > > > > for direct IO case in f2fs_map_blocks().
> > > > > 
> > > > > Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
> > > > > ---
> > > > >  fs/f2fs/data.c | 12 ++++++++++++
> > > > >  1 file changed, 12 insertions(+)
> > > > > 
> > > > > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> > > > > index 9ef6f1f..7b2fef0 100644
> > > > > --- a/fs/f2fs/data.c
> > > > > +++ b/fs/f2fs/data.c
> > > > > @@ -1028,6 +1028,12 @@ int f2fs_map_blocks(struct inode *inode, struct f2fs_map_blocks *map,
> > > > >  		map->m_pblk = ei.blk + pgofs - ei.fofs;
> > > > >  		map->m_len = min((pgoff_t)maxblocks, ei.fofs + ei.len - pgofs);
> > > > >  		map->m_flags = F2FS_MAP_MAPPED;
> > > > > +		/* for HW encryption, but to avoid potential issue in future */
> > > > > +		if (flag == F2FS_GET_BLOCK_DIO) {
> > > > > +			blkaddr = map->m_pblk;
> > > > > +			for (; blkaddr < map->m_pblk + map->m_len; blkaddr++)
> > > > > +				f2fs_wait_on_block_writeback(sbi, blkaddr);
> > > > 
> > > > Do we need this? IIRC, DIO would give create=1.
> > > 
> > > Yes, we need it. When we are overwriting an existing file, DIO calls
> > > f2fs_map_blocks() with create=0. From the DIO code, I see that this happens
> > > because blockdev_direct_IO() passes this dio flag DIO_SKIP_HOLES. And then
> > > in get_more_blocks(), below code updates create=0, when we are overwriting
> > > an existing file.
> > > 
> > >                 create = dio->op == REQ_OP_WRITE;
> > >                 if (dio->flags & DIO_SKIP_HOLES) {
> > >                         if (fs_startblk <= ((i_size_read(dio->inode) - 1) >>
> > >                                                         i_blkbits))
> > >                                 create = 0;
> > >                 }
> > > 
> > >                 ret = (*sdio->get_block)(dio->inode, fs_startblk,
> > >                                                 map_bh, create);
> > > 
> > 
> > Got it.
> > How about this?
> > 
> 
> Sorry, this is v2.

Looks good to me. Thanks for updating it :)

> 
> From b78dd7b2e0317be18716b9496269e9792829f63e Mon Sep 17 00:00:00 2001
> From: Sahitya Tummala <stummala@codeaurora.org>
> Date: Wed, 10 Oct 2018 10:56:22 +0530
> Subject: [PATCH] f2fs: fix data corruption issue with hardware encryption
> 
> Direct IO can be used in case of hardware encryption. The following
> scenario results into data corruption issue in this path -
> 
> Thread A -                          Thread B-
> -> write file#1 in direct IO
>                                     -> GC gets kicked in
>                                     -> GC submitted bio on meta mapping
> 				       for file#1, but pending completion
> -> write file#1 again with new data
>    in direct IO
>                                     -> GC bio gets completed now
>                                     -> GC writes old data to the new
>                                        location and thus file#1 is
> 				       corrupted.
> 
> Fix this by submitting and waiting for pending io on meta mapping
> for direct IO case in f2fs_map_blocks().
> 
> Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
> ---
>  fs/f2fs/data.c    | 11 +++++++++++
>  fs/f2fs/f2fs.h    |  2 ++
>  fs/f2fs/segment.c |  9 +++++++++
>  3 files changed, 22 insertions(+)
> 
> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> index be19257d9e36..8952f2d610a6 100644
> --- a/fs/f2fs/data.c
> +++ b/fs/f2fs/data.c
> @@ -1030,6 +1030,11 @@ int f2fs_map_blocks(struct inode *inode, struct f2fs_map_blocks *map,
>  		map->m_flags = F2FS_MAP_MAPPED;
>  		if (map->m_next_extent)
>  			*map->m_next_extent = pgofs + map->m_len;
> +
> +		/* for hardware encryption, but to avoid potential issue in future */
> +		if (flag == F2FS_GET_BLOCK_DIO)
> +			f2fs_wait_on_block_writeback_range(inode,
> +						map->m_pblk, map->m_len);
>  		goto out;
>  	}
>  
> @@ -1188,6 +1193,12 @@ int f2fs_map_blocks(struct inode *inode, struct f2fs_map_blocks *map,
>  	goto next_dnode;
>  
>  sync_out:
> +
> +	/* for hardware encryption, but to avoid potential issue in future */
> +	if (flag == F2FS_GET_BLOCK_DIO && map->m_flags & F2FS_MAP_MAPPED)
> +		f2fs_wait_on_block_writeback_range(inode,
> +						map->m_pblk, map->m_len);
> +
>  	if (flag == F2FS_GET_BLOCK_PRECACHE) {
>  		if (map->m_flags & F2FS_MAP_MAPPED) {
>  			unsigned int ofs = start_pgofs - map->m_lblk;
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index 7693b1a2072e..4a608a71c360 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -2986,6 +2986,8 @@ void f2fs_allocate_data_block(struct f2fs_sb_info *sbi, struct page *page,
>  void f2fs_wait_on_page_writeback(struct page *page,
>  			enum page_type type, bool ordered);
>  void f2fs_wait_on_block_writeback(struct inode *inode, block_t blkaddr);
> +void f2fs_wait_on_block_writeback_range(struct inode *inode, block_t blkaddr,
> +								block_t len);
>  void f2fs_write_data_summaries(struct f2fs_sb_info *sbi, block_t start_blk);
>  void f2fs_write_node_summaries(struct f2fs_sb_info *sbi, block_t start_blk);
>  int f2fs_lookup_journal_in_cursum(struct f2fs_journal *journal, int type,
> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> index 805c8310d7b0..f306d8946d99 100644
> --- a/fs/f2fs/segment.c
> +++ b/fs/f2fs/segment.c
> @@ -3301,6 +3301,15 @@ void f2fs_wait_on_block_writeback(struct inode *inode, block_t blkaddr)
>  	}
>  }
>  
> +void f2fs_wait_on_block_writeback_range(struct inode *inode, block_t blkaddr,
> +								block_t len)
> +{
> +	block_t i;
> +
> +	for (i = 0; i < len; i++)
> +		f2fs_wait_on_block_writeback(inode, blkaddr + i);
> +}
> +
>  static int read_compacted_summaries(struct f2fs_sb_info *sbi)
>  {
>  	struct f2fs_checkpoint *ckpt = F2FS_CKPT(sbi);
> -- 
> 2.19.0.605.g01d371f741-goog
> 

-- 
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

WARNING: multiple messages have this Message-ID (diff)
From: Sahitya Tummala <stummala@codeaurora.org>
To: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH] f2fs: fix data corruption issue with hardware encryption
Date: Thu, 11 Oct 2018 09:15:09 +0530	[thread overview]
Message-ID: <20181011034509.GB24669@codeaurora.org> (raw)
In-Reply-To: <20181011030544.GA82403@jaegeuk-macbookpro.roam.corp.google.com>

On Wed, Oct 10, 2018 at 08:05:44PM -0700, Jaegeuk Kim wrote:
> On 10/10, Jaegeuk Kim wrote:
> > On 10/11, Sahitya Tummala wrote:
> > > On Wed, Oct 10, 2018 at 02:34:02PM -0700, Jaegeuk Kim wrote:
> > > > On 10/10, Sahitya Tummala wrote:
> > > > > Direct IO can be used in case of hardware encryption. The following
> > > > > scenario results into data corruption issue in this path -
> > > > > 
> > > > > Thread A -                          Thread B-
> > > > > -> write file#1 in direct IO
> > > > >                                     -> GC gets kicked in
> > > > >                                     -> GC submitted bio on meta mapping
> > > > > 				       for file#1, but pending completion
> > > > > -> write file#1 again with new data
> > > > >    in direct IO
> > > > >                                     -> GC bio gets completed now
> > > > >                                     -> GC writes old data to the new
> > > > >                                        location and thus file#1 is
> > > > > 				       corrupted.
> > > > > 
> > > > > Fix this by submitting and waiting for pending io on meta mapping
> > > > > for direct IO case in f2fs_map_blocks().
> > > > > 
> > > > > Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
> > > > > ---
> > > > >  fs/f2fs/data.c | 12 ++++++++++++
> > > > >  1 file changed, 12 insertions(+)
> > > > > 
> > > > > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> > > > > index 9ef6f1f..7b2fef0 100644
> > > > > --- a/fs/f2fs/data.c
> > > > > +++ b/fs/f2fs/data.c
> > > > > @@ -1028,6 +1028,12 @@ int f2fs_map_blocks(struct inode *inode, struct f2fs_map_blocks *map,
> > > > >  		map->m_pblk = ei.blk + pgofs - ei.fofs;
> > > > >  		map->m_len = min((pgoff_t)maxblocks, ei.fofs + ei.len - pgofs);
> > > > >  		map->m_flags = F2FS_MAP_MAPPED;
> > > > > +		/* for HW encryption, but to avoid potential issue in future */
> > > > > +		if (flag == F2FS_GET_BLOCK_DIO) {
> > > > > +			blkaddr = map->m_pblk;
> > > > > +			for (; blkaddr < map->m_pblk + map->m_len; blkaddr++)
> > > > > +				f2fs_wait_on_block_writeback(sbi, blkaddr);
> > > > 
> > > > Do we need this? IIRC, DIO would give create=1.
> > > 
> > > Yes, we need it. When we are overwriting an existing file, DIO calls
> > > f2fs_map_blocks() with create=0. From the DIO code, I see that this happens
> > > because blockdev_direct_IO() passes this dio flag DIO_SKIP_HOLES. And then
> > > in get_more_blocks(), below code updates create=0, when we are overwriting
> > > an existing file.
> > > 
> > >                 create = dio->op == REQ_OP_WRITE;
> > >                 if (dio->flags & DIO_SKIP_HOLES) {
> > >                         if (fs_startblk <= ((i_size_read(dio->inode) - 1) >>
> > >                                                         i_blkbits))
> > >                                 create = 0;
> > >                 }
> > > 
> > >                 ret = (*sdio->get_block)(dio->inode, fs_startblk,
> > >                                                 map_bh, create);
> > > 
> > 
> > Got it.
> > How about this?
> > 
> 
> Sorry, this is v2.

Looks good to me. Thanks for updating it :)

> 
> From b78dd7b2e0317be18716b9496269e9792829f63e Mon Sep 17 00:00:00 2001
> From: Sahitya Tummala <stummala@codeaurora.org>
> Date: Wed, 10 Oct 2018 10:56:22 +0530
> Subject: [PATCH] f2fs: fix data corruption issue with hardware encryption
> 
> Direct IO can be used in case of hardware encryption. The following
> scenario results into data corruption issue in this path -
> 
> Thread A -                          Thread B-
> -> write file#1 in direct IO
>                                     -> GC gets kicked in
>                                     -> GC submitted bio on meta mapping
> 				       for file#1, but pending completion
> -> write file#1 again with new data
>    in direct IO
>                                     -> GC bio gets completed now
>                                     -> GC writes old data to the new
>                                        location and thus file#1 is
> 				       corrupted.
> 
> Fix this by submitting and waiting for pending io on meta mapping
> for direct IO case in f2fs_map_blocks().
> 
> Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
> ---
>  fs/f2fs/data.c    | 11 +++++++++++
>  fs/f2fs/f2fs.h    |  2 ++
>  fs/f2fs/segment.c |  9 +++++++++
>  3 files changed, 22 insertions(+)
> 
> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> index be19257d9e36..8952f2d610a6 100644
> --- a/fs/f2fs/data.c
> +++ b/fs/f2fs/data.c
> @@ -1030,6 +1030,11 @@ int f2fs_map_blocks(struct inode *inode, struct f2fs_map_blocks *map,
>  		map->m_flags = F2FS_MAP_MAPPED;
>  		if (map->m_next_extent)
>  			*map->m_next_extent = pgofs + map->m_len;
> +
> +		/* for hardware encryption, but to avoid potential issue in future */
> +		if (flag == F2FS_GET_BLOCK_DIO)
> +			f2fs_wait_on_block_writeback_range(inode,
> +						map->m_pblk, map->m_len);
>  		goto out;
>  	}
>  
> @@ -1188,6 +1193,12 @@ int f2fs_map_blocks(struct inode *inode, struct f2fs_map_blocks *map,
>  	goto next_dnode;
>  
>  sync_out:
> +
> +	/* for hardware encryption, but to avoid potential issue in future */
> +	if (flag == F2FS_GET_BLOCK_DIO && map->m_flags & F2FS_MAP_MAPPED)
> +		f2fs_wait_on_block_writeback_range(inode,
> +						map->m_pblk, map->m_len);
> +
>  	if (flag == F2FS_GET_BLOCK_PRECACHE) {
>  		if (map->m_flags & F2FS_MAP_MAPPED) {
>  			unsigned int ofs = start_pgofs - map->m_lblk;
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index 7693b1a2072e..4a608a71c360 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -2986,6 +2986,8 @@ void f2fs_allocate_data_block(struct f2fs_sb_info *sbi, struct page *page,
>  void f2fs_wait_on_page_writeback(struct page *page,
>  			enum page_type type, bool ordered);
>  void f2fs_wait_on_block_writeback(struct inode *inode, block_t blkaddr);
> +void f2fs_wait_on_block_writeback_range(struct inode *inode, block_t blkaddr,
> +								block_t len);
>  void f2fs_write_data_summaries(struct f2fs_sb_info *sbi, block_t start_blk);
>  void f2fs_write_node_summaries(struct f2fs_sb_info *sbi, block_t start_blk);
>  int f2fs_lookup_journal_in_cursum(struct f2fs_journal *journal, int type,
> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> index 805c8310d7b0..f306d8946d99 100644
> --- a/fs/f2fs/segment.c
> +++ b/fs/f2fs/segment.c
> @@ -3301,6 +3301,15 @@ void f2fs_wait_on_block_writeback(struct inode *inode, block_t blkaddr)
>  	}
>  }
>  
> +void f2fs_wait_on_block_writeback_range(struct inode *inode, block_t blkaddr,
> +								block_t len)
> +{
> +	block_t i;
> +
> +	for (i = 0; i < len; i++)
> +		f2fs_wait_on_block_writeback(inode, blkaddr + i);
> +}
> +
>  static int read_compacted_summaries(struct f2fs_sb_info *sbi)
>  {
>  	struct f2fs_checkpoint *ckpt = F2FS_CKPT(sbi);
> -- 
> 2.19.0.605.g01d371f741-goog
> 

-- 
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

  reply	other threads:[~2018-10-11  3:45 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-10  5:26 [PATCH] f2fs: fix data corruption issue with hardware encryption Sahitya Tummala
2018-10-10 21:34 ` Jaegeuk Kim
2018-10-11  0:29   ` Sahitya Tummala
2018-10-11  2:15     ` Jaegeuk Kim
2018-10-11  2:15       ` Jaegeuk Kim
2018-10-11  3:05       ` Jaegeuk Kim
2018-10-11  3:05         ` [f2fs-dev] " Jaegeuk Kim
2018-10-11  3:45         ` Sahitya Tummala [this message]
2018-10-11  3:45           ` Sahitya Tummala
2018-10-15 12:26         ` Chao Yu
2018-10-15 12:26           ` Chao Yu

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=20181011034509.GB24669@codeaurora.org \
    --to=stummala@codeaurora.org \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-kernel@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.