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

[Mikulas Patocka <mpatocka@redhat.com>]

On Wed, 18 Mar 2026, Keith Busch wrote:

> On Wed, Mar 18, 2026 at 05:34:47PM +0100, Mikulas Patocka wrote:
> > On Mon, 16 Mar 2026, Keith Busch wrote:
> > > +static int crypt_build_sgl(struct crypt_config *cc, struct scatterlist **psg,
> > >  			   struct bvec_iter *iter, struct bio *bio,
> > >  			   int max_segs)
> > >  {
> > >  	unsigned int bytes = cc->sector_size;
> > > +	struct scatterlist *sg = *psg;
> > >  	struct bvec_iter tmp = *iter;
> > >  	int segs, i = 0;
> > >  
> > >  	bio_advance_iter(bio, &tmp, bytes);
> > >  	segs = tmp.bi_idx - iter->bi_idx + !!tmp.bi_bvec_done;
> > > -	if (segs > max_segs)
> > > -		return -EIO;
> > > +	if (segs > max_segs) {
> > > +		sg = kmalloc_array(segs, sizeof(struct scatterlist), GFP_NOIO);
> > > +		if (!sg)
> > > +			return -ENOMEM;
> > > +	}
> > >  
> > >  	sg_init_table(sg, segs);
> > >  	do {
> > 
> > GFP_NOIO allocations may be unavailable when you are swapping to the 
> > dm-crypt device and the machine runs out of memory temporarily. There 
> > should be:
> > 
> > sg = kmalloc_array(segs, sizeof(struct scatterlist), GFP_NOWAIT | __GFP_NOMEMALLOC);
> > 
> > and if it fails, allocate "sg" from a mempool with GFP_NOIO (mempool_alloc 
> > with GFP_NOIO can't fail, it waits until someone frees some entries into 
> > the mempool).
> 
> Thanks for the suggestion, this sounds good. Just to note, the use case
> for swap always writes out pages, so it's always aligned and would never
> take this path. The use case in mind where this path could happen is
> just for zero-copy direct io applications.

That's true, but I'd rather like to have the code clean and not depend on 
some implicit assumptions like "swap never uses split sglists".

> 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?

Mikulas