From: Eric Biggers <ebiggers@kernel.org> To: Matthew Wilcox <willy@infradead.org> Cc: Dave Chinner <david@fromorbit.com>, Satya Tangirala <satyat@google.com>, linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org Subject: Re: [PATCH v4 3/7] iomap: support direct I/O with fscrypt using blk-crypto Date: Wed, 22 Jul 2020 16:12:58 -0700 [thread overview] Message-ID: <20200722231258.GA83434@sol.localdomain> (raw) In-Reply-To: <20200722224407.GR15516@casper.infradead.org> On Wed, Jul 22, 2020 at 11:44:07PM +0100, Matthew Wilcox wrote: > On Wed, Jul 22, 2020 at 03:34:04PM -0700, Eric Biggers wrote: > > > Which means you are now placing a new constraint on this code in > > > that we cannot ever, in future, zero entire blocks here. > > > > > > This code can issue arbitrary sized zeroing bios - multiple entire fs blocks > > > blocks if necessary - so I think constraining it to only support > > > partial block zeroing by adding a warning like this is no correct. > > > > In v3 and earlier this instead had the code to set an encryption context: > > > > fscrypt_set_bio_crypt_ctx(bio, inode, pos >> inode->i_blkbits, > > GFP_KERNEL); > > > > Would you prefer that, even though the call to fscrypt_set_bio_crypt_ctx() would > > always be a no-op currently (since for now, iomap_dio_zero() will never be > > called with an encrypted file) and thus wouldn't be properly tested? > > > > BTW, iomap_dio_zero() is actually limited to one page, so it's not quite > > "arbitrary sizes". > > I have a patch for that > > http://git.infradead.org/users/willy/pagecache.git/commitdiff/1a4d72a890ca9c2ea3d244a6153511ae674ce1d8 No you don't :-) Your patch is for iomap_zero_range() in fs/iomap/buffered-io.c. It doesn't touch fs/iomap/direct-io.c which is what we're talking about here. > It's not going to cause a problem for crossing a 2^32 boundary because > pages are naturally aligned and don't get that big. Well, the boundary can actually occur at any block. But it's not relevant here because (a) fs/iomap/buffered-io.c doesn't yet support encryption anyway, since neither ext4 nor f2fs use it; and (b) iomap_zero_range() just writes to the pagecache, and the bios aren't actually issued until ->writepages(). - Eric
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org> To: Matthew Wilcox <willy@infradead.org> Cc: Satya Tangirala <satyat@google.com>, Dave Chinner <david@fromorbit.com>, linux-f2fs-devel@lists.sourceforge.net, linux-xfs@vger.kernel.org, linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org Subject: Re: [f2fs-dev] [PATCH v4 3/7] iomap: support direct I/O with fscrypt using blk-crypto Date: Wed, 22 Jul 2020 16:12:58 -0700 [thread overview] Message-ID: <20200722231258.GA83434@sol.localdomain> (raw) In-Reply-To: <20200722224407.GR15516@casper.infradead.org> On Wed, Jul 22, 2020 at 11:44:07PM +0100, Matthew Wilcox wrote: > On Wed, Jul 22, 2020 at 03:34:04PM -0700, Eric Biggers wrote: > > > Which means you are now placing a new constraint on this code in > > > that we cannot ever, in future, zero entire blocks here. > > > > > > This code can issue arbitrary sized zeroing bios - multiple entire fs blocks > > > blocks if necessary - so I think constraining it to only support > > > partial block zeroing by adding a warning like this is no correct. > > > > In v3 and earlier this instead had the code to set an encryption context: > > > > fscrypt_set_bio_crypt_ctx(bio, inode, pos >> inode->i_blkbits, > > GFP_KERNEL); > > > > Would you prefer that, even though the call to fscrypt_set_bio_crypt_ctx() would > > always be a no-op currently (since for now, iomap_dio_zero() will never be > > called with an encrypted file) and thus wouldn't be properly tested? > > > > BTW, iomap_dio_zero() is actually limited to one page, so it's not quite > > "arbitrary sizes". > > I have a patch for that > > http://git.infradead.org/users/willy/pagecache.git/commitdiff/1a4d72a890ca9c2ea3d244a6153511ae674ce1d8 No you don't :-) Your patch is for iomap_zero_range() in fs/iomap/buffered-io.c. It doesn't touch fs/iomap/direct-io.c which is what we're talking about here. > It's not going to cause a problem for crossing a 2^32 boundary because > pages are naturally aligned and don't get that big. Well, the boundary can actually occur at any block. But it's not relevant here because (a) fs/iomap/buffered-io.c doesn't yet support encryption anyway, since neither ext4 nor f2fs use it; and (b) iomap_zero_range() just writes to the pagecache, and the bios aren't actually issued until ->writepages(). - Eric _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next prev parent reply other threads:[~2020-07-22 23:13 UTC|newest] Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-07-20 23:37 [PATCH v4 0/7] add support for direct I/O with fscrypt using blk-crypto Satya Tangirala 2020-07-20 23:37 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2020-07-20 23:37 ` [PATCH v4 1/7] fscrypt: Add functions for direct I/O support Satya Tangirala 2020-07-20 23:37 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2020-07-22 17:04 ` Jaegeuk Kim 2020-07-22 17:04 ` [f2fs-dev] " Jaegeuk Kim 2020-07-20 23:37 ` [PATCH v4 2/7] direct-io: add support for fscrypt using blk-crypto Satya Tangirala 2020-07-20 23:37 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2020-07-22 17:05 ` Jaegeuk Kim 2020-07-22 17:05 ` [f2fs-dev] " Jaegeuk Kim 2020-07-20 23:37 ` [PATCH v4 3/7] iomap: support direct I/O with " Satya Tangirala 2020-07-20 23:37 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2020-07-22 17:06 ` Jaegeuk Kim 2020-07-22 17:06 ` [f2fs-dev] " Jaegeuk Kim 2020-07-22 21:16 ` Dave Chinner 2020-07-22 21:16 ` [f2fs-dev] " Dave Chinner 2020-07-22 22:34 ` Eric Biggers 2020-07-22 22:34 ` [f2fs-dev] " Eric Biggers 2020-07-22 22:44 ` Matthew Wilcox 2020-07-22 22:44 ` [f2fs-dev] " Matthew Wilcox 2020-07-22 23:12 ` Eric Biggers [this message] 2020-07-22 23:12 ` Eric Biggers 2020-07-22 23:26 ` Eric Biggers 2020-07-22 23:26 ` [f2fs-dev] " Eric Biggers 2020-07-22 23:32 ` Darrick J. Wong 2020-07-22 23:32 ` [f2fs-dev] " Darrick J. Wong 2020-07-22 23:43 ` Eric Biggers 2020-07-22 23:43 ` [f2fs-dev] " Eric Biggers 2020-07-23 22:07 ` Dave Chinner 2020-07-23 22:07 ` [f2fs-dev] " Dave Chinner 2020-07-23 23:03 ` Eric Biggers 2020-07-23 23:03 ` [f2fs-dev] " Eric Biggers 2020-07-24 1:39 ` Dave Chinner 2020-07-24 1:39 ` [f2fs-dev] " Dave Chinner 2020-07-24 3:46 ` Eric Biggers 2020-07-24 3:46 ` [f2fs-dev] " Eric Biggers 2020-07-24 5:31 ` Dave Chinner 2020-07-24 5:31 ` [f2fs-dev] " Dave Chinner 2020-07-24 17:41 ` Eric Biggers 2020-07-24 17:41 ` [f2fs-dev] " Eric Biggers 2020-07-25 23:47 ` Dave Chinner 2020-07-25 23:47 ` [f2fs-dev] " Dave Chinner 2020-07-25 23:59 ` Dave Chinner 2020-07-25 23:59 ` [f2fs-dev] " Dave Chinner 2020-07-26 2:42 ` Eric Biggers 2020-07-26 2:42 ` [f2fs-dev] " Eric Biggers 2020-07-27 17:16 ` Eric Biggers 2020-07-27 17:16 ` [f2fs-dev] " Eric Biggers 2020-07-20 23:37 ` [PATCH v4 4/7] ext4: " Satya Tangirala 2020-07-20 23:37 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2020-07-22 17:07 ` Jaegeuk Kim 2020-07-22 17:07 ` [f2fs-dev] " Jaegeuk Kim 2020-07-20 23:37 ` [PATCH v4 5/7] f2fs: " Satya Tangirala 2020-07-20 23:37 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2020-07-21 20:11 ` Jaegeuk Kim 2020-07-21 20:11 ` [f2fs-dev] " Jaegeuk Kim 2020-07-20 23:37 ` [PATCH v4 6/7] fscrypt: document inline encryption support Satya Tangirala 2020-07-20 23:37 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2020-07-22 17:01 ` Jaegeuk Kim 2020-07-22 17:01 ` [f2fs-dev] " Jaegeuk Kim 2020-07-20 23:37 ` [PATCH v4 7/7] fscrypt: update documentation for direct I/O support Satya Tangirala 2020-07-20 23:37 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2020-07-21 0:47 ` Eric Biggers 2020-07-21 0:47 ` [f2fs-dev] " Eric Biggers 2020-07-22 16:57 ` Jaegeuk Kim 2020-07-22 16:57 ` [f2fs-dev] " Jaegeuk Kim 2020-07-21 0:56 ` [PATCH v4 0/7] add support for direct I/O with fscrypt using blk-crypto Eric Biggers 2020-07-21 0:56 ` [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=20200722231258.GA83434@sol.localdomain \ --to=ebiggers@kernel.org \ --cc=david@fromorbit.com \ --cc=linux-ext4@vger.kernel.org \ --cc=linux-f2fs-devel@lists.sourceforge.net \ --cc=linux-fscrypt@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-xfs@vger.kernel.org \ --cc=satyat@google.com \ --cc=willy@infradead.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: linkBe 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.