Re: [PATCH v7 3/6] mm/gup: Introduce memfd_pin_folios() for pinning memfd folios (v7)

[Jason Gunthorpe <jgg@nvidia.com>]

On Wed, Dec 13, 2023 at 04:36:34PM +0100, Christoph Hellwig wrote:
> On Wed, Dec 13, 2023 at 08:31:55AM -0400, Jason Gunthorpe wrote:
> > > That is, populate a scatterlist with ubuf->pagecount number of entries,
> > > where each segment if of size PAGE_SIZE, in order to be consistent and
> > > support a wide variety of DMA importers that may not probably handle
> > > segments that are larger than PAGE_SIZE.
> > 
> > No! This is totally wrong, sg lists must aggregate up to the limits
> > specified in the struct device. We have importer helpers that do this
> > aggregation.
> > 
> > If some driver is working with a sglist and can't handle this it is
> > simply broken. Do not mess up core code to accomodate such things.
> 
> Well.. There's no single driver that is broken, it's more the whole
> dmabuf philosophy that wants things to be mappable by multiple devices
> without knowing their limits beforehand.  So you'll get this cargo
> culting.

It is not so bad, the API has the importer pass a struct device to the
exporter that can be used in the usual way to shape the sg list.

But really, I think in most cases importers don't strictly need the sg
list to be a certain configuration, it is just a combination of lazy
driver writers and a lack of common helpers to iterate over the sg
list in the way they need.

RDMA has done this right, but for it to work efficiently the exporter
*must* aggregate all contiguous memory into a single sg element
otherwise you loose the HW's large page support.

Jason