Re: [RESEND PATCHv3 2/2] dm-crypt: dynamic scatterlist for many segments

[Keith Busch <kbusch@kernel.org>]

On Wed, Mar 18, 2026 at 07:16:15PM +0100, Mikulas Patocka wrote:
> On Wed, 18 Mar 2026, Keith Busch wrote:
> > On Wed, Mar 18, 2026 at 06:40:52PM +0100, Mikulas Patocka wrote:
> > > On Wed, 18 Mar 2026, Keith Busch wrote:
> > > 
> > > > But even then, the only thing I know of that really wants this has an
> > > > offset that straddles two pages per block, so I never need more than 2
> > > > segments, and the inline scatterlist has four. There's just currently no
> > > > way for the block layer to report a max-segments-per-block limit, so I'm
> > > > including this patch to be consistent with the reportable limits.
> > > 
> > > Can userspace use preadv/pwritev with many small iovecs on a file opened 
> > > for direct I/O?
> > 
> > Yes, I have several patches that were accepted last year to block and
> > iomap that align direct-io memory requirements to the backing device's
> > dma constraints. You can do dword aligned and sized vectored IO to a
> > block device today if the block limits say its okay.
> 
> So, we must support worst-case scenario - "cc->sector_size / 4" segments. 
> 
> sector_size can be up to 4096, so there may be up to 1024 segments. Each 
> segment consumes sizeof(struct scatterlist) bytes - that's 32 bytes. So, 
> we allocate up to 32768 bytes.
> 
> kmalloc with size greater than 32768 is unreliable - so we are just on 
> this limit.

Direct-io hits the BIO_VEC_MAX limit (256) first, so 8k for the
scatterlist (not great, but less terrible). You can have some 4-byte
segments in the user request, but the average segement size would have
to be larger. The important part is that any segment can start at any
memory address dword alignment offset.