Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

112 participants
7217 discussions

[PATCH v5 0/9] vfio/pci: Add mmap() for DMABUFs

by Matt Evans

Hi all, The goal of this series is to enable userspace driver designs that use VFIO to export DMABUFs representing subsets of PCI device BARs, and "vend" those buffers from a primary process to other subordinate processes by fd. These processes then mmap() the buffers and their access to the device is isolated to the exported ranges. This is an improvement on sharing the VFIO device fd to subordinate processes, which would allow unfettered access. This is achieved by enabling mmap() of vfio-pci DMABUFs, passed by fd to subordinate processes. Second, a new revocation mechanism is added to allow the primary process to forcibly revoke access to previously-shared BAR spans, even if the subordinate processes haven't cleanly exited. (The related topic of safe delegation of iommufd control to the subordinate processes is not addressed here, and is follow-up work.) The background/rationale is covered in more detail in the RFC cover letters. Feedback from the RFCs requested that, instead of creating DMABUF-specific vm_ops and .fault paths, to go the whole way and migrate the existing VFIO PCI BAR mmap() to be backed by a DMABUF too, resulting in a common vm_ops and fault handler for mmap()s of both the VFIO device and explicitly-exported DMABUFs. This will help future iommufd emulation of VFIO Type1 peer-to-peer, making it easier to get a DMABUF for a VFIO BAR as a DMA target. mmap() conversion to use DMABUF underneath has been done for vfio-pci, but not sub-drivers: nvgrace-gpu's mmap() override path is unchanged; I kept this out of scope for now not least because I don't have a thorough test setup for this system. I would prefer to help the nvgrace-gpu maintainers enable BAR mmap() DMABUFs themselves. Notes on patches ================ PCI/P2PDMA: Split pool-related cleanup out of pci_p2pdma_release() PCI/P2PDMA: Add CONFIG_PCI_P2PDMA_CORE Later in the series, vfio-pci's mmap() is going to depend on pcim_p2pdma_provider() which depended on CONFIG_PCI_P2PDMA, which in turn depended on ZONE_DEVICE. That isn't available on 32-bit and some archs, because they lack MEMORY_HOTPLUG and friends. VFIO does _not_ require actual P2P to be present for basic mmap() functionality, only for the optional CONFIG_DMA_SHARED_BUFFER feature. These split out p2pdma_core.c under CONFIG_PCI_P2PDMA_CORE (which currently contains pcim_p2pdma_provider()), and an optional CONFIG_PCI_P2PDMA which depends on ZONE_DEVICE etc. providing P2P functionality in the existing p2pdma.c. The first splits out pool cleanup from the release path, and the second does the refactor/code move to the new file. vfio/pci: Add a helper to look up PFNs for DMABUFs vfio/pci: Add a helper to create a DMABUF for a BAR-map VMA The first adds a DMABUF VMA fault handler helper to determine arbitrary-sized PFNs from ranges in DMABUF. The second refactors DMABUF export for use by the existing export feature, and adds a helper that creates a DMABUF corresponding to a VFIO BAR mmap() request. vfio/pci: Convert BAR mmap() to use a DMABUF The vfio-pci core mmap() creates a DMABUF with the helper above, and the vm_ops fault handler uses the other helper to resolve the fault. Because this depends on DMABUF structs/code, CONFIG_VFIO_PCI_CORE needs to depend on CONFIG_DMA_SHARED_BUFFER. The CONFIG_VFIO_PCI_DMABUF still conditionally enables the export support code. NOTE: The user mmap()s a device fd, but the resulting VMA's vm_file becomes that of the DMABUF. The DMABUF takes ownership of the device file and put()s it on release, which maintains the existing behaviour of a VMA keeping the VFIO device open. BAR zapping then happens via the existing vfio_pci_dma_buf_move() path, which now needs to unmap PTEs in the DMABUF's address_space. vfio/pci: Provide a user-facing name for BAR mappings There was a request for decent debug naming in /proc/<pid>/maps etc. comparable to the existing VFIO names: since the VMAs are DMABUFs, they have a "dmabuf:" prefix and can't be 100% identical to before. This is a user-visible change, but this patch at least now gives us extra info on the BDF & BAR being mapped. vfio/pci: Clean up BAR zap and revocation In general (see NOTE!) the vfio_pci_zap_bars() is now obsolete, since it unmaps PTEs in the VFIO device address_space which is now unused. This consolidates all calls (e.g. around reset) with the neighbouring vfio_pci_dma_buf_move()s into new functions, to revoke/unrevoke (making the steps clearer). NOTE: Because drivers can use their own vm_ops and override .mmap, the core must conservatively assume an overridden .mmap might still add PTEs to the VFIO device address_space and therefore still does the zap. A new flag, zap_bars_on_revoke, enables the zap when .mmap is overridden. A driver that does not need the zap can clear this to opt-out, e.g. if the driver calls down to the common mmap (and so uses DMABUFs). hisi-acc-vfio-pci does just this, and thus sets the opt-out flag. vfio/pci: Support mmap() of a VFIO DMABUF Adds mmap() for a DMABUF fd exported from vfio-pci. It was a goal to keep the VFIO device fd lifetime behaviour unchanged with respect to the DMABUFs. An application can close all device fds, and this will revoke/clean up all DMABUFs; then, no mappings or other access can be performed. When enabling mmap() of the DMABUFs, this means access through the VMA is also revoked. This complicates the fault handler because whilst the DMABUF exists, it has no guarantee that the corresponding VFIO device is still alive. Adds synchronisation ensuring the vdev is available before vdev->memory_lock is touched; this holds the device registration so that even if the buffer has been cleaned up, vdev hasn't been freed and so the lock can be safely taken. vfio/pci: Permanently revoke a DMABUF on request This is mostly a rename of `revoked` to an enum, `status`, and adding a third state for a buffer: usable, revoked temporary, revoked permanent. A new VFIO feature is added, VFIO_DEVICE_FEATURE_DMA_BUF_REVOKE, which takes a DMABUF (exported from the same device) and permanently revokes it. Thus a userspace driver can guarantee any downstream consumers of a shared fd are prevented from accessing a BAR range, and that range can be reused. NOTE: This might block userspace, waiting on importers to detach. The code doing revocation in vfio_pci_dma_buf_move() is moved, to a common function for use by ..._move() and this new feature. NOTE: See changelog, by request v4 added a condition to the existing code to elide the unnecessary invalidation/sync on the un-revoke path.) NOTE: Previous versions contained an additional feature patch, "vfio/pci: Add mmap() attributes to DMABUF feature". This has been dropped in v5 because: - The mechanism simply set vma->vm_page_prot. This would be sufficient for arm64 and other architectures. - However, (locally-run claude-opus-4-8) Sashiko flagged that, on x86, additional memtype handling is required to set up the PAT. Without this, the memtype is returned back to UC- by pfnmap_setup_cachemode() upon PTE creation. Most other sources of userspace WC mappings create PTEs eagerly with e.g. io_remap_pfn_range() which memtype_reserve() WC for the range. Getting them with lazy-fault used by vfio-pci is more complicated (e.g. perhaps registering WC for BARs with PAT/MTRRs, and deciding how to deal with aliasing...). Since this feature is not critical for this series to be useful, I've decided for now to drop it in favour of a simpler series now and revisiting this separ*ately. Testing ======= (The [RFC ONLY] userspace test program, for QEMU edu-plus, can be found in the GitHub branch below. It at least illustrates how the export, map, revoke, and close semantics interoperate.) This code has been tested in mapping DMABUFs of single/multiple ranges from multiple BARs, aliasing mmap()s, aliasing ranges across DMABUFs, vm_pgoff > 0, revocation, shutdown/cleanup scenarios, and hugepage mappings. No regressions observed on the VFIO selftests, or on our internal vfio-pci applications. VFIO on i386 has been build-tested. Dear Reviewers, =============== I was grateful for the reviews and Reviewed-Bys on previous versions. Thanks; I've added some Reviewed-Bys/Acks. I have NOT included your tags where the patch has materially changed after your review (or where requested changes ended up more than super-trivial). I hope that's okay. End === This is based on v7.2-rc3. These commits are on GitHub for easier browsing, along with "[RFC ONLY] selftests: vfio: Add standalone vfio_dmabuf_mmap_test": https://github.com/metamev/linux/compare/v7.2-rc3...dev/mev/vfio-dmabuf-mma… Thanks for reading, Matt ================================================================================ Changelog: v5: - Rebased on 7.2-rc3 - Dropped the memattr/WC feature (see explanation above). - "vfio/pci: Convert BAR mmap() to use a DMABUF": Fixed a potentially-nasty bug (which (locally-run) Sashiko found!) whereby the unmap_mapping_range() performed in cleanup was passed a range up from offset zero for the DMABUF size. Initially this was how all DMABUFs were created and an appropriate zap, but a new version kept the VFIO region index encoded in the offset -- for BAR > 0 the unmap span would then mismatch. Instead, pass size 0 to mean an "all" range. Because the goal is to shoot down everything relating to one DMABUF and the address_space can only contain things relating to that DMABUF, this is equivalent and has the bonus of never failing to match mappings... Praan, Kevin, I kept your R-Bs on this fix. - The revoke patch converts vfio_pci_dma_buf_cleanup()'s priv->vdev = NULL to a WRITE_ONCE, corresponding to the revoke function's READ_ONCE (performed to test that the VFIO and DMABUF are related). - Clarified the VFIO_DEVICE_FEATURE_DMA_BUF_REVOKE UAPI comments, documenting previously-missing error cases and their reasons. v4: https://lore.kernel.org/all/20260701171245.90111-1-matt@ozlabs.org/ v3: https://lore.kernel.org/all/20260610154327.37758-1-matt@ozlabs.org/ v2: https://lore.kernel.org/all/20260527102319.100128-1-mattev@meta.com/ v1: https://lore.kernel.org/kvm/20260416131815.2729131-1-mattev@meta.com/ RFCv2: https://lore.kernel.org/kvm/20260312184613.3710705-1-mattev@meta.com/ RFCv1: https://lore.kernel.org/all/20260226202211.929005-1-mattev@meta.com/ Tech topic: https://lore.kernel.org/linux-iommu/20250918214425.2677057-1-amastro@fb.com/ Matt Evans (9): PCI/P2PDMA: Split pool-related cleanup out of pci_p2pdma_release() PCI/P2PDMA: Add CONFIG_PCI_P2PDMA_CORE vfio/pci: Add a helper to look up PFNs for DMABUFs vfio/pci: Add a helper to create a DMABUF for a BAR-map VMA vfio/pci: Convert BAR mmap() to use a DMABUF vfio/pci: Provide a user-facing name for BAR mappings vfio/pci: Clean up BAR zap and revocation vfio/pci: Support mmap() of a VFIO DMABUF vfio/pci: Permanently revoke a DMABUF on request MAINTAINERS | 2 +- drivers/pci/Kconfig | 5 + drivers/pci/Makefile | 1 + drivers/pci/p2pdma.c | 113 +--- drivers/pci/p2pdma.h | 29 + drivers/pci/p2pdma_core.c | 122 +++++ drivers/vfio/pci/Kconfig | 5 +- drivers/vfio/pci/Makefile | 3 +- .../vfio/pci/hisilicon/hisi_acc_vfio_pci.c | 8 + drivers/vfio/pci/vfio_pci_config.c | 30 +- drivers/vfio/pci/vfio_pci_core.c | 210 +++++-- drivers/vfio/pci/vfio_pci_dmabuf.c | 515 +++++++++++++++--- drivers/vfio/pci/vfio_pci_priv.h | 53 +- include/linux/pci-p2pdma.h | 24 +- include/linux/pci.h | 2 +- include/linux/vfio_pci_core.h | 1 + include/uapi/linux/vfio.h | 25 + 17 files changed, 875 insertions(+), 273 deletions(-) create mode 100644 drivers/pci/p2pdma.h create mode 100644 drivers/pci/p2pdma_core.c -- 2.50.1 (Apple Git-155)

3 hours, 50 minutes

Re: [PATCH v2] dma-buf/udmabuf: Disable the size limit by default

by Kasireddy, Vivek

Hi Robert, > Subject: [PATCH v2] dma-buf/udmabuf: Disable the size limit by default > > As udmabuf increasingly enjoys popularity - being used in projects like > libcamera, Gstreamer, Mesa, KWin and Weston - users more frequently > encounter cases where the current default size limit of 64MB is too low. > Examples include allocating video buffers at a 8K resolution - and even > 4K > is affected when using non-subsampled video formats and high bit > depths. > > In its current form the size limit for individual buffers does not seem to > provide any additional level of protection - such as limiting the amount > of > memory a process can pin - as the later can just allocate multiple > buffers. > If additional guardrails are desired, they would likely require some kind > accounting not limited to individual buffers. > > Therefor let's disable the size limit by default by setting it to the > maximal possible value, INT_MAX. > > Signed-off-by: Robert Mader <robert.mader(a)collabora.com> > > --- > > Changes in V2: > - Use INT_MAX instead of 0 in order to not change behavior otherwise. > > See > https://lore.kernel.org/dri-devel/20260711144814.8205-1- > robert.mader(a)collabora.com/ > for a previous attempt to make the value configurable via kconfig - and > in particular > https://lore.kernel.org/dri-devel/6764ca6f-b4d8-4baa-9d27- > 2ca867ac2d41(a)amd.com/ > for the suggestion and discussion to remove the default limit. > --- > drivers/dma-buf/udmabuf.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c > index bced421c0d65..639e93704924 100644 > --- a/drivers/dma-buf/udmabuf.c > +++ b/drivers/dma-buf/udmabuf.c > @@ -20,9 +20,9 @@ static int list_limit = 1024; > module_param(list_limit, int, 0644); > MODULE_PARM_DESC(list_limit, "udmabuf_create_list->count limit. > Default is 1024."); > > -static int size_limit_mb = 64; > +static int size_limit_mb = INT_MAX; > module_param(size_limit_mb, int, 0644); > -MODULE_PARM_DESC(size_limit_mb, "Max size of a dmabuf, in > megabytes. Default is 64."); > +MODULE_PARM_DESC(size_limit_mb, "Max size of a dmabuf, in > megabytes. Default is INT_MAX."); Acked-by: Vivek Kasireddy <vivek.kasireddy(a)intel.com> If there are no further concerns/questions from anyone, I'll push it to drm-misc-next soon. Thanks, Vivek > > struct udmabuf { > pgoff_t pagecount; > -- > 2.55.0

6 hours, 2 minutes

Re: [PATCH] drm/gem: Move pages_to_sg helper into drm_gem.c

by Liviu Dudau

On Fri, Jul 24, 2026 at 01:08:58PM +0100, Adrián Larumbe wrote: > None of the semantics of the function tell of it being a PRIME-exclusive > entry point. In fact, most drivers seem to be using it to translate a list > of pages into an sg table that can be used for GPU mapping later on, rather > than just for sharing an object's pages with another driver. > > Move it across files and rename accordingly. > > Signed-off-by: Adrián Larumbe <adrian.larumbe(a)collabora.com> > --- > drm_prime_pages_to_sg() has no real dependency on PRIME/dma-buf interfaces. > It is a generic helper that converts a page array into a scatter/gather > table via dma_map_sg_attrs. Nothing in its implementation touches struct > dma_buf or import/export logic. > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 6 ++--- > drivers/gpu/drm/drm_gem.c | 35 ++++++++++++++++++++++++++ > drivers/gpu/drm/drm_gem_shmem_helper.c | 2 +- > drivers/gpu/drm/drm_prime.c | 38 ----------------------------- > drivers/gpu/drm/etnaviv/etnaviv_gem.c | 3 +-- > drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 3 ++- > drivers/gpu/drm/loongson/lsdc_gem.c | 3 +-- > drivers/gpu/drm/msm/msm_gem.c | 2 +- > drivers/gpu/drm/msm/msm_gem_prime.c | 2 +- > drivers/gpu/drm/nouveau/nouveau_prime.c | 4 +-- > drivers/gpu/drm/panthor/panthor_gem.c | 6 ++--- For Panthor and the general rename: Reviewed-by: Liviu Dudau <liviu.dudau(a)arm.com> Best regards, Liviu > drivers/gpu/drm/radeon/radeon_prime.c | 5 ++-- > drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 6 ++--- > drivers/gpu/drm/tegra/gem.c | 4 +-- > drivers/gpu/drm/vmwgfx/vmwgfx_gem.c | 4 +-- > drivers/gpu/drm/xe/xe_dma_buf.c | 6 ++--- > drivers/gpu/drm/xen/xen_drm_front_gem.c | 2 +- > include/drm/drm_gem.h | 5 +++- > include/drm/drm_prime.h | 2 -- > 19 files changed, 68 insertions(+), 70 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c > index b33c300e26e2..c9a98aec7eb6 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c > @@ -203,9 +203,9 @@ static struct sg_table *amdgpu_dma_buf_map(struct dma_buf_attachment *attach, > > switch (bo->tbo.resource->mem_type) { > case TTM_PL_TT: > - sgt = drm_prime_pages_to_sg(obj->dev, > - bo->tbo.ttm->pages, > - bo->tbo.ttm->num_pages); > + sgt = drm_pages_to_sg(obj->dev, > + bo->tbo.ttm->pages, > + bo->tbo.ttm->num_pages); > if (IS_ERR(sgt)) > return sgt; > > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c > index 018df97d590d..22c8a3b5f667 100644 > --- a/drivers/gpu/drm/drm_gem.c > +++ b/drivers/gpu/drm/drm_gem.c > @@ -780,6 +780,41 @@ void drm_gem_put_pages(struct drm_gem_object *obj, struct page **pages, > } > EXPORT_SYMBOL(drm_gem_put_pages); > > +/** > + * drm_pages_to_sg - converts a page array into an sg list > + * @dev: DRM device > + * @pages: pointer to the array of page pointers to convert > + * @nr_pages: length of the page vector > + * > + * This helper creates an sg table object from a set of pages. > + * This is useful for implementing &drm_gem_object_funcs.get_sg_table. > + */ > +struct sg_table *drm_pages_to_sg(struct drm_device *dev, > + struct page **pages, unsigned int nr_pages) > +{ > + struct sg_table *sg; > + size_t max_segment = 0; > + int err; > + > + sg = kmalloc_obj(struct sg_table); > + if (!sg) > + return ERR_PTR(-ENOMEM); > + > + if (dev) > + max_segment = dma_max_mapping_size(drm_dev_dma_dev(dev)); > + if (max_segment == 0) > + max_segment = UINT_MAX; > + err = sg_alloc_table_from_pages_segment(sg, pages, nr_pages, 0, > + (unsigned long)nr_pages << PAGE_SHIFT, > + max_segment, GFP_KERNEL); > + if (err) { > + kfree(sg); > + sg = ERR_PTR(err); > + } > + return sg; > +} > +EXPORT_SYMBOL(drm_pages_to_sg); > + > static int objects_lookup(struct drm_file *filp, u32 *handle, int count, > struct drm_gem_object **objs) > { > diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c > index 22ec52e2ffb8..144d088a477f 100644 > --- a/drivers/gpu/drm/drm_gem_shmem_helper.c > +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c > @@ -825,7 +825,7 @@ struct sg_table *drm_gem_shmem_get_sg_table(struct drm_gem_shmem_object *shmem) > > drm_WARN_ON(obj->dev, drm_gem_is_imported(obj)); > > - return drm_prime_pages_to_sg(obj->dev, shmem->pages, obj->size >> PAGE_SHIFT); > + return drm_pages_to_sg(obj->dev, shmem->pages, obj->size >> PAGE_SHIFT); > } > EXPORT_SYMBOL_GPL(drm_gem_shmem_get_sg_table); > > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c > index 9b44c78cd77f..54539a8929c1 100644 > --- a/drivers/gpu/drm/drm_prime.c > +++ b/drivers/gpu/drm/drm_prime.c > @@ -835,44 +835,6 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops = { > .vunmap = drm_gem_dmabuf_vunmap, > }; > > -/** > - * drm_prime_pages_to_sg - converts a page array into an sg list > - * @dev: DRM device > - * @pages: pointer to the array of page pointers to convert > - * @nr_pages: length of the page vector > - * > - * This helper creates an sg table object from a set of pages > - * the driver is responsible for mapping the pages into the > - * importers address space for use with dma_buf itself. > - * > - * This is useful for implementing &drm_gem_object_funcs.get_sg_table. > - */ > -struct sg_table *drm_prime_pages_to_sg(struct drm_device *dev, > - struct page **pages, unsigned int nr_pages) > -{ > - struct sg_table *sg; > - size_t max_segment = 0; > - int err; > - > - sg = kmalloc_obj(struct sg_table); > - if (!sg) > - return ERR_PTR(-ENOMEM); > - > - if (dev) > - max_segment = dma_max_mapping_size(drm_dev_dma_dev(dev)); > - if (max_segment == 0) > - max_segment = UINT_MAX; > - err = sg_alloc_table_from_pages_segment(sg, pages, nr_pages, 0, > - (unsigned long)nr_pages << PAGE_SHIFT, > - max_segment, GFP_KERNEL); > - if (err) { > - kfree(sg); > - sg = ERR_PTR(err); > - } > - return sg; > -} > -EXPORT_SYMBOL(drm_prime_pages_to_sg); > - > /** > * drm_prime_get_contiguous_size - returns the contiguous size of the buffer > * @sgt: sg_table describing the buffer to check > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c b/drivers/gpu/drm/etnaviv/etnaviv_gem.c > index b0436a1e103f..a8e8614f8210 100644 > --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c > @@ -3,7 +3,6 @@ > * Copyright (C) 2015-2018 Etnaviv Project > */ > > -#include <drm/drm_prime.h> > #include <drm/drm_print.h> > #include <linux/dma-mapping.h> > #include <linux/shmem_fs.h> > @@ -104,7 +103,7 @@ struct page **etnaviv_gem_get_pages(struct etnaviv_gem_object *etnaviv_obj) > unsigned int npages = etnaviv_obj->base.size >> PAGE_SHIFT; > struct sg_table *sgt; > > - sgt = drm_prime_pages_to_sg(dev, etnaviv_obj->pages, npages); > + sgt = drm_pages_to_sg(dev, etnaviv_obj->pages, npages); > if (IS_ERR(sgt)) { > dev_err(dev->dev, "failed to allocate sgt: %ld\n", > PTR_ERR(sgt)); > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c > index 6757ae6ec304..f44484325ddb 100644 > --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c > @@ -3,6 +3,7 @@ > * Copyright (C) 2014-2018 Etnaviv Project > */ > > +#include <drm/drm_gem.h> > #include <drm/drm_prime.h> > #include <linux/dma-buf.h> > #include <linux/module.h> > @@ -22,7 +23,7 @@ struct sg_table *etnaviv_gem_prime_get_sg_table(struct drm_gem_object *obj) > if (WARN_ON(!etnaviv_obj->pages)) /* should have already pinned! */ > return ERR_PTR(-EINVAL); > > - return drm_prime_pages_to_sg(obj->dev, etnaviv_obj->pages, npages); > + return drm_pages_to_sg(obj->dev, etnaviv_obj->pages, npages); > } > > int etnaviv_gem_prime_vmap(struct drm_gem_object *obj, struct iosys_map *map) > diff --git a/drivers/gpu/drm/loongson/lsdc_gem.c b/drivers/gpu/drm/loongson/lsdc_gem.c > index 2fb03487c983..37160228244c 100644 > --- a/drivers/gpu/drm/loongson/lsdc_gem.c > +++ b/drivers/gpu/drm/loongson/lsdc_gem.c > @@ -9,7 +9,6 @@ > #include <drm/drm_dumb_buffers.h> > #include <drm/drm_file.h> > #include <drm/drm_gem.h> > -#include <drm/drm_prime.h> > #include <drm/drm_print.h> > > #include "lsdc_drv.h" > @@ -51,7 +50,7 @@ static struct sg_table *lsdc_gem_prime_get_sg_table(struct drm_gem_object *obj) > return ERR_PTR(-ENOMEM); > } > > - return drm_prime_pages_to_sg(obj->dev, tt->pages, tt->num_pages); > + return drm_pages_to_sg(obj->dev, tt->pages, tt->num_pages); > } > > static void lsdc_gem_object_free(struct drm_gem_object *obj) > diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c > index efd3d3c9a449..7e3418290c22 100644 > --- a/drivers/gpu/drm/msm/msm_gem.c > +++ b/drivers/gpu/drm/msm/msm_gem.c > @@ -207,7 +207,7 @@ static struct page **get_pages(struct drm_gem_object *obj) > > msm_obj->pages = p; > > - msm_obj->sgt = drm_prime_pages_to_sg(obj->dev, p, npages); > + msm_obj->sgt = drm_pages_to_sg(obj->dev, p, npages); > if (IS_ERR(msm_obj->sgt)) { > void *ptr = ERR_CAST(msm_obj->sgt); > > diff --git a/drivers/gpu/drm/msm/msm_gem_prime.c b/drivers/gpu/drm/msm/msm_gem_prime.c > index 036d34c674d9..d25393a9e549 100644 > --- a/drivers/gpu/drm/msm/msm_gem_prime.c > +++ b/drivers/gpu/drm/msm/msm_gem_prime.c > @@ -23,7 +23,7 @@ struct sg_table *msm_gem_prime_get_sg_table(struct drm_gem_object *obj) > if (WARN_ON(!msm_obj->pages)) /* should have already pinned! */ > return ERR_PTR(-ENOMEM); > > - return drm_prime_pages_to_sg(obj->dev, msm_obj->pages, npages); > + return drm_pages_to_sg(obj->dev, msm_obj->pages, npages); > } > > int msm_gem_prime_vmap(struct drm_gem_object *obj, struct iosys_map *map) > diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c b/drivers/gpu/drm/nouveau/nouveau_prime.c > index caab60fc62f6..b95f2f07df74 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_prime.c > +++ b/drivers/gpu/drm/nouveau/nouveau_prime.c > @@ -32,8 +32,8 @@ struct sg_table *nouveau_gem_prime_get_sg_table(struct drm_gem_object *obj) > { > struct nouveau_bo *nvbo = nouveau_gem_object(obj); > > - return drm_prime_pages_to_sg(obj->dev, nvbo->bo.ttm->pages, > - nvbo->bo.ttm->num_pages); > + return drm_pages_to_sg(obj->dev, nvbo->bo.ttm->pages, > + nvbo->bo.ttm->num_pages); > } > > struct drm_gem_object *nouveau_gem_prime_import_sg_table(struct drm_device *dev, > diff --git a/drivers/gpu/drm/panthor/panthor_gem.c b/drivers/gpu/drm/panthor/panthor_gem.c > index 9855df738194..ec530d254fa4 100644 > --- a/drivers/gpu/drm/panthor/panthor_gem.c > +++ b/drivers/gpu/drm/panthor/panthor_gem.c > @@ -321,8 +321,8 @@ panthor_gem_dev_map_get_sgt_locked(struct panthor_gem_object *bo) > if (ret) > return ERR_PTR(ret); > > - sgt = drm_prime_pages_to_sg(bo->base.dev, bo->backing.pages, > - bo->base.size >> PAGE_SHIFT); > + sgt = drm_pages_to_sg(bo->base.dev, bo->backing.pages, > + bo->base.size >> PAGE_SHIFT); > if (IS_ERR(sgt)) > return sgt; > > @@ -702,7 +702,7 @@ static struct sg_table *panthor_gem_get_sg_table(struct drm_gem_object *obj) > drm_WARN_ON_ONCE(obj->dev, !bo->backing.pages); > drm_WARN_ON_ONCE(obj->dev, !refcount_read(&bo->backing.pin_count)); > > - return drm_prime_pages_to_sg(obj->dev, bo->backing.pages, obj->size >> PAGE_SHIFT); > + return drm_pages_to_sg(obj->dev, bo->backing.pages, obj->size >> PAGE_SHIFT); > } > > static int panthor_gem_vmap_locked(struct drm_gem_object *obj, > diff --git a/drivers/gpu/drm/radeon/radeon_prime.c b/drivers/gpu/drm/radeon/radeon_prime.c > index a77881f035e7..4cfc4282a59c 100644 > --- a/drivers/gpu/drm/radeon/radeon_prime.c > +++ b/drivers/gpu/drm/radeon/radeon_prime.c > @@ -26,6 +26,7 @@ > > #include <linux/dma-buf.h> > > +#include <drm/drm_gem.h> > #include <drm/drm_prime.h> > #include <drm/radeon_drm.h> > > @@ -38,8 +39,8 @@ struct sg_table *radeon_gem_prime_get_sg_table(struct drm_gem_object *obj) > { > struct radeon_bo *bo = gem_to_radeon_bo(obj); > > - return drm_prime_pages_to_sg(obj->dev, bo->tbo.ttm->pages, > - bo->tbo.ttm->num_pages); > + return drm_pages_to_sg(obj->dev, bo->tbo.ttm->pages, > + bo->tbo.ttm->num_pages); > } > > struct drm_gem_object *radeon_gem_prime_import_sg_table(struct drm_device *dev, > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c > index b188539dca0b..7897da0becf4 100644 > --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c > @@ -89,8 +89,8 @@ static int rockchip_gem_get_pages(struct rockchip_gem_object *rk_obj) > > rk_obj->num_pages = rk_obj->base.size >> PAGE_SHIFT; > > - rk_obj->sgt = drm_prime_pages_to_sg(rk_obj->base.dev, > - rk_obj->pages, rk_obj->num_pages); > + rk_obj->sgt = drm_pages_to_sg(rk_obj->base.dev, > + rk_obj->pages, rk_obj->num_pages); > if (IS_ERR(rk_obj->sgt)) { > ret = PTR_ERR(rk_obj->sgt); > goto err_put_pages; > @@ -432,7 +432,7 @@ struct sg_table *rockchip_gem_prime_get_sg_table(struct drm_gem_object *obj) > int ret; > > if (rk_obj->pages) > - return drm_prime_pages_to_sg(obj->dev, rk_obj->pages, rk_obj->num_pages); > + return drm_pages_to_sg(obj->dev, rk_obj->pages, rk_obj->num_pages); > > sgt = kzalloc_obj(*sgt); > if (!sgt) > diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c > index 436394e04812..701af672b4e5 100644 > --- a/drivers/gpu/drm/tegra/gem.c > +++ b/drivers/gpu/drm/tegra/gem.c > @@ -17,7 +17,7 @@ > > #include <drm/drm_drv.h> > #include <drm/drm_dumb_buffers.h> > -#include <drm/drm_prime.h> > +#include <drm/drm_gem.h> > > #include "drm.h" > #include "gem.h" > @@ -352,7 +352,7 @@ static int tegra_bo_get_pages(struct drm_device *drm, struct tegra_bo *bo) > > bo->num_pages = bo->gem.size >> PAGE_SHIFT; > > - bo->sgt = drm_prime_pages_to_sg(bo->gem.dev, bo->pages, bo->num_pages); > + bo->sgt = drm_pages_to_sg(bo->gem.dev, bo->pages, bo->num_pages); > if (IS_ERR(bo->sgt)) { > err = PTR_ERR(bo->sgt); > goto put_pages; > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c b/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c > index 39f8c46550c2..c9e7f2e3668c 100644 > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c > @@ -28,7 +28,7 @@ > #include "vmwgfx_bo.h" > #include "vmwgfx_drv.h" > > -#include "drm/drm_prime.h" > +#include "drm/drm_gem.h" > #include "drm/drm_gem_ttm_helper.h" > > #include <linux/debugfs.h> > @@ -76,7 +76,7 @@ static struct sg_table *vmw_gem_object_get_sg_table(struct drm_gem_object *obj) > if (vmw_tt->vsgt.sgt) > return vmw_tt->vsgt.sgt; > > - return drm_prime_pages_to_sg(obj->dev, vmw_tt->dma_ttm.pages, vmw_tt->dma_ttm.num_pages); > + return drm_pages_to_sg(obj->dev, vmw_tt->dma_ttm.pages, vmw_tt->dma_ttm.num_pages); > } > > static int vmw_gem_vmap(struct drm_gem_object *obj, struct iosys_map *map) > diff --git a/drivers/gpu/drm/xe/xe_dma_buf.c b/drivers/gpu/drm/xe/xe_dma_buf.c > index 8a920e58245c..f0fe80706b79 100644 > --- a/drivers/gpu/drm/xe/xe_dma_buf.c > +++ b/drivers/gpu/drm/xe/xe_dma_buf.c > @@ -118,9 +118,9 @@ static struct sg_table *xe_dma_buf_map(struct dma_buf_attachment *attach, > > switch (bo->ttm.resource->mem_type) { > case XE_PL_TT: > - sgt = drm_prime_pages_to_sg(obj->dev, > - bo->ttm.ttm->pages, > - obj->size >> PAGE_SHIFT); > + sgt = drm_pages_to_sg(obj->dev, > + bo->ttm.ttm->pages, > + obj->size >> PAGE_SHIFT); > if (IS_ERR(sgt)) > return sgt; > > diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c b/drivers/gpu/drm/xen/xen_drm_front_gem.c > index eec4c1da3f9e..a4a7c7f2c91c 100644 > --- a/drivers/gpu/drm/xen/xen_drm_front_gem.c > +++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c > @@ -236,7 +236,7 @@ struct sg_table *xen_drm_front_gem_get_sg_table(struct drm_gem_object *gem_obj) > if (!xen_obj->pages) > return ERR_PTR(-ENOMEM); > > - return drm_prime_pages_to_sg(gem_obj->dev, > + return drm_pages_to_sg(gem_obj->dev, > xen_obj->pages, xen_obj->num_pages); > } > > diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h > index 885244e375d3..7b9cc6335689 100644 > --- a/include/drm/drm_gem.h > +++ b/include/drm/drm_gem.h > @@ -155,7 +155,7 @@ struct drm_gem_object_funcs { > * here cannot be used for sg tables pointing at driver private memory > * ranges. > * > - * See also drm_prime_pages_to_sg(). > + * See also drm_pages_to_sg(). > */ > struct sg_table *(*get_sg_table)(struct drm_gem_object *obj); > > @@ -589,6 +589,9 @@ struct page **drm_gem_get_pages(struct drm_gem_object *obj); > void drm_gem_put_pages(struct drm_gem_object *obj, struct page **pages, > bool dirty, bool accessed); > > +struct sg_table *drm_pages_to_sg(struct drm_device *dev, > + struct page **pages, unsigned int nr_pages); > + > void drm_gem_lock(struct drm_gem_object *obj); > void drm_gem_unlock(struct drm_gem_object *obj); > > diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h > index f50f862f0d8b..603e16a40ae7 100644 > --- a/include/drm/drm_prime.h > +++ b/include/drm/drm_prime.h > @@ -92,8 +92,6 @@ void drm_gem_dmabuf_vunmap(struct dma_buf *dma_buf, struct iosys_map *map); > int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma); > int drm_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct *vma); > > -struct sg_table *drm_prime_pages_to_sg(struct drm_device *dev, > - struct page **pages, unsigned int nr_pages); > struct dma_buf *drm_gem_prime_export(struct drm_gem_object *obj, > int flags); > > > --- > base-commit: 48dd37d1fef33fbf42f1d6887c61e242fd21d00d > change-id: 20260724-get_pages-e2e91c53eaa3 > > Best regards, > -- > Adrián Larumbe <adrian.larumbe(a)collabora.com> > -- ==================== | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --------------- ¯\_(ツ)_/¯

11 hours, 49 minutes

Do My Online Class: A Smarter Way to Stay on Track

by davidtim00990＠gmail.com

Managing online school can be stressful when assignments, weekly discussions, and due dates start to add up. Students have to worry about attending classes while working a job, internship, or taking care of their families. Most students have to ask themselves, do my online class for me https://myassignmenthelp.com/take-my-online-class.html while trying to find ways to make managing their education easier. Academic assistance can be helpful to staying on top of everything while being able to get the grades they want. With the right planning, guidance, and effort, online school can be manageable. Having good time-management skills and using the right resources can help students get the most out of their education and be able to accomplish their goals.

16 hours, 41 minutes

Re: [PATCH v3 1/2] dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds

by Sumit Semwal

Hello Baineng, On Mon, 27 Jul 2026 at 08:56, 寿柏能 <shoubaineng(a)gmail.com> wrote: > > Ping. Any chance this can be picked up? Thank you for the patch. While discussing with T J, we realised that adding a selftest for this would also be helpful. Could you please re-submit with a selftest added? > > Baineng Thanks and best regards, Sumit. > > 寿柏能 <shoubaineng(a)gmail.com> 于2026年7月15日周三 10:04写道： >> >> Hi David >> >> The rollback here is the simplest possible case (put_unused_fd + >> dma_buf_put), not the complex sockopt scenario you describe. >> >> Baineng >> >> David Laight <david.laight.linux(a)gmail.com> 于2026年7月14日周二 22:33写道： >>> >>> On Tue, 14 Jul 2026 21:38:07 +0800 >>> 寿柏能 <shoubaineng(a)gmail.com> wrote: >>> >>> > Hi David, >>> > >>> > Thanks for the feedback. >>> > >>> > The concern is not just about the EFAULT return — it's about the race >>> > window between fd_install() and copy_to_user(). Once fd_install() >>> > returns, the fd is immediately observable by other threads in the same >>> > process (via /proc/self/fd, SCM_RIGHTS, etc.), even before >>> > copy_to_user() has a chance to fail. The triggering condition is a >>> > deliberate mprotect() flip, not a corrupted heap. >>> >>> That is what makes doing the close wrong. >>> But that is a program aggressively trying to hit the timing window, >>> not a normal program that has managed to pass an invalid pointer. >>> The most likely reason for a real program passing an invalid pointer >>> is a corrupted heap (assuming the stupid coding errors are fixed). >>> >>> It is really no different from the sockopt code that receives >>> SCM_RIGHTS messages. >>> In that case once you've removed the FILE from the socket (or similar) >>> you really don't want to have to put it back because the write to the >>> sockopt buffer or length field fails. >>> The chance of correctly reverting the kernel state is small - and won't >>> be tested. >>> >>> David >>> >>> > >>> > The fix itself is small and follows the standard kernel idiom: >>> > get_unused_fd_flags() reserves the fd without publishing it, so the >>> > window between reservation and install is entirely under kernel control. >>> > >>> > Baineng >>> > >>> > David Laight <david.laight.linux(a)gmail.com> 于2026年7月14日周二 21:14写道： >>> > >>> > > On Tue, 14 Jul 2026 19:46:53 +0800 >>> > > Baineng Shou <shoubaineng(a)gmail.com> wrote: >>> > > >>> > > > DMA_HEAP_IOCTL_ALLOC allocates a dma-buf and installs an fd into the >>> > > > caller's fd table via dma_buf_fd() -> fd_install() before >>> > > > dma_heap_ioctl() copies the result back to userspace. If the trailing >>> > > > copy_to_user() fails, userspace never learns the fd number, but the >>> > > > fd (and the underlying dma-buf reference) are already visible to >>> > > > other threads in the same process and are leaked for the lifetime of >>> > > > the process. >>> > > > >>> > > > The obvious "close it on the failure path" fix is unsafe: once >>> > > > fd_install() has run, another thread can already dup() the fd, send >>> > > > it via SCM_RIGHTS, or close() it and let its number be reused, so a >>> > > > subsequent close_fd() from the ioctl path can operate on an unrelated >>> > > > file. This was pointed out by Christian König on v1 [1]. >>> > > ... >>> > > >>> > > My 2c: >>> > > >>> > > The other option is just to leave it as a 'problem for user space'. >>> > > No reasonable program is going to handle the EFAULT return by doing >>> > > anything other than exiting. >>> > > Even getting an EFAULT is really an indication that the application >>> > > is already in a real mess - most likely with a badly corrupted heap. >>> > > >>> > > Anything else leaves error recovery code in the kernel that is pretty >>> > > much never executed and open to a variety of bugs. >>> > > While the recovery here is probably ok, there are some sockopt calls >>> > > where it is all more complicated. >>> > > >>> > > David >>> > > >>>

19 hours, 47 minutes

by homesforyou28＠gmail.com

watsap:+237679457696 The Breeky 200mcg tablets Dubai (_/¯_/¯_/¯watsap:+237679457696_/¯_/¯_/¯ Plan B Kit _/¯_/¯Abu Dhabi, (Uae) Ajman, Sharjah, Al ain, Al barsha Abortion pill Abu Dhabi DubaiThe Breeky 200mcg tablets Dubai (watsap:+237679457696)Buy Abortion pills in riyadh% #jeddah, %dammam, @medina,riyadh saudi arabia?] watsap:+237679457696 __?***?]”Abortion Pills For Sale In kuwait abortion pills in Kuwait watsap:+237679457696, Buy Mtp Kit In Kuwait watsap:+237679457696, watsap:+237679457696 buy Mifepristone and misoprostol online In Kuwait, watsap:watsap:+237679457696 Abortion Pills For Sale In Dubai, watsap:+237679457696 Abortion Pills In Dubai, watsap:+237679457696 Misoprostol Medicine Available In Dubai, Mifepristone Tablets In Abu Dhabi, watsap:+237679457696 Abortion Pills For Sale In Abu Dhabi, watsap:+237679457696 Abortion Pills In Abu Dhabi, watsap:+237679457696 Misoprostol Medicine Available In Abu Dhabi, Mifepristone Tablets In Abu Dhabi,watsap:+237679457696 Abortion Pills For Sale In Sharjah, +237679457696 Abortion Pills In Sharjah, watsap:+237679457696 Misoprostol Medicine Available In Sharjah, Mifepristone Tablets In Sharjah, watsap:+237679457696 Abortion Pills For Sale In Al Ain, watsap:+237679457696 Abortion Pills In Al Ain, watsap:+237679457696 Misoprostol Medicine Available In Al Ain, Mifepristone Tablets In Al Ain, watsap:+237679457696 Abortion Pills For Sale In Fujairah, watsap:+237679457696 Abortion Pills In Fujairah, watsap:+237679457696 Misoprostol Medicine Available In Fujairah, Mifepristone Tablets In Fujairah, watsap:+237679457696 Abortion Pills For Sale In Ras Al Khaimah, watsap:+237679457696 Abortion Pills In Ras Al Khaimah, watsap:+237679457696 Misoprostol Medicine Available In Ras Al Khaimah, Mifepristone Tablets In RAs Al Khaimah, watsap:+237679457696 Abortion Pills For Sale In Doha, +237679457696 Abortion Pills In Doha, watsap:+237679457696 Misoprostol Medicine Available In Doha, Mifepristone Tablets In Doha, watsap:+237679457696 Abortion Pills For Sale In Qatar, +237679457696 Abortion Pills In Qatar, watsap:+237679457696 Misoprostol Medicine Available In Qatar, Mifepristone Tablets In Qatar, watsap:+237679457696 Abortion Pills For Sale In Bahrain, watsap:+237679457696 Abortion Pills In Bahrain, watsap:+237679457696 Misoprostol Medicine Available In Bahrain, Mifepristone Tablets In Bahrain, watsap:+237679457696 Abortion Pills For Sale In Muscat, watsap:+237679457696 Abortion Pills In Muscat, watsap:+237679457696 Misoprostol Medicine Available In Muscat, Mifepristone Tablets In Muscat, watsap:+237679457696 Abortion Pills For Sale In Oman, watsap:+237679457696 Abortion Pills In Oman, watsap:+237679457696 Misoprostol Medicine Available In Oman, Mifepristone Tablets In Oman,

21 hours, 55 minutes

by homesforyou28＠gmail.com

1 day, 13 hours

by homesforyou28＠gmail.com

1 day, 13 hours

by homesforyou28＠gmail.com

1 day, 13 hours

by homesforyou28＠gmail.com

1 day, 13 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig