All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [PATCH 3/6] f2fs: do not expose unwritten blocks to user by DIO
Date: Fri, 7 Jan 2022 18:21:26 -0800	[thread overview]
Message-ID: <Ydj1JvEeLo1mrqvb@sol.localdomain> (raw)
In-Reply-To: <YdjucBBopEDuUb5b@google.com>

On Fri, Jan 07, 2022 at 05:52:48PM -0800, Jaegeuk Kim wrote:
> On 01/07, Eric Biggers wrote:
> > Hi Jaegeuk,
> > 
> > On Tue, Jan 04, 2022 at 01:24:16PM -0800, Jaegeuk Kim wrote:
> > > DIO preallocates physical blocks before writing data, but if an error occurrs
> > > or power-cut happens, we can see block contents from the disk. This patch tries
> > > to fix it by 1) turning to buffered writes for DIO into holes, 2) truncating
> > > unwritten blocks from error or power-cut.
> > > 
> > > Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
> > > ---
> > >  fs/f2fs/data.c  |  5 ++++-
> > >  fs/f2fs/f2fs.h  |  5 +++++
> > >  fs/f2fs/file.c  | 27 ++++++++++++++++++---------
> > >  fs/f2fs/inode.c |  8 ++++++++
> > >  4 files changed, 35 insertions(+), 10 deletions(-)
> > 
> > Unfortunately, this patch doesn't completely fix the uninitialized data
> > exposure.  The problem is that it only makes DIO writes fall back to buffered
> > writes for holes, and not for reserved blocks (NEW_ADDR).  f2fs's reserved
> > blocks are *not* the same as the unwritten extents that other filesystems have;
> > f2fs's reserved blocks have to be turned into regular blocks before DIO can
> > write to them.  That immediately exposes them to concurrent reads (at least
> > buffered reads, but I think DIO reads too).
> 
> Isn't it resolved by i_size which gives the written blocks only?
> 

I'm not sure what you mean, but this is for non-extending writes, so i_size
isn't relevant.

- Eric

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH 3/6] f2fs: do not expose unwritten blocks to user by DIO
Date: Fri, 7 Jan 2022 18:21:26 -0800	[thread overview]
Message-ID: <Ydj1JvEeLo1mrqvb@sol.localdomain> (raw)
In-Reply-To: <YdjucBBopEDuUb5b@google.com>

On Fri, Jan 07, 2022 at 05:52:48PM -0800, Jaegeuk Kim wrote:
> On 01/07, Eric Biggers wrote:
> > Hi Jaegeuk,
> > 
> > On Tue, Jan 04, 2022 at 01:24:16PM -0800, Jaegeuk Kim wrote:
> > > DIO preallocates physical blocks before writing data, but if an error occurrs
> > > or power-cut happens, we can see block contents from the disk. This patch tries
> > > to fix it by 1) turning to buffered writes for DIO into holes, 2) truncating
> > > unwritten blocks from error or power-cut.
> > > 
> > > Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
> > > ---
> > >  fs/f2fs/data.c  |  5 ++++-
> > >  fs/f2fs/f2fs.h  |  5 +++++
> > >  fs/f2fs/file.c  | 27 ++++++++++++++++++---------
> > >  fs/f2fs/inode.c |  8 ++++++++
> > >  4 files changed, 35 insertions(+), 10 deletions(-)
> > 
> > Unfortunately, this patch doesn't completely fix the uninitialized data
> > exposure.  The problem is that it only makes DIO writes fall back to buffered
> > writes for holes, and not for reserved blocks (NEW_ADDR).  f2fs's reserved
> > blocks are *not* the same as the unwritten extents that other filesystems have;
> > f2fs's reserved blocks have to be turned into regular blocks before DIO can
> > write to them.  That immediately exposes them to concurrent reads (at least
> > buffered reads, but I think DIO reads too).
> 
> Isn't it resolved by i_size which gives the written blocks only?
> 

I'm not sure what you mean, but this is for non-extending writes, so i_size
isn't relevant.

- Eric


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

  reply	other threads:[~2022-01-08  2:21 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-04 21:24 [PATCH 1/6] f2fs: rework write preallocations Jaegeuk Kim
2022-01-04 21:24 ` [f2fs-dev] " Jaegeuk Kim
2022-01-04 21:24 ` [PATCH 2/6] f2fs: reduce indentation in f2fs_file_write_iter() Jaegeuk Kim
2022-01-04 21:24   ` [f2fs-dev] " Jaegeuk Kim
2022-01-04 21:24 ` [PATCH 3/6] f2fs: do not expose unwritten blocks to user by DIO Jaegeuk Kim
2022-01-04 21:24   ` [f2fs-dev] " Jaegeuk Kim
2022-01-05 13:19   ` Chao Yu
2022-01-05 13:19     ` Chao Yu
2022-01-05 18:25     ` Jaegeuk Kim
2022-01-05 18:25       ` Jaegeuk Kim
2022-01-07 23:13   ` Eric Biggers
2022-01-07 23:13     ` [f2fs-dev] " Eric Biggers
2022-01-08  1:52     ` Jaegeuk Kim
2022-01-08  1:52       ` [f2fs-dev] " Jaegeuk Kim
2022-01-08  2:21       ` Eric Biggers [this message]
2022-01-08  2:21         ` Eric Biggers
2022-01-08  3:35         ` Jaegeuk Kim
2022-01-08  3:35           ` [f2fs-dev] " Jaegeuk Kim
2022-01-08  4:21           ` Eric Biggers
2022-01-08  4:21             ` Eric Biggers
2022-01-04 21:24 ` [PATCH 4/6] f2fs: fix the f2fs_file_write_iter tracepoint Jaegeuk Kim
2022-01-04 21:24   ` [f2fs-dev] " Jaegeuk Kim
2022-01-04 21:24 ` [f2fs-dev] [PATCH 5/6] f2fs: implement iomap operations Jaegeuk Kim
2022-01-04 21:24   ` Jaegeuk Kim
2022-01-05 13:20   ` [f2fs-dev] " Chao Yu
2022-01-05 13:20     ` Chao Yu
2022-01-05 18:25     ` Jaegeuk Kim
2022-01-05 18:25       ` Jaegeuk Kim
2022-01-04 21:24 ` [PATCH 6/6] f2fs: use iomap for direct I/O Jaegeuk Kim
2022-01-04 21:24   ` [f2fs-dev] " Jaegeuk Kim

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=Ydj1JvEeLo1mrqvb@sol.localdomain \
    --to=ebiggers@kernel.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.