All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Chao Yu <chao@kernel.org>
Cc: Eric Biggers <ebiggers@kernel.org>,
	Jaegeuk Kim <jaegeuk@kernel.org>,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org,
	Satya Tangirala <satyaprateek2357@gmail.com>,
	Changheun Lee <nanich.lee@samsung.com>,
	Matthew Bobrowski <mbobrowski@mbobrowski.org>
Subject: Re: [PATCH 3/9] f2fs: rework write preallocations
Date: Tue, 27 Jul 2021 08:33:35 -0700	[thread overview]
Message-ID: <20210727153335.GE559212@magnolia> (raw)
In-Reply-To: <70d9c954-d7f0-bbe2-f078-62273229342f@kernel.org>

On Tue, Jul 27, 2021 at 04:30:16PM +0800, Chao Yu wrote:
> On 2021/7/27 15:38, Eric Biggers wrote:
> > That's somewhat helpful, but I've been doing some more investigation and now I'm
> > even more confused.  How can f2fs support non-overwrite DIO writes at all
> > (meaning DIO writes in LFS mode as well as DIO writes to holes in non-LFS mode),
> > given that it has no support for unwritten extents?  AFAICS, as-is users can
> 
> I'm trying to pick up DAX support patch created by Qiuyang from huawei, and it
> looks it faces the same issue, so it tries to fix this by calling sb_issue_zeroout()
> in f2fs_map_blocks() before it returns.

I really hope you don't, because zeroing the region before memcpy'ing it
is absurd.  I don't know if f2fs can do that (xfs can't really) without
pinning resources during a potentially lengthy memcpy operation, but you
/could/ allocate the space in ->iomap_begin, attach some record of that
to iomap->private, and only commit the mapping update in ->iomap_end.

--D

> > easily leak uninitialized disk contents on f2fs by issuing a DIO write that
> > won't complete fully (or might not complete fully), then reading back the blocks
> > that got allocated but not written to.
> > 
> > I think that f2fs will have to take the ext2 approach of not allowing
> > non-overwrite DIO writes at all...
> Yes,
> 
> Another option is to enhance f2fs metadata's scalability which needs to update layout
> of dnode block or SSA block, after that we can record the status of unwritten data block
> there... it's a big change though...
> 
> Thanks,
> 
> > 
> > - Eric
> > 

WARNING: multiple messages have this Message-ID (diff)
From: "Darrick J. Wong" <djwong@kernel.org>
To: Chao Yu <chao@kernel.org>
Cc: Satya Tangirala <satyaprateek2357@gmail.com>,
	linux-xfs@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	Eric Biggers <ebiggers@kernel.org>,
	Matthew Bobrowski <mbobrowski@mbobrowski.org>,
	Changheun Lee <nanich.lee@samsung.com>,
	linux-fsdevel@vger.kernel.org, Jaegeuk Kim <jaegeuk@kernel.org>
Subject: Re: [f2fs-dev] [PATCH 3/9] f2fs: rework write preallocations
Date: Tue, 27 Jul 2021 08:33:35 -0700	[thread overview]
Message-ID: <20210727153335.GE559212@magnolia> (raw)
In-Reply-To: <70d9c954-d7f0-bbe2-f078-62273229342f@kernel.org>

On Tue, Jul 27, 2021 at 04:30:16PM +0800, Chao Yu wrote:
> On 2021/7/27 15:38, Eric Biggers wrote:
> > That's somewhat helpful, but I've been doing some more investigation and now I'm
> > even more confused.  How can f2fs support non-overwrite DIO writes at all
> > (meaning DIO writes in LFS mode as well as DIO writes to holes in non-LFS mode),
> > given that it has no support for unwritten extents?  AFAICS, as-is users can
> 
> I'm trying to pick up DAX support patch created by Qiuyang from huawei, and it
> looks it faces the same issue, so it tries to fix this by calling sb_issue_zeroout()
> in f2fs_map_blocks() before it returns.

I really hope you don't, because zeroing the region before memcpy'ing it
is absurd.  I don't know if f2fs can do that (xfs can't really) without
pinning resources during a potentially lengthy memcpy operation, but you
/could/ allocate the space in ->iomap_begin, attach some record of that
to iomap->private, and only commit the mapping update in ->iomap_end.

--D

> > easily leak uninitialized disk contents on f2fs by issuing a DIO write that
> > won't complete fully (or might not complete fully), then reading back the blocks
> > that got allocated but not written to.
> > 
> > I think that f2fs will have to take the ext2 approach of not allowing
> > non-overwrite DIO writes at all...
> Yes,
> 
> Another option is to enhance f2fs metadata's scalability which needs to update layout
> of dnode block or SSA block, after that we can record the status of unwritten data block
> there... it's a big change though...
> 
> Thanks,
> 
> > 
> > - Eric
> > 


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

  reply	other threads:[~2021-07-27 15:35 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-16 14:39 [PATCH 0/9] f2fs: use iomap for direct I/O Eric Biggers
2021-07-16 14:39 ` [f2fs-dev] " Eric Biggers
2021-07-16 14:39 ` [PATCH 1/9] f2fs: make f2fs_write_failed() take struct inode Eric Biggers
2021-07-16 14:39   ` [f2fs-dev] " Eric Biggers
2021-07-25 10:00   ` Chao Yu
2021-07-25 10:00     ` [f2fs-dev] " Chao Yu
2021-07-16 14:39 ` [PATCH 2/9] f2fs: remove allow_outplace_dio() Eric Biggers
2021-07-16 14:39   ` [f2fs-dev] " Eric Biggers
2021-07-19  8:41   ` Christoph Hellwig
2021-07-19  8:41     ` [f2fs-dev] " Christoph Hellwig
2021-07-16 14:39 ` [PATCH 3/9] f2fs: rework write preallocations Eric Biggers
2021-07-16 14:39   ` [f2fs-dev] " Eric Biggers
2021-07-25 10:50   ` Chao Yu
2021-07-25 10:50     ` [f2fs-dev] " Chao Yu
2021-07-25 17:57     ` Eric Biggers
2021-07-25 17:57       ` [f2fs-dev] " Eric Biggers
2021-07-27  2:00       ` Jaegeuk Kim
2021-07-27  2:00         ` [f2fs-dev] " Jaegeuk Kim
2021-07-27  3:23         ` Chao Yu
2021-07-27  3:23           ` [f2fs-dev] " Chao Yu
2021-07-27  7:38           ` Eric Biggers
2021-07-27  7:38             ` [f2fs-dev] " Eric Biggers
2021-07-27  8:30             ` Chao Yu
2021-07-27  8:30               ` [f2fs-dev] " Chao Yu
2021-07-27 15:33               ` Darrick J. Wong [this message]
2021-07-27 15:33                 ` Darrick J. Wong
2021-07-29  0:26                 ` Chao Yu
2021-07-29  0:26                   ` [f2fs-dev] " Chao Yu
2021-07-28  2:29         ` Jaegeuk Kim
2021-07-28  2:29           ` [f2fs-dev] " Jaegeuk Kim
2021-07-25 15:35   ` Jaegeuk Kim
2021-07-25 15:35     ` [f2fs-dev] " Jaegeuk Kim
2021-07-25 15:47     ` Jaegeuk Kim
2021-07-25 15:47       ` [f2fs-dev] " Jaegeuk Kim
2021-07-25 18:01       ` Eric Biggers
2021-07-25 18:01         ` [f2fs-dev] " Eric Biggers
2021-07-26 19:04         ` Jaegeuk Kim
2021-07-26 19:04           ` [f2fs-dev] " Jaegeuk Kim
2021-07-16 14:39 ` [PATCH 4/9] f2fs: reduce indentation in f2fs_file_write_iter() Eric Biggers
2021-07-16 14:39   ` [f2fs-dev] " Eric Biggers
2021-07-16 14:39 ` [PATCH 5/9] f2fs: fix the f2fs_file_write_iter tracepoint Eric Biggers
2021-07-16 14:39   ` [f2fs-dev] " Eric Biggers
2021-07-16 14:39 ` [PATCH 6/9] f2fs: implement iomap operations Eric Biggers
2021-07-16 14:39   ` [f2fs-dev] " Eric Biggers
2021-07-19  8:59   ` Christoph Hellwig
2021-07-19  8:59     ` [f2fs-dev] " Christoph Hellwig
2021-07-22 20:47     ` Jaegeuk Kim
2021-07-22 20:47       ` [f2fs-dev] " Jaegeuk Kim
2021-07-22 20:49       ` Jaegeuk Kim
2021-07-22 20:49         ` [f2fs-dev] " Jaegeuk Kim
2021-07-22 20:54       ` Eric Biggers
2021-07-22 20:54         ` [f2fs-dev] " Eric Biggers
2021-07-22 21:57         ` Jaegeuk Kim
2021-07-22 21:57           ` [f2fs-dev] " Jaegeuk Kim
2021-07-23  1:52     ` Eric Biggers
2021-07-23  1:52       ` [f2fs-dev] " Eric Biggers
2021-07-23  5:00       ` Christoph Hellwig
2021-07-23  5:00         ` [f2fs-dev] " Christoph Hellwig
2021-07-23  8:05         ` Eric Biggers
2021-07-23  8:05           ` [f2fs-dev] " Eric Biggers
2021-07-16 14:39 ` [PATCH 7/9] f2fs: use iomap for direct I/O reads Eric Biggers
2021-07-16 14:39   ` [f2fs-dev] " Eric Biggers
2021-07-16 14:39 ` [PATCH 8/9] f2fs: use iomap for direct I/O writes Eric Biggers
2021-07-16 14:39   ` [f2fs-dev] " Eric Biggers
2021-07-16 14:39 ` [PATCH 9/9] f2fs: remove f2fs_direct_IO() Eric Biggers
2021-07-16 14:39   ` [f2fs-dev] " Eric Biggers

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=20210727153335.GE559212@magnolia \
    --to=djwong@kernel.org \
    --cc=chao@kernel.org \
    --cc=ebiggers@kernel.org \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=mbobrowski@mbobrowski.org \
    --cc=nanich.lee@samsung.com \
    --cc=satyaprateek2357@gmail.com \
    /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.