Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 23 Jul 2021 10:52:26 -0700
From:   Eric Biggers <ebiggers@kernel.org>
To:     Satya Tangirala <satyaprateek2357@gmail.com>
Cc:     linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
        Jens Axboe <axboe@kernel.dk>
Subject: Re: [PATCH v4 0/9] ensure bios aren't split in middle of crypto data
 unit
Message-ID: <YPsB2vsJPobULxO0@gmail.com>
References: <20210707052943.3960-1-satyaprateek2357@gmail.com>
 <YPrzMI6P7MzO3V3K@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YPrzMI6P7MzO3V3K@gmail.com>
Precedence: bulk

On Fri, Jul 23, 2021 at 09:49:52AM -0700, Eric Biggers wrote:
> On Tue, Jul 06, 2021 at 10:29:34PM -0700, Satya Tangirala wrote:
> > 
> > Changes v3 => v4
> >  - Patch 4 in v3 has been removed (Eric points out it isn't required
> >    without some of the changes in the device mapper patchset at
> >    https://lore.kernel.org/linux-block/20210604210908.2105870-1-satyat@google.com/
> >   so I'll add this patch to that series instead.
> 
> Wouldn't it make more sense to have the blk-crypto-fallback change in this
> series?  My concern was just that it didn't make sense to have it split between
> the two patch series -- it seemed like one logical change.

This series also doesn't actually remove the data_unit_size bvec alignment
requirement from block/blk-crypto.c.  Isn't that the main goal here?  So I
expected that it would be included.

Unless there are special considerations here, I'd expect that all the block
layer changes needed for the fscrypt direct I/O support would be in one patch
series that could go in together, and then the patch series with the direct I/O
support would be only filesystem layer changes.

- Eric