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
