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