Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

17 participants
4318 discussions

RECOVER LOST INVESTMENT:THROUGH CHAINTRACE ASSET RECOVERY

by mikelowrey090＠gmail.com

I am thrilled to share my positive experience with CHAINTRACE ASSET RECOVERY, a reputable firm that specializes in recovering lost or scammed cryptocurrencies. Unfortunately, I fell victim to a sophisticated scam, which resulted in the loss of my bitcoin. I had sent the funds to a scammer's wallet address, thinking I was making a legitimate transaction. However, it soon became apparent that I had been deceived. Devastated and feeling helpless, I began to research possible solutions to recover my stolen bitcoin. That's when I came across CHAINTRACE ASSET RECOVERY. I was skeptical at first, but after reading numerous testimonials and reviews from satisfied clients, I decided to reach out to them for assistance. The team at CHAINTRACE ASSET RECOVERY was professional, responsive, and empathetic. They guided me through the recovery process, which was surprisingly efficient and straightforward. Their expertise and knowledge of blockchain technology and cryptocurrency transactions were impressive, and I was confident that I was in good hands. Thanks to CHAINTRACE ASSET RECOVERY, I was able to recover a significant portion of my lost bitcoin. I am extremely grateful for their help and would highly recommend their services to anyone who has fallen victim to cryptocurrency scams. If you have lost your crypto to scammers, I urge you to contact CHAINTRACE ASSET RECOVERY. Their dedication to helping individuals recover their stolen assets is truly commendable, and I am thankful to have found them. In conclusion, my experience with CHAINTRACE ASSET RECOVERY has been nothing short of exceptional. Their professionalism, expertise, and commitment to recovering lost cryptocurrencies have made a significant difference in my life. If you are a victim of cryptocurrency scams, do not lose hope. Reach out to CHAINTRACE ASSET RECOVERY, and let their team of experts help you recover your stolen assets. WHATSAPP : +1 (581) 256‑1989 EMAIL: chaintraceasset(a)post.com WEBSITE: ‪https://chaintraceassetrecovery.com

6 months, 2 weeks

[PATCH 0/9] accel: New driver for NXP's Neutron NPU

by Ioana Ciocoi-Radulescu

Introduce a new accel driver for the Neutron Neural Processing Unit (NPU), along with associated dt-bindings and DTS node. The first patch extends the GEM DMA helper APIs to allow bidirectional mapping of non-coherent DMA buffers. While not part of the Neutron driver, it's a prerequisite allowing us to use the GEM DMA helper. Neutron is a Neural Processing Unit from NXP, providing machine learning (ML) acceleration for edge AI applications. Neutron is integrated on NXP SoCs such as the i.MX95. The NPU consists of the following: - RISC-V core running a proprietary firmware - One or more Neutron cores, representing the main computation engine performing ML operations - Dedicated fast memory (TCM) - DMA engine that handles data transfers between DDR and TCM The firmware is closed source and distributed as a binary here [1]. The Neutron software stack also contains a userspace library [1] and a LiteRT custom delegate [2] that allow integration with standard LiteRT tools. [1] https://github.com/nxp-upstream/neutron/tree/upstream [2] https://github.com/nxp-imx/tflite-neutron-delegate Signed-off-by: Ioana Ciocoi-Radulescu <ruxandra.radulescu(a)nxp.com> --- Ioana Ciocoi-Radulescu (9): drm/gem-dma: Add flag for bidirectional mapping of non-coherent GEM DMA buffers accel/neutron: Add documentation for NXP Neutron accelerator driver dt-bindings: npu: Add bindings for NXP Neutron accel/neutron: Add driver for NXP Neutron NPU accel/neutron: Add GEM buffer object support accel/neutron: Add mailbox support accel/neutron: Add job submission IOCTL accel/neutron: Add logging support arm64: dts: imx95: Add Neutron node Documentation/accel/index.rst | 1 + Documentation/accel/neutron/index.rst | 12 + Documentation/accel/neutron/neutron.rst | 131 ++++++++ .../devicetree/bindings/npu/nxp,imx95-neutron.yaml | 95 ++++++ MAINTAINERS | 10 + arch/arm64/boot/dts/freescale/imx95.dtsi | 28 ++ drivers/accel/Kconfig | 1 + drivers/accel/Makefile | 3 +- drivers/accel/neutron/Kconfig | 16 + drivers/accel/neutron/Makefile | 12 + drivers/accel/neutron/neutron_debugfs.c | 34 ++ drivers/accel/neutron/neutron_debugfs.h | 15 + drivers/accel/neutron/neutron_device.c | 239 ++++++++++++++ drivers/accel/neutron/neutron_device.h | 158 +++++++++ drivers/accel/neutron/neutron_driver.c | 262 +++++++++++++++ drivers/accel/neutron/neutron_driver.h | 16 + drivers/accel/neutron/neutron_gem.c | 115 +++++++ drivers/accel/neutron/neutron_gem.h | 14 + drivers/accel/neutron/neutron_job.c | 367 +++++++++++++++++++++ drivers/accel/neutron/neutron_job.h | 45 +++ drivers/accel/neutron/neutron_mailbox.c | 47 +++ drivers/accel/neutron/neutron_mailbox.h | 42 +++ drivers/gpu/drm/drm_gem_dma_helper.c | 6 +- include/drm/drm_gem_dma_helper.h | 3 + include/uapi/drm/neutron_accel.h | 130 ++++++++ 25 files changed, 1799 insertions(+), 3 deletions(-) --- base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f change-id: 20260226-neutron-c435e39d167f Best regards, -- Ioana Ciocoi-Radulescu <ruxandra.radulescu(a)nxp.com>

6 months, 2 weeks

[PATCH v2 0/9] dma-buf: heaps: Turn heaps into modules

by Maxime Ripard

Hi, The recent introduction of heaps in the optee driver [1] made possible the creation of heaps as modules. It's generally a good idea if possible, including for the already existing system and CMA heaps. The system one is pretty trivial, the CMA one is a bit more involved, especially since we have a call from kernel/dma/contiguous.c to the CMA heap code. This was solved by turning the logic around and making the CMA heap call into the contiguous DMA code. Let me know what you think, Maxime 1: https://lore.kernel.org/dri-devel/20250911135007.1275833-4-jens.wiklander@l… Signed-off-by: Maxime Ripard <mripard(a)kernel.org> --- Changes in v2: - Collect tags - Don't export dma_contiguous_default_area anymore, but export dev_get_cma_area instead - Mentioned that heap modules can't be removed - Link to v1: https://lore.kernel.org/r/20260225-dma-buf-heaps-as-modules-v1-0-2109225a09… --- Maxime Ripard (9): dma: contiguous: Turn heap registration logic around dma: contiguous: Make dev_get_cma_area() a proper function dma: contiguous: Make dma_contiguous_default_area static mm: cma: Export dev_get_cma_area() mm: cma: Export cma_alloc and cma_release mm: cma: Export cma_get_name dma-buf: heaps: Export mem_accounting parameter dma-buf: heaps: cma: Turn the heap into a module dma-buf: heaps: system: Turn the heap into a module drivers/dma-buf/dma-heap.c | 1 + drivers/dma-buf/heaps/Kconfig | 4 ++-- drivers/dma-buf/heaps/cma_heap.c | 21 +++++---------------- drivers/dma-buf/heaps/system_heap.c | 5 +++++ include/linux/dma-map-ops.h | 14 ++++++-------- kernel/dma/contiguous.c | 37 ++++++++++++++++++++++++++++++++++--- mm/cma.c | 3 +++ 7 files changed, 56 insertions(+), 29 deletions(-) --- base-commit: 499a718536dc0e1c1d1b6211847207d58acd9916 change-id: 20260225-dma-buf-heaps-as-modules-1034b3ec9f2a Best regards, -- Maxime Ripard <mripard(a)kernel.org>

6 months, 2 weeks

WHAT CAN I DO TO RECOVER MY SCAMMED CRYPTO

by va7325462＠gmail.com

After losing $350,000 in a fraudulent cryptocurrency scheme, I felt completely defeated. Instead of acting out of panic, I forced myself to slow down and investigate carefully. Through research and conversations with other victims then I came across a Google post It was only after spending many hours researching and asking other victims for advice that I discovered vaulttraces.com. I decided to contact them because of their successful recovery record and encouraging client testimonials. I had no idea that this would be the pivotal moment in my fight against cryptocurrency theft. Thanks to their expert team, I was able to recover my lost cryptocurrency back.The process was intricate, but vaulttraces.com commitment to utilizing the latest technology ensured a successful outcome. I highly recommend their services to anyone who has fallen victim to cryptocurrency fraud. For assistance REACH OUT TO THEM ON their Website;: https://vaulttraces.com/contact.html . Mail-Box: info(a)vaulttraces.com . Or WhatsApp: +1 (570) 291-8211

6 months, 2 weeks

WHAT CAN I DO TO RECOVER MY SCAMMED CRYPTO

by va7325462＠gmail.com

6 months, 2 weeks

WHAT CAN I DO TO RECOVER MY SCAMMED BITCOIN

by christaenssa＠gmail.com

I was recently scammed out of $400,000 through what appeared to be a legitimate Bitcoin investment opportunity. At the same time, I was dealing with serious health challenges and upcoming medical expenses, which made the situation even more devastating. I felt overwhelmed and desperate for answers. I spent countless hours researching, speaking with other victims, and trying to understand what options were truly legitimate. That experience taught me how important it is to verify every opportunity and to report fraud immediately through proper legal channels. I came across a Google post It was only after spending many hours researching and asking other victims for advice that I discovered vaulttraces.com. I decided to contact them because of their successful recovery record and encouraging client testimonials. I had no idea that this would be the pivotal moment in my fight against cryptocurrency theft. Thanks to their expert team, I was able to recover my lost cryptocurrency back.The process was intricate, but vaulttraces.com commitment to utilizing the latest technology ensured a successful outcome. I highly recommend their services to anyone who has fallen victim to cryptocurrency fraud. For assistance REACH OUT TO THEM ON their Website;: https://vaulttraces.com/contact.html . Mail-Box: info(a)vaulttraces.com . Or WhatsApp: +1 (570) 291-8211

6 months, 3 weeks

HIRE ALMIGHTY RECOVERY COIN,THE BEST CERTIFIED HACKER FOR CRYPTOCURRENCY RECOVERY.

by laurenjones545648＠gmail.com

I want to sincerely thank Almighty Recovery Coin professionals for their incredible skill; they are truly outstanding individuals and I wish I had gotten in touch with them sooner rather than reaching out to other cybercriminals for help. If you read this comment, you will definitely be able to recover your stolen or restricted cryptocurrency investment. I am posting it for people who have been affected by cryptocurrency mining, trading, Investments and financial scams. Email: almightyrecoverycoin(@) mail . (com) Website: almightyrecoveryco.wixsite.com/almighty-recovery-co WhatsApp: +53 5 (155) 6969

6 months, 3 weeks

[RFC PATCH 0/7] vfio/pci: Add mmap() for DMABUFs

by Matt Evans

Hi all, There were various suggestions in the September 2025 thread "[TECH TOPIC] vfio, iommufd: Enabling user space drivers to vend more granular access to client processes" [0], and LPC discussions, around improving the situation for multi-process userspace driver designs. This RFC series implements some of these ideas. Background: Multi-process USDs ============================== The userspace driver scenario discussed in that thread involves a primary process driving a PCIe function through VFIO/iommufd, which manages the function-wide ownership/lifecycle. The function is designed to provide multiple distinct programming interfaces (for example, several independent MMIO register frames in one function), and the primary process delegates control of these interfaces to multiple independent client processes (which do the actual work). This scenario clearly relies on a HW design that provides appropriate isolation between the programming interfaces. The two key needs are: 1. Mechanisms to safely delegate a subset of the device MMIO resources to a client process without over-sharing wider access (or influence over whole-device activities, such as reset). 2. Mechanisms to allow a client process to do its own iommufd management w.r.t. its address space, in a way that's isolated from DMA relating to other clients. mmap() of VFIO DMABUFs ====================== First, this RFC addresses #1, implementing the proposals in [0] to add mmap() support to the existing VFIO DMABUF exporter. This enables a userspace driver to define DMABUF ranges corresponding to sub-ranges of a BAR, and grant a given client (via a shared fd) the capability to access (only) those sub-ranges. The VFIO device fds would be kept private to the primary process. All the client can do with that fd is map (or iomap via iommufd) that specific subset of resources, and the impact of bugs/malice is contained. (We'll follow up on #2 separately, as a related-but-distinct problem. PASIDs are one way to achieve per-client isolation of DMA; another could be sharing of a single IOVA space via 'constrained' iommufds.) Revocation/reclaim ================== That's useful as-is, but then the lifetime of access granted to a client needs to be managed well. For example, a protocol between the primary process and the client can indicate when the client is done, and when it's safe to reuse the resources elsewhere. Resources could be released cooperatively, but it's much more robust to enable the driver to make the resources guaranteed-inaccessible when it chooses, so that it can re-assign them to other uses in future. So, second, I've suggested a PoC/example mechanism for reclaiming ranges shared with clients: a new DMABUF ioctl, DMA_BUF_IOCTL_REVOKE, is routed to a DMABUF exporter callback. The VFIO DMABUF exporter's implementation permanently revokes a DMABUF (notifying importers, and zapping PTEs for any mappings). This makes the DMABUF defunct and any client (or third party the client has shared the buffer onto!) cannot be used to access the BAR ranges, whether via DMABUF import or mmap(). A primary driver process would do this operation when the client's tenure ends to reclaim "loaned-out" MMIO interfaces, at which point the interfaces could be safely re-used. This ioctl is one of several possible approaches to achieve buffer revocation, but I wanted to demonstrate something here as it's an important part of the buffer lifecycle in this driver scenario. An alternative implementation could be some VFIO-specific operation to search for a DMABUF (by address?) and kill it, but if the server keeps hold of the DMABUF fd that's already a clean way to locate it later. BAR mapping access attributes ============================= Third, inspired by Alex [Mastro] and Jason's comments in [0], and Mahmoud's work in [1] with the goal of controlling CPU access attributes for VFIO BAR mappings (e.g. WC) I noticed that once we can mmap() VFIO DMABUFs representing BAR sub-spans, it's straightforward to decorate them with access attributes for the VMA. I've proposed reserving a field in struct vfio_device_feature_dma_buf's flags to specify an attribute for its ranges. Although that keeps the (UAPI) struct unchanged, it means all ranges in a DMABUF share the same attribute. I feel a single attribute-to-mmap() relation is logical/reasonable. An application can also create multiple DMABUFs to describe any BAR layout and mix of attributes. Tests ===== I've included an [RFC ONLY] userspace test program which I am _not_ proposing to merge, but am sharing for context. It illustrates & tests various map/revoke cases, but doesn't use the existing VFIO selftests and relies on a (tweaked) QEMU EDU function. I'm working on integrating the scenarios into the existing VFIO selftests. This code has been tested in mapping DMABUFs of single/multiple ranges, aliasing mmap()s, aliasing ranges across DMABUFs, vm_pgoff > 0, revocation, shutdown/cleanup scenarios, and hugepage mappings seem to work correctly. I've lightly tested WC mappings also (by observing resulting PTEs as having the correct attributes...). (The first two commits are a couple of tiny bugfixes which I can send separately, should reviewers prefer.) This series is based on v6.19 but I expect to rebase, at least onto Leon's recent work [2] ("vfio: Wait for dma-buf invalidation to complete"). What are people's thoughts? I'll respin to de-RFC and capture comments, if we think this approach is appropriate. Thanks, Matt References: [0]: https://lore.kernel.org/linux-iommu/20250918214425.2677057-1-amastro@fb.com/ [1]: https://lore.kernel.org/all/20250804104012.87915-1-mngyadam@amazon.de/ [2]: https://lore.kernel.org/linux-iommu/20260205-nocturnal-poetic-chamois-f566a… Matt Evans (7): vfio/pci: Ensure VFIO barmap is set up before creating a DMABUF vfio/pci: Clean up DMABUFs before disabling function vfio/pci: Support mmap() of a DMABUF dma-buf: uapi: Mechanism to revoke DMABUFs via ioctl() vfio/pci: Permanently revoke a DMABUF on request vfio/pci: Add mmap() attributes to DMABUF feature [RFC ONLY] selftests: vfio: Add standalone vfio_dmabuf_mmap_test drivers/dma-buf/dma-buf.c | 5 + drivers/vfio/pci/vfio_pci_core.c | 4 +- drivers/vfio/pci/vfio_pci_dmabuf.c | 300 ++++++- include/linux/dma-buf.h | 22 + include/uapi/linux/dma-buf.h | 1 + include/uapi/linux/vfio.h | 12 +- tools/testing/selftests/vfio/Makefile | 1 + .../vfio/standalone/vfio_dmabuf_mmap_test.c | 822 ++++++++++++++++++ 8 files changed, 1153 insertions(+), 14 deletions(-) create mode 100644 tools/testing/selftests/vfio/standalone/vfio_dmabuf_mmap_test.c -- 2.47.3

6 months, 3 weeks

[PATCH 00/61] vfs: change inode->i_ino from unsigned long to u64

by Jeff Layton

Christian said [1] to "just do it" when I proposed this, so here we are! For historical reasons, the inode->i_ino field is an unsigned long, which means that it's 32 bits on 32 bit architectures. This has caused a number of filesystems to implement hacks to hash a 64-bit identifier into a 32-bit field, and deprives us of a universal identifier field for an inode. This patchset changes the inode->i_ino field from an unsigned long to a u64. This shouldn't make any material difference on 64-bit hosts, but 32-bit hosts will see struct inode grow by at least 4 bytes. This could have effects on slabcache sizes and field alignment. The bulk of the changes are to format strings and tracepoints, since the kernel itself doesn't care that much about the i_ino field. The first patch changes some vfs function arguments, so check that one out carefully. With this change, we may be able to shrink some inode structures. For instance, struct nfs_inode has a fileid field that holds the 64-bit inode number. With this set of changes, that field could be eliminated. I'd rather leave that sort of cleanups for later just to keep this simple. Much of this set was generated by LLM, but I attributed it to myself since I consider this to be in the "menial tasks" category of LLM usage. [1]: https://lore.kernel.org/linux-fsdevel/20260219-portrait-winkt-959070cee42f@… Signed-off-by: Jeff Layton <jlayton(a)kernel.org> --- Jeff Layton (61): vfs: widen inode hash/lookup functions to u64 vfs: change i_ino from unsigned long to u64 trace: update VFS-layer trace events for u64 i_ino ext4: update for u64 i_ino jbd2: update format strings for u64 i_ino f2fs: update for u64 i_ino lockd: update format strings for u64 i_ino nfs: update for u64 i_ino nfs: remove nfs_fattr_to_ino_t() and nfs_fileid_to_ino_t() nfs: remove nfs_compat_user_ino64() nfs: remove enable_ino64 module parameter nfsd: update format strings for u64 i_ino smb: store full 64-bit uniqueid in i_ino smb: remove cifs_uniqueid_to_ino_t() locks: update /proc/locks format for u64 i_ino proc: update /proc/PID/maps for u64 i_ino nilfs2: update for u64 i_ino 9p: update format strings for u64 i_ino affs: update format strings for u64 i_ino afs: update format strings for u64 i_ino autofs: update format strings for u64 i_ino befs: update format strings for u64 i_ino bfs: update format strings for u64 i_ino cachefiles: update format strings for u64 i_ino ceph: update format strings for u64 i_ino coda: update format strings for u64 i_ino cramfs: update format strings for u64 i_ino ecryptfs: update format strings for u64 i_ino efs: update format strings for u64 i_ino exportfs: update format strings for u64 i_ino ext2: update format strings for u64 i_ino freevxfs: update format strings for u64 i_ino hfs: update format strings for u64 i_ino hfsplus: update format strings for u64 i_ino hpfs: update format strings for u64 i_ino isofs: update format strings for u64 i_ino jffs2: update format strings for u64 i_ino jfs: update format strings for u64 i_ino minix: update format strings for u64 i_ino nsfs: update format strings for u64 i_ino ntfs3: update format strings for u64 i_ino ocfs2: update format strings for u64 i_ino orangefs: update format strings for u64 i_ino overlayfs: update format strings for u64 i_ino qnx4: update format strings for u64 i_ino qnx6: update format strings for u64 i_ino ubifs: update format strings for u64 i_ino udf: update format strings for u64 i_ino ufs: update format strings for u64 i_ino zonefs: update format strings for u64 i_ino security: update audit format strings for u64 i_ino drm/amdgpu: update for u64 i_ino fsnotify: update fdinfo format strings for u64 i_ino net: update socket dname format for u64 i_ino uprobes: update format strings for u64 i_ino dma-buf: update format string for u64 i_ino fscrypt: update format strings for u64 i_ino fsverity: update format string for u64 i_ino iomap: update format string for u64 i_ino net: update legacy protocol format strings for u64 i_ino vfs: update core format strings for u64 i_ino drivers/dma-buf/dma-buf.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 +- fs/9p/vfs_addr.c | 4 +- fs/9p/vfs_inode.c | 6 +- fs/9p/vfs_inode_dotl.c | 6 +- fs/affs/amigaffs.c | 8 +- fs/affs/bitmap.c | 2 +- fs/affs/dir.c | 2 +- fs/affs/file.c | 20 +- fs/affs/inode.c | 12 +- fs/affs/namei.c | 14 +- fs/affs/symlink.c | 2 +- fs/afs/dir.c | 10 +- fs/afs/dir_search.c | 2 +- fs/afs/dynroot.c | 2 +- fs/afs/inode.c | 2 +- fs/autofs/inode.c | 2 +- fs/befs/linuxvfs.c | 28 +- fs/bfs/dir.c | 4 +- fs/cachefiles/io.c | 6 +- fs/cachefiles/namei.c | 12 +- fs/cachefiles/xattr.c | 2 +- fs/ceph/crypto.c | 4 +- fs/coda/dir.c | 2 +- fs/coda/inode.c | 2 +- fs/cramfs/inode.c | 2 +- fs/crypto/crypto.c | 2 +- fs/crypto/hooks.c | 2 +- fs/crypto/keysetup.c | 2 +- fs/dcache.c | 4 +- fs/ecryptfs/crypto.c | 6 +- fs/ecryptfs/file.c | 2 +- fs/efs/inode.c | 6 +- fs/eventpoll.c | 2 +- fs/exportfs/expfs.c | 4 +- fs/ext2/dir.c | 10 +- fs/ext2/ialloc.c | 9 +- fs/ext2/inode.c | 2 +- fs/ext2/xattr.c | 14 +- fs/ext4/dir.c | 2 +- fs/ext4/ext4.h | 4 +- fs/ext4/extents.c | 8 +- fs/ext4/extents_status.c | 28 +- fs/ext4/fast_commit.c | 8 +- fs/ext4/ialloc.c | 10 +- fs/ext4/indirect.c | 2 +- fs/ext4/inline.c | 14 +- fs/ext4/inode.c | 22 +- fs/ext4/ioctl.c | 4 +- fs/ext4/mballoc.c | 6 +- fs/ext4/migrate.c | 2 +- fs/ext4/move_extent.c | 20 +- fs/ext4/namei.c | 10 +- fs/ext4/orphan.c | 16 +- fs/ext4/page-io.c | 10 +- fs/ext4/super.c | 22 +- fs/ext4/xattr.c | 10 +- fs/f2fs/compress.c | 4 +- fs/f2fs/dir.c | 2 +- fs/f2fs/extent_cache.c | 8 +- fs/f2fs/f2fs.h | 6 +- fs/f2fs/file.c | 12 +- fs/f2fs/gc.c | 2 +- fs/f2fs/inline.c | 4 +- fs/f2fs/inode.c | 48 ++-- fs/f2fs/namei.c | 8 +- fs/f2fs/node.c | 12 +- fs/f2fs/recovery.c | 10 +- fs/f2fs/xattr.c | 10 +- fs/freevxfs/vxfs_bmap.c | 4 +- fs/fserror.c | 2 +- fs/hfs/catalog.c | 2 +- fs/hfs/extent.c | 4 +- fs/hfs/inode.c | 4 +- fs/hfsplus/attributes.c | 10 +- fs/hfsplus/catalog.c | 2 +- fs/hfsplus/dir.c | 6 +- fs/hfsplus/extents.c | 6 +- fs/hfsplus/inode.c | 8 +- fs/hfsplus/super.c | 6 +- fs/hfsplus/xattr.c | 10 +- fs/hpfs/dir.c | 4 +- fs/hpfs/dnode.c | 4 +- fs/hpfs/ea.c | 4 +- fs/hpfs/inode.c | 4 +- fs/inode.c | 46 ++-- fs/iomap/ioend.c | 2 +- fs/isofs/compress.c | 2 +- fs/isofs/dir.c | 2 +- fs/isofs/inode.c | 6 +- fs/isofs/namei.c | 2 +- fs/jbd2/journal.c | 4 +- fs/jbd2/transaction.c | 2 +- fs/jffs2/dir.c | 4 +- fs/jffs2/file.c | 4 +- fs/jffs2/fs.c | 18 +- fs/jfs/inode.c | 2 +- fs/jfs/jfs_imap.c | 2 +- fs/jfs/jfs_metapage.c | 2 +- fs/lockd/svclock.c | 8 +- fs/lockd/svcsubs.c | 2 +- fs/locks.c | 6 +- fs/minix/inode.c | 10 +- fs/nfs/dir.c | 22 +- fs/nfs/file.c | 8 +- fs/nfs/filelayout/filelayout.c | 8 +- fs/nfs/flexfilelayout/flexfilelayout.c | 8 +- fs/nfs/inode.c | 54 +--- fs/nfs/nfs4proc.c | 4 +- fs/nfs/pnfs.c | 12 +- fs/nfsd/export.c | 2 +- fs/nfsd/nfs4state.c | 4 +- fs/nfsd/nfsfh.c | 4 +- fs/nfsd/vfs.c | 2 +- fs/nilfs2/alloc.c | 10 +- fs/nilfs2/bmap.c | 2 +- fs/nilfs2/btnode.c | 2 +- fs/nilfs2/btree.c | 12 +- fs/nilfs2/dir.c | 12 +- fs/nilfs2/direct.c | 4 +- fs/nilfs2/gcinode.c | 2 +- fs/nilfs2/inode.c | 8 +- fs/nilfs2/mdt.c | 2 +- fs/nilfs2/namei.c | 2 +- fs/nilfs2/segment.c | 2 +- fs/notify/fdinfo.c | 4 +- fs/nsfs.c | 4 +- fs/ntfs3/super.c | 2 +- fs/ocfs2/alloc.c | 2 +- fs/ocfs2/aops.c | 4 +- fs/ocfs2/dir.c | 8 +- fs/ocfs2/dlmfs/dlmfs.c | 10 +- fs/ocfs2/extent_map.c | 12 +- fs/ocfs2/inode.c | 2 +- fs/ocfs2/quota_local.c | 2 +- fs/ocfs2/refcounttree.c | 10 +- fs/ocfs2/xattr.c | 4 +- fs/orangefs/inode.c | 2 +- fs/overlayfs/export.c | 2 +- fs/overlayfs/namei.c | 4 +- fs/overlayfs/util.c | 2 +- fs/pipe.c | 2 +- fs/proc/fd.c | 2 +- fs/proc/task_mmu.c | 4 +- fs/qnx4/inode.c | 4 +- fs/qnx6/inode.c | 2 +- fs/smb/client/cifsfs.h | 17 -- fs/smb/client/inode.c | 6 +- fs/smb/client/readdir.c | 2 +- fs/ubifs/debug.c | 8 +- fs/ubifs/dir.c | 28 +- fs/ubifs/file.c | 28 +- fs/ubifs/journal.c | 6 +- fs/ubifs/super.c | 16 +- fs/ubifs/tnc.c | 4 +- fs/ubifs/xattr.c | 14 +- fs/udf/directory.c | 18 +- fs/udf/file.c | 2 +- fs/udf/inode.c | 12 +- fs/udf/namei.c | 8 +- fs/udf/super.c | 2 +- fs/ufs/balloc.c | 6 +- fs/ufs/dir.c | 10 +- fs/ufs/ialloc.c | 6 +- fs/ufs/inode.c | 18 +- fs/ufs/ufs_fs.h | 6 +- fs/ufs/util.c | 2 +- fs/verity/init.c | 2 +- fs/zonefs/super.c | 8 +- include/linux/fs.h | 28 +- include/linux/nfs_fs.h | 10 - include/trace/events/cachefiles.h | 18 +- include/trace/events/ext4.h | 427 +++++++++++++++-------------- include/trace/events/f2fs.h | 172 ++++++------ include/trace/events/filelock.h | 16 +- include/trace/events/filemap.h | 20 +- include/trace/events/fs_dax.h | 20 +- include/trace/events/fsverity.h | 30 +- include/trace/events/hugetlbfs.h | 28 +- include/trace/events/netfs.h | 4 +- include/trace/events/nilfs2.h | 12 +- include/trace/events/readahead.h | 12 +- include/trace/events/timestamp.h | 12 +- include/trace/events/writeback.h | 148 +++++----- kernel/events/uprobes.c | 4 +- net/netrom/af_netrom.c | 4 +- net/rose/af_rose.c | 4 +- net/socket.c | 2 +- net/x25/x25_proc.c | 4 +- security/apparmor/apparmorfs.c | 4 +- security/integrity/integrity_audit.c | 2 +- security/ipe/audit.c | 2 +- security/lsm_audit.c | 10 +- security/selinux/hooks.c | 4 +- security/smack/smack_lsm.c | 12 +- 195 files changed, 1101 insertions(+), 1166 deletions(-) --- base-commit: 2bf35e96cf6c6c3a290b69b777d34be15888e364 change-id: 20260224-iino-u64-b44a3a72543c Best regards, -- Jeff Layton <jlayton(a)kernel.org>

6 months, 3 weeks

[PATCH] dma-buf: heaps: Add Coherent heap to dmabuf heaps

by Albert Esteve

Add a dma-buf heap for DT coherent reserved-memory (i.e., 'shared-dma-pool' without 'reusable' property), exposing one heap per region for userspace buffers. The heap binds a synthetic platform device to each region so coherent allocations use the correct dev->dma_mem, and it defers registration until late_initcall when normal allocator are available. This patch includes charging of the coherent heap allocator to the dmem cgroup. Signed-off-by: Albert Esteve <aesteve(a)redhat.com> --- This patch introduces a new driver to expose DT coherent reserved-memory regions as dma-buf heaps, allowing userspace buffers to be created. Since these regions are device-dependent, we bind a synthetic platform device to each region so coherent allocations use the correct dev->dma_mem. Following Eric’s [1] and Maxime’s [2] work on charging DMA buffers allocated from userspace to cgroups (dmem), this patch adds the same charging pattern used by CMA heaps patch. Charging is done only through the dma-buf heap interface so it can be attributed to a userspace allocator. This allows each device-specific reserved-memory region to enforce its own limits. [1] https://lore.kernel.org/all/20260218-dmabuf-heap-cma-dmem-v2-0-b249886fb7b2… [2] https://lore.kernel.org/all/20250310-dmem-cgroups-v1-0-2984c1bc9312@kernel.… --- drivers/dma-buf/heaps/Kconfig | 17 ++ drivers/dma-buf/heaps/Makefile | 1 + drivers/dma-buf/heaps/coherent_heap.c | 485 ++++++++++++++++++++++++++++++++++ include/linux/dma-heap.h | 11 + kernel/dma/coherent.c | 9 + 5 files changed, 523 insertions(+) diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig index a5eef06c42264..93765dca164e3 100644 --- a/drivers/dma-buf/heaps/Kconfig +++ b/drivers/dma-buf/heaps/Kconfig @@ -12,3 +12,20 @@ config DMABUF_HEAPS_CMA Choose this option to enable dma-buf CMA heap. This heap is backed by the Contiguous Memory Allocator (CMA). If your system has these regions, you should say Y here. + +config DMABUF_HEAPS_COHERENT + bool "DMA-BUF Coherent Reserved-Memory Heap" + depends on DMABUF_HEAPS && OF_RESERVED_MEM && DMA_DECLARE_COHERENT + help + Choose this option to enable coherent reserved-memory dma-buf heaps. + This heap is backed by non-reusable DT "shared-dma-pool" regions. + If your system defines coherent reserved-memory regions, you should + say Y here. + +config COHERENT_AREAS_DEFERRED + int "Max deferred coherent reserved-memory regions" + depends on DMABUF_HEAPS_COHERENT + default 16 + help + Maximum number of coherent reserved-memory regions that can be + deferred for later registration during early boot. diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile index 974467791032f..96bda7a65f041 100644 --- a/drivers/dma-buf/heaps/Makefile +++ b/drivers/dma-buf/heaps/Makefile @@ -1,3 +1,4 @@ # SPDX-License-Identifier: GPL-2.0 obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o +obj-$(CONFIG_DMABUF_HEAPS_COHERENT) += coherent_heap.o diff --git a/drivers/dma-buf/heaps/coherent_heap.c b/drivers/dma-buf/heaps/coherent_heap.c new file mode 100644 index 0000000000000..870b2b89aefcb --- /dev/null +++ b/drivers/dma-buf/heaps/coherent_heap.c @@ -0,0 +1,485 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * DMABUF heap for coherent reserved-memory regions + * + * Copyright (C) 2026 Red Hat, Inc. + * Author: Albert Esteve <aesteve(a)redhat.com> + * + */ + +#include <linux/cgroup_dmem.h> +#include <linux/dma-heap.h> +#include <linux/dma-buf.h> +#include <linux/dma-mapping.h> +#include <linux/err.h> +#include <linux/highmem.h> +#include <linux/iosys-map.h> +#include <linux/of_reserved_mem.h> +#include <linux/platform_device.h> +#include <linux/scatterlist.h> +#include <linux/slab.h> +#include <linux/vmalloc.h> + +#define DEFERRED_AREAS_MAX CONFIG_COHERENT_AREAS_DEFERRED + +/* + * Early init can't use normal memory management yet (memblock is used + * instead), so keep a small deferred list and retry at late_initcall. + */ +static struct reserved_mem *rmem_areas_deferred[DEFERRED_AREAS_MAX]; +static unsigned int rmem_areas_deferred_num; + +static int coherent_heap_add_deferred(struct reserved_mem *rmem) +{ + if (rmem_areas_deferred_num >= DEFERRED_AREAS_MAX) { + pr_warn("Deferred heap areas list full, dropping %s\n", + rmem->name ? rmem->name : "unknown"); + return -EINVAL; + } + rmem_areas_deferred[rmem_areas_deferred_num++] = rmem; + return 0; +} + +struct coherent_heap { + struct dma_heap *heap; + struct reserved_mem *rmem; + char *name; + struct device *dev; + struct platform_device *pdev; +#if IS_ENABLED(CONFIG_CGROUP_DMEM) + struct dmem_cgroup_region *cg; +#endif +}; + +struct coherent_heap_buffer { + struct coherent_heap *heap; + struct list_head attachments; + struct mutex lock; + unsigned long len; + dma_addr_t dma_addr; + void *alloc_vaddr; + struct page **pages; + pgoff_t pagecount; + int vmap_cnt; + void *vaddr; +#if IS_ENABLED(CONFIG_CGROUP_DMEM) + struct dmem_cgroup_pool_state *pool; +#endif +}; + +struct dma_heap_attachment { + struct device *dev; + struct sg_table table; + struct list_head list; + bool mapped; +}; + +static int coherent_heap_attach(struct dma_buf *dmabuf, + struct dma_buf_attachment *attachment) +{ + struct coherent_heap_buffer *buffer = dmabuf->priv; + struct dma_heap_attachment *a; + int ret; + + a = kzalloc_obj(*a); + if (!a) + return -ENOMEM; + + ret = sg_alloc_table_from_pages(&a->table, buffer->pages, + buffer->pagecount, 0, + buffer->pagecount << PAGE_SHIFT, + GFP_KERNEL); + if (ret) { + kfree(a); + return ret; + } + + a->dev = attachment->dev; + INIT_LIST_HEAD(&a->list); + a->mapped = false; + + attachment->priv = a; + + mutex_lock(&buffer->lock); + list_add(&a->list, &buffer->attachments); + mutex_unlock(&buffer->lock); + + return 0; +} + +static void coherent_heap_detach(struct dma_buf *dmabuf, + struct dma_buf_attachment *attachment) +{ + struct coherent_heap_buffer *buffer = dmabuf->priv; + struct dma_heap_attachment *a = attachment->priv; + + mutex_lock(&buffer->lock); + list_del(&a->list); + mutex_unlock(&buffer->lock); + + sg_free_table(&a->table); + kfree(a); +} + +static struct sg_table *coherent_heap_map_dma_buf(struct dma_buf_attachment *attachment, + enum dma_data_direction direction) +{ + struct dma_heap_attachment *a = attachment->priv; + struct sg_table *table = &a->table; + int ret; + + ret = dma_map_sgtable(attachment->dev, table, direction, 0); + if (ret) + return ERR_PTR(-ENOMEM); + a->mapped = true; + + return table; +} + +static void coherent_heap_unmap_dma_buf(struct dma_buf_attachment *attachment, + struct sg_table *table, + enum dma_data_direction direction) +{ + struct dma_heap_attachment *a = attachment->priv; + + a->mapped = false; + dma_unmap_sgtable(attachment->dev, table, direction, 0); +} + +static int coherent_heap_dma_buf_begin_cpu_access(struct dma_buf *dmabuf, + enum dma_data_direction direction) +{ + struct coherent_heap_buffer *buffer = dmabuf->priv; + struct dma_heap_attachment *a; + + mutex_lock(&buffer->lock); + if (buffer->vmap_cnt) + invalidate_kernel_vmap_range(buffer->vaddr, buffer->len); + + list_for_each_entry(a, &buffer->attachments, list) { + if (!a->mapped) + continue; + dma_sync_sgtable_for_cpu(a->dev, &a->table, direction); + } + mutex_unlock(&buffer->lock); + + return 0; +} + +static int coherent_heap_dma_buf_end_cpu_access(struct dma_buf *dmabuf, + enum dma_data_direction direction) +{ + struct coherent_heap_buffer *buffer = dmabuf->priv; + struct dma_heap_attachment *a; + + mutex_lock(&buffer->lock); + if (buffer->vmap_cnt) + flush_kernel_vmap_range(buffer->vaddr, buffer->len); + + list_for_each_entry(a, &buffer->attachments, list) { + if (!a->mapped) + continue; + dma_sync_sgtable_for_device(a->dev, &a->table, direction); + } + mutex_unlock(&buffer->lock); + + return 0; +} + +static int coherent_heap_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma) +{ + struct coherent_heap_buffer *buffer = dmabuf->priv; + struct coherent_heap *coh_heap = buffer->heap; + + return dma_mmap_coherent(coh_heap->dev, vma, buffer->alloc_vaddr, + buffer->dma_addr, buffer->len); +} + +static void *coherent_heap_do_vmap(struct coherent_heap_buffer *buffer) +{ + void *vaddr; + + vaddr = vmap(buffer->pages, buffer->pagecount, VM_MAP, PAGE_KERNEL); + if (!vaddr) + return ERR_PTR(-ENOMEM); + + return vaddr; +} + +static int coherent_heap_vmap(struct dma_buf *dmabuf, struct iosys_map *map) +{ + struct coherent_heap_buffer *buffer = dmabuf->priv; + void *vaddr; + int ret = 0; + + mutex_lock(&buffer->lock); + if (buffer->vmap_cnt) { + buffer->vmap_cnt++; + iosys_map_set_vaddr(map, buffer->vaddr); + goto out; + } + + vaddr = coherent_heap_do_vmap(buffer); + if (IS_ERR(vaddr)) { + ret = PTR_ERR(vaddr); + goto out; + } + + buffer->vaddr = vaddr; + buffer->vmap_cnt++; + iosys_map_set_vaddr(map, buffer->vaddr); +out: + mutex_unlock(&buffer->lock); + + return ret; +} + +static void coherent_heap_vunmap(struct dma_buf *dmabuf, struct iosys_map *map) +{ + struct coherent_heap_buffer *buffer = dmabuf->priv; + + mutex_lock(&buffer->lock); + if (!--buffer->vmap_cnt) { + vunmap(buffer->vaddr); + buffer->vaddr = NULL; + } + mutex_unlock(&buffer->lock); + iosys_map_clear(map); +} + +static void coherent_heap_dma_buf_release(struct dma_buf *dmabuf) +{ + struct coherent_heap_buffer *buffer = dmabuf->priv; + struct coherent_heap *coh_heap = buffer->heap; + + if (buffer->vmap_cnt > 0) { + WARN(1, "%s: buffer still mapped in the kernel\n", __func__); + vunmap(buffer->vaddr); + buffer->vaddr = NULL; + buffer->vmap_cnt = 0; + } + + if (buffer->alloc_vaddr) + dma_free_coherent(coh_heap->dev, buffer->len, buffer->alloc_vaddr, + buffer->dma_addr); + kfree(buffer->pages); +#if IS_ENABLED(CONFIG_CGROUP_DMEM) + dmem_cgroup_uncharge(buffer->pool, buffer->len); +#endif + kfree(buffer); +} + +static const struct dma_buf_ops coherent_heap_buf_ops = { + .attach = coherent_heap_attach, + .detach = coherent_heap_detach, + .map_dma_buf = coherent_heap_map_dma_buf, + .unmap_dma_buf = coherent_heap_unmap_dma_buf, + .begin_cpu_access = coherent_heap_dma_buf_begin_cpu_access, + .end_cpu_access = coherent_heap_dma_buf_end_cpu_access, + .mmap = coherent_heap_mmap, + .vmap = coherent_heap_vmap, + .vunmap = coherent_heap_vunmap, + .release = coherent_heap_dma_buf_release, +}; + +static struct dma_buf *coherent_heap_allocate(struct dma_heap *heap, + unsigned long len, + u32 fd_flags, + u64 heap_flags) +{ + struct coherent_heap *coh_heap; + struct coherent_heap_buffer *buffer; + DEFINE_DMA_BUF_EXPORT_INFO(exp_info); + size_t size = PAGE_ALIGN(len); + pgoff_t pagecount = size >> PAGE_SHIFT; + struct dma_buf *dmabuf; + int ret = -ENOMEM; + pgoff_t pg; + + coh_heap = dma_heap_get_drvdata(heap); + if (!coh_heap) + return ERR_PTR(-EINVAL); + if (!coh_heap->dev) + return ERR_PTR(-ENODEV); + + buffer = kzalloc_obj(*buffer); + if (!buffer) + return ERR_PTR(-ENOMEM); + + INIT_LIST_HEAD(&buffer->attachments); + mutex_init(&buffer->lock); + buffer->len = size; + buffer->heap = coh_heap; + buffer->pagecount = pagecount; + +#if IS_ENABLED(CONFIG_CGROUP_DMEM) + if (mem_accounting) { + ret = dmem_cgroup_try_charge(coh_heap->cg, size, + &buffer->pool, NULL); + if (ret) + goto free_buffer; + } +#endif + + buffer->alloc_vaddr = dma_alloc_coherent(coh_heap->dev, buffer->len, + &buffer->dma_addr, GFP_KERNEL); + if (!buffer->alloc_vaddr) { + ret = -ENOMEM; +#if IS_ENABLED(CONFIG_CGROUP_DMEM) + goto uncharge_cgroup; +#else + goto free_buffer; +#endif + } + + buffer->pages = kmalloc_array(pagecount, sizeof(*buffer->pages), + GFP_KERNEL); + if (!buffer->pages) { + ret = -ENOMEM; + goto free_dma; + } + + for (pg = 0; pg < pagecount; pg++) + buffer->pages[pg] = virt_to_page((char *)buffer->alloc_vaddr + + (pg * PAGE_SIZE)); + + /* create the dmabuf */ + exp_info.exp_name = dma_heap_get_name(heap); + exp_info.ops = &coherent_heap_buf_ops; + exp_info.size = buffer->len; + exp_info.flags = fd_flags; + exp_info.priv = buffer; + dmabuf = dma_buf_export(&exp_info); + if (IS_ERR(dmabuf)) { + ret = PTR_ERR(dmabuf); + goto free_pages; + } + return dmabuf; + +free_pages: + kfree(buffer->pages); +free_dma: + dma_free_coherent(coh_heap->dev, buffer->len, buffer->alloc_vaddr, + buffer->dma_addr); +#if IS_ENABLED(CONFIG_CGROUP_DMEM) +uncharge_cgroup: + dmem_cgroup_uncharge(buffer->pool, size); +#endif +free_buffer: + kfree(buffer); + return ERR_PTR(ret); +} + +static const struct dma_heap_ops coherent_heap_ops = { + .allocate = coherent_heap_allocate, +}; + +static int __coherent_heap_register(struct reserved_mem *rmem) +{ + struct dma_heap_export_info exp_info; + struct coherent_heap *coh_heap; +#if IS_ENABLED(CONFIG_CGROUP_DMEM) + struct dmem_cgroup_region *region; +#endif + const char *rmem_name; + int ret; + + if (!rmem) + return -EINVAL; + + rmem_name = rmem->name ? rmem->name : "unknown"; + + coh_heap = kzalloc_obj(*coh_heap); + if (!coh_heap) + return -ENOMEM; + + coh_heap->name = kasprintf(GFP_KERNEL, "coherent_%s", rmem_name); + if (!coh_heap->name) { + ret = -ENOMEM; + goto free_coherent_heap; + } + + coh_heap->rmem = rmem; + + /* create a platform device per rmem and bind it */ + coh_heap->pdev = platform_device_register_simple("coherent-heap", + PLATFORM_DEVID_AUTO, + NULL, 0); + if (IS_ERR(coh_heap->pdev)) { + ret = PTR_ERR(coh_heap->pdev); + goto free_name; + } + + if (rmem->ops && rmem->ops->device_init) { + ret = rmem->ops->device_init(rmem, &coh_heap->pdev->dev); + if (ret) + goto pdev_unregister; + } + + coh_heap->dev = &coh_heap->pdev->dev; +#if IS_ENABLED(CONFIG_CGROUP_DMEM) + region = dmem_cgroup_register_region(rmem->size, "coh/%s", rmem_name); + if (IS_ERR(region)) { + ret = PTR_ERR(region); + goto pdev_unregister; + } + coh_heap->cg = region; +#endif + + exp_info.name = coh_heap->name; + exp_info.ops = &coherent_heap_ops; + exp_info.priv = coh_heap; + + coh_heap->heap = dma_heap_add(&exp_info); + if (IS_ERR(coh_heap->heap)) { + ret = PTR_ERR(coh_heap->heap); + goto cg_unregister; + } + + return 0; + +cg_unregister: +#if IS_ENABLED(CONFIG_CGROUP_DMEM) + dmem_cgroup_unregister_region(coh_heap->cg); +#endif +pdev_unregister: + platform_device_unregister(coh_heap->pdev); + coh_heap->pdev = NULL; +free_name: + kfree(coh_heap->name); +free_coherent_heap: + kfree(coh_heap); + + return ret; +} + +int dma_heap_coherent_register(struct reserved_mem *rmem) +{ + int ret; + + ret = __coherent_heap_register(rmem); + if (ret == -ENOMEM) + return coherent_heap_add_deferred(rmem); + return ret; +} + +static int __init coherent_heap_register_deferred(void) +{ + unsigned int i; + int ret; + + for (i = 0; i < rmem_areas_deferred_num; i++) { + struct reserved_mem *rmem = rmem_areas_deferred[i]; + + ret = __coherent_heap_register(rmem); + if (ret) { + pr_warn("Failed to add coherent heap %s", + rmem->name ? rmem->name : "unknown"); + continue; + } + } + + return 0; +} +late_initcall(coherent_heap_register_deferred); +MODULE_DESCRIPTION("DMA-BUF heap for coherent reserved-memory regions"); diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h index 648328a64b27e..e894cfa1ecf1a 100644 --- a/include/linux/dma-heap.h +++ b/include/linux/dma-heap.h @@ -9,9 +9,11 @@ #ifndef _DMA_HEAPS_H #define _DMA_HEAPS_H +#include <linux/errno.h> #include <linux/types.h> struct dma_heap; +struct reserved_mem; /** * struct dma_heap_ops - ops to operate on a given heap @@ -48,4 +50,13 @@ struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info); extern bool mem_accounting; +#if IS_ENABLED(CONFIG_DMABUF_HEAPS_COHERENT) +int dma_heap_coherent_register(struct reserved_mem *rmem); +#else +static inline int dma_heap_coherent_register(struct reserved_mem *rmem) +{ + return -EOPNOTSUPP; +} +#endif + #endif /* _DMA_HEAPS_H */ diff --git a/kernel/dma/coherent.c b/kernel/dma/coherent.c index 1147497bc512c..f49d13e460e4b 100644 --- a/kernel/dma/coherent.c +++ b/kernel/dma/coherent.c @@ -9,6 +9,7 @@ #include <linux/module.h> #include <linux/dma-direct.h> #include <linux/dma-map-ops.h> +#include <linux/dma-heap.h> struct dma_coherent_mem { void *virt_base; @@ -393,6 +394,14 @@ static int __init rmem_dma_setup(struct reserved_mem *rmem) rmem->ops = &rmem_dma_ops; pr_info("Reserved memory: created DMA memory pool at %pa, size %ld MiB\n", &rmem->base, (unsigned long)rmem->size / SZ_1M); + + if (IS_ENABLED(CONFIG_DMABUF_HEAPS_COHERENT)) { + int ret = dma_heap_coherent_register(rmem); + + if (ret) + pr_warn("Reserved memory: failed to register coherent heap for %s (%d)\n", + rmem->name ? rmem->name : "unknown", ret); + } return 0; } --- base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f change-id: 20260223-b4-dmabuf-heap-coherent-rmem-91fd3926afe9 Best regards, -- Albert Esteve <aesteve(a)redhat.com>

6 months, 3 weeks

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig