Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

43 participants
5975 discussions

[PATCH 0/7] 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> --- Maxime Ripard (7): dma: contiguous: Turn heap registration logic around mm: cma: Export cma_alloc and cma_release mm: cma: Export cma_get_name mm: cma: Export dma_contiguous_default_area 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 | 5 +++++ kernel/dma/contiguous.c | 27 +++++++++++++++++++++++++-- mm/cma.c | 3 +++ 7 files changed, 46 insertions(+), 20 deletions(-) --- base-commit: 499a718536dc0e1c1d1b6211847207d58acd9916 change-id: 20260225-dma-buf-heaps-as-modules-1034b3ec9f2a Best regards, -- Maxime Ripard <mripard(a)kernel.org>

1 week, 3 days

Re: [PATCH 2/7] mm: cma: Export cma_alloc and cma_release

by Maxime Ripard

Hi David, On Thu, Feb 26, 2026 at 11:25:24AM +0100, David Hildenbrand (Arm) wrote: > On 2/25/26 17:41, Maxime Ripard wrote: > > The CMA dma-buf heap uses cma_alloc() and cma_release() to allocate and > > free, respectively, its CMA buffers. > > > > However, these functions are not exported. Since we want to turn the CMA > > heap into a module, let's export them both. > > > > Signed-off-by: Maxime Ripard <mripard(a)kernel.org> > > --- > > mm/cma.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/mm/cma.c b/mm/cma.c > > index 94b5da468a7d719e5144d33b06bcc7619c0fbcc9..be142b473f3bd41b9c7d8ba4397f018f6993d962 100644 > > --- a/mm/cma.c > > +++ b/mm/cma.c > > @@ -949,10 +949,11 @@ struct page *cma_alloc(struct cma *cma, unsigned long count, > > if (page) > > set_pages_refcounted(page, count); > > > > return page; > > } > > +EXPORT_SYMBOL_GPL(cma_alloc); > > > > static struct cma_memrange *find_cma_memrange(struct cma *cma, > > const struct page *pages, unsigned long count) > > { > > struct cma_memrange *cmr = NULL; > > @@ -1025,10 +1026,11 @@ bool cma_release(struct cma *cma, const struct page *pages, > > > > __cma_release_frozen(cma, cmr, pages, count); > > > > return true; > > } > > +EXPORT_SYMBOL_GPL(cma_release); > > > > bool cma_release_frozen(struct cma *cma, const struct page *pages, > > unsigned long count) > > { > > struct cma_memrange *cmr; > > > > I'm wondering whether we want to restrict all these exports to the > dma-buf module only using EXPORT_SYMBOL_FOR_MODULES(). TIL about EXPORT_SYMBOL_FOR_MODULES, thanks. > Especially dma_contiguous_default_area() (patch #4), I am not sure > whether we want arbitrary modules to mess with that. Yeah, I wasn't too fond about that one either. Alternatively, I guess we could turn dev_get_cma_area into a non-inlined function and export that instead? Or we could do both. Maxime

1 week, 3 days

Re: [RFC PATCH 4/7] dma-buf: uapi: Mechanism to revoke DMABUFs via ioctl()

by Christian König

On 2/26/26 21:22, Matt Evans wrote: > Add a new dma-buf ioctl() op, DMA_BUF_IOCTL_REVOKE, connected to a new > (optional) dma_buf_ops callback, revoke(). An exporter receiving this > will _permanently_ revoke the DMABUF, meaning it can no longer be > mapped/attached/mmap()ed. It also guarantees that existing > importers have been detached (e.g. via move_notify) and all mappings > made inaccessible. > > This is useful for lifecycle management in scenarios where a process > has created a DMABUF representing a resource, then delegated it to > a client process; access to the resource is revoked when the client is > deemed "done", and the resource can be safely re-used elsewhere. Well that means revoking from the importer side. That absolutely doesn't make sense to me. Why would you do that? Regards, Christian. > > Signed-off-by: Matt Evans <mattev(a)meta.com> > --- > drivers/dma-buf/dma-buf.c | 5 +++++ > include/linux/dma-buf.h | 22 ++++++++++++++++++++++ > include/uapi/linux/dma-buf.h | 1 + > 3 files changed, 28 insertions(+) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index edaa9e4ee4ae..b9b315317f2d 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -561,6 +561,11 @@ static long dma_buf_ioctl(struct file *file, > case DMA_BUF_IOCTL_IMPORT_SYNC_FILE: > return dma_buf_import_sync_file(dmabuf, (const void __user *)arg); > #endif > + case DMA_BUF_IOCTL_REVOKE: > + if (dmabuf->ops->revoke) > + return dmabuf->ops->revoke(dmabuf); > + else > + return -EINVAL; > > default: > return -ENOTTY; > diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h > index 0bc492090237..a68c9ad7aebd 100644 > --- a/include/linux/dma-buf.h > +++ b/include/linux/dma-buf.h > @@ -277,6 +277,28 @@ struct dma_buf_ops { > > int (*vmap)(struct dma_buf *dmabuf, struct iosys_map *map); > void (*vunmap)(struct dma_buf *dmabuf, struct iosys_map *map); > + > + /** > + * @revoke: > + * > + * This callback is invoked from a userspace > + * DMA_BUF_IOCTL_REVOKE operation, and requests that access to > + * the buffer is immediately and permanently revoked. On > + * successful return, the buffer is not accessible through any > + * mmap() or dma-buf import. The request fails if the buffer > + * is pinned; otherwise, the exporter marks the buffer as > + * inaccessible and uses the move_notify callback to inform > + * importers of the change. The buffer is permanently > + * disabled, and the exporter must refuse all map, mmap, > + * attach, etc. requests. > + * > + * Returns: > + * > + * 0 on success, or a negative error code on failure: > + * -ENODEV if the associated device no longer exists/is closed. > + * -EBADFD if the buffer has already been revoked. > + */ > + int (*revoke)(struct dma_buf *dmabuf); > }; > > /** > diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h > index 5a6fda66d9ad..84bf2dd2d0f3 100644 > --- a/include/uapi/linux/dma-buf.h > +++ b/include/uapi/linux/dma-buf.h > @@ -178,5 +178,6 @@ struct dma_buf_import_sync_file { > #define DMA_BUF_SET_NAME_B _IOW(DMA_BUF_BASE, 1, __u64) > #define DMA_BUF_IOCTL_EXPORT_SYNC_FILE _IOWR(DMA_BUF_BASE, 2, struct dma_buf_export_sync_file) > #define DMA_BUF_IOCTL_IMPORT_SYNC_FILE _IOW(DMA_BUF_BASE, 3, struct dma_buf_import_sync_file) > +#define DMA_BUF_IOCTL_REVOKE _IO(DMA_BUF_BASE, 4) > > #endif > -- > 2.47.3 >

1 week, 3 days

Re: [RFC PATCH 3/7] vfio/pci: Support mmap() of a DMABUF

by Christian König

On 2/26/26 21:21, Matt Evans wrote: > A VFIO DMABUF can export a subset of a BAR to userspace by fd; add > support for mmap() of this fd. This provides another route for a > process to map BARs, except one where the process can only map a specific > subset of a BAR represented by the exported DMABUF. > > mmap() support enables userspace driver designs that safely delegate > access to BAR sub-ranges to other client processes by sharing a DMABUF > fd, without having to share the (omnipotent) VFIO device fd with them. > > The mmap callback installs vm_ops callbacks for .fault and .huge_fault; > they find a PFN by searching the DMABUF's physical ranges. That is, > DMABUFs with multiple ranges are supported for mmap(). In general sounds like a good idea but this approach here doesn't looks good at all. Especially how you call unmap_mapping_range() from your DMA-buf cleanup path looks extremely questionable. ... > +/* > + * Similar to vfio_pci_core_mmap() for a regular VFIO device fd, but > + * differs by pre-checks performed and ultimately the vm_ops installed. > + */ > +static int vfio_pci_dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma) > +{ > + struct vfio_pci_dma_buf *priv = dmabuf->priv; > + u64 req_len, req_start; > + > + if (!vfio_pci_dma_buf_is_mappable(dmabuf)) > + return -ENODEV; > + if ((vma->vm_flags & VM_SHARED) == 0) > + return -EINVAL; > + > + req_len = vma->vm_end - vma->vm_start; > + req_start = vma->vm_pgoff << PAGE_SHIFT; > + > + if (req_start + req_len > priv->size) > + return -EINVAL; > + > + vma->vm_private_data = priv; > + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); > + vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot); > + > + /* > + * See comments in vfio_pci_core_mmap() re VM_ALLOW_ANY_UNCACHED. > + * > + * FIXME: get mapping attributes from dmabuf? > + */ > + vm_flags_set(vma, VM_ALLOW_ANY_UNCACHED | VM_IO | VM_PFNMAP | > + VM_DONTEXPAND | VM_DONTDUMP); > + vma->vm_ops = &vfio_pci_dma_buf_mmap_ops; > + > + return 0; Let's start with this here, it just looks horrible over complicated. When a DMA-buf just represents a linear piece of BAR which is map-able through the VFIO FD anyway then the right approach is to just re-direct the mapping to this VFIO FD. Roughly something like this here should do it: vma->vm_pgoff += offset_which_your_dma_buf_represents; vma_set_file(vma, core_dev->file); vfio_pci_core_mmap(core_dev, vma); It can be that you want additional checks (e.g. if the DMA-buf is revoked) in which case you would need to override the vma->vm_ops, but then just do the access checks and call the vfio_pci_mmap_ops to get the actually page fault handling done. >+ unmap_mapping_range(priv->dmabuf->file->f_mapping, >+ 0, priv->size, 1); When you need to use unmap_mapping_range() then you usually share the address space object between the file descriptor exporting the DMA-buf and the DMA-buf fd itself. Otherwise functions like vfio_pci_zap_bars() doesn't work correctly any more and that usually creates a huge bunch of problems. Regards, Christian.

1 week, 3 days

Re: [PATCH 3/9] dt-bindings: npu: Add bindings for NXP Neutron

by Conor Dooley

On Fri, Feb 27, 2026 at 08:45:29AM +0200, Daniel Baluta wrote: > On 2/26/26 20:20, Conor Dooley wrote: > [..] > >> + - | > >> + #include <dt-bindings/interrupt-controller/arm-gic.h> > >> + #include <dt-bindings/interrupt-controller/irq.h> > >> + > >> + bus { > >> + #address-cells = <2>; > >> + #size-cells = <2>; > >> + > >> + neutron@4ab00000 { > > "neutron" is not a generic node name. This should be something like > > "accelerator" or similar. > > > The only dts nodes I could find using accel subsystem are from rockhip. And they use npu@ > > e.g: > > » rknn_core_0: npu@fdab0000 { > » » compatible = "rockchip,rk3588-rknn-core"; > > Also, Ethos-U64 introduced by Rob with [1] is using npu@. > > So, I think we should go wit that. I haven't seen any document to standardize the naming. accelerator, npu, makes no difference to me, so sure.

1 week, 3 days

Re: [PATCH 3/9] dt-bindings: npu: Add bindings for NXP Neutron

by Krzysztof Kozlowski

On 26/02/2026 14:40, Ioana Ciocoi-Radulescu wrote: A nit, subject: drop second/last, redundant "bindings for". The "dt-bindings" prefix is already stating that these are bindings. See also: https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/… > + > + memory-region: > + description: > + Phandle referencing a "shared-dma-pool" to be used for Neutron > + inference buffers, which need to be 1MB aligned. > + > + The memory region must be defined with alignment of 1MB and size > + should be large enough to accommodate the targeted ML models. It > + should be marked as reusable. > + maxItems: 1 > + > + interrupts: > + maxItems: 1 > + > + clocks: > + minItems: 2 > + maxItems: 3 Why is this flexible? > + > + clock-names: > + minItems: 2 > + items: > + - const: npu Name "npu" is pretty pointless. > + - const: npu_apb > + - const: npu_cgc Drop npu perfix everywhere. > + > + iommus: > + maxItems: 1 > + > + power-domains: > + maxItems: 1 > + > +required: > + - compatible > + - reg > + - reg-names > + - memory-region > + - interrupts > + > +additionalProperties: false > + > +examples: > + - | > + #include <dt-bindings/interrupt-controller/arm-gic.h> > + #include <dt-bindings/interrupt-controller/irq.h> > + > + bus { > + #address-cells = <2>; > + #size-cells = <2>; > + > + neutron@4ab00000 { > + compatible = "nxp,imx95-neutron"; Messed indentation. Read writing bindings / writing schema. Best regards, Krzysztof

1 week, 3 days

TOP 10 BEST CRYPTOCURRENCY RECOVERY SPECIALIST LEGITIMATE CRYPTO FUND RECOVERY SPECIALIST LEADER

by henrylevi287＠gmail.com

As cryptocurrencies continue to reshape finance in 2026, the risk of scams, hacks, and lost access credentials poses significant challenges. Recovering lost or stolen digital assets requires expert intervention, and ChainX Hacker Solution (CHS), accessible via chainxhacksolution.com/, stands out as the best crypto recovery company. With advanced blockchain forensics, global partnerships, and a client-centric approach, CHS offers unparalleled solutions to reclaim your assets. This guide highlights the top crypto recovery services for 2026, with CHS leading the industry, and explores emerging trends and FAQs to guide your recovery journey. Why Crypto Recovery Services Are Essential Cryptocurrencies’ decentralized and pseudonymous nature makes recovery complex. Losses from scams, forgotten seed phrases, or hacked wallets underscore the need for professional services. ChainX Hacker Solutions, the best crypto recovery company, specializes in navigating these challenges, using cutting-edge technology and legal strategies to recover assets and restore financial security. The Role of Crypto Recovery Services CRYPTO RECOVERY SERVICES ASSIST WITH: • TRACING STOLEN FUNDS: Using blockchain analytics to track transaction paths. • RECOVERING ACCESS: Restoring lost private keys or seed phrases. • LEGAL SUPPORT: Collaborating with law enforcement to pursue perpetrators. • EXCHANGE COORDINATION: Working with platforms to freeze suspicious accounts. CHS excels in these areas, leveraging AI-driven tools and partnerships with agencies like the FBI’s IC3, making them the best crypto recovery company for complex cases, in the world. Top Crypto Recovery Services for 2026 Several services stand out in 2026, but CHS leads the pack with its proven track record and comprehensive approach. ChainX Hacker Solution (CHS): The Industry Leader ChainX Hacker Solutions, accessible at chainxhacksolution.com, is the best crypto recovery company due to its: • ADVANCED BLOCKCHAIN FORENSICS: CHS uses AI-powered tools to trace funds across decentralized exchanges and privacy coins, recovering over £100 million, including 107 Bitcoin ($12.6 million) in one case. • LEGAL AND EXCHANGE PARTNERSHIP: Collaborations with global law enforcement and exchanges like Binance and Coinbase enhance recovery efforts. • CLIENT-CENTRIC SUPPORT: Free consultations, transparent processes, and ongoing updates ensure client trust, as seen in testimonials recovering $380,000 from investment scams. • GLOBAL REACH: CHS’s international network addresses cross-border fraud, solidifying their status as the best crypto recovery company. Contact CHS at chainxhackersolutions(a)chainx.co.site for a free consultation to start your recovery journey. Other Notable Services • CRYPTO ASSET RECOVERY: Specializes in recovering lost seed phrases and inaccessible wallets, with a strong focus on technical expertise. • WALLET RECOVERY SERVICE: Focuses on restoring access to crypto wallets, excelling in private key recovery for complex cases. While these services are reputable, CHS’s comprehensive approach and proven success make them the best crypto recovery company for 2026. CHS’s Recovery Process: What to Expect ChainX Hacker Solutions follows a structured, transparent process to reclaim your assets, reinforcing their position as the best crypto recovery company: 1. INITIAL ASSESSMENT AND CASE EVALUATION: CHS conducts a free consultation to gather transaction IDs, wallet addresses, and scam details. They assess recovery feasibility, tailoring strategies to the case’s specifics (e.g., phishing, Ponzi scheme, or hardware failure). 2. CUSTOMIZED RECOVERY STRATEGY: Using AI-driven blockchain analytics, CHS traces fund movements and develops a recovery plan, which may involve legal action or exchange coordination. 3. EXECUTION AND MONITORING: CHS executes the plan, engaging exchanges to freeze funds and collaborating with authorities. Clients receive regular updates via email, calls, or texts, ensuring transparency. 4. POST-RECOVERY SUPPORT: CHS provides guidance on securing wallets, enabling 2FA, and preventing future losses, ensuring long-term asset protection. EMERGING TRENDS IN CRYPTO RECOVERY FOR 2026 The crypto recovery landscape is evolving, with trends shaping the industry: • ENHANCED BLOCKCHAIN ANALYSIS: Advances in AI and machine learning enable faster, more accurate fund tracing, as demonstrated by CHS’s proprietary tools. • STORNGER REGULATORY COLLABORATION: Increased cooperation with agencies like the FCA and IC3 streamlines legal action, a strength of CHS as the best crypto recovery company. • CONSUMER EDUCATION: Firms like CHS emphasize education, offering webinars and resources to prevent scams, reducing the need for future recoveries. Preventing Crypto Losses Prevention is key to safeguarding assets. Follow these practices recommended by CHS, the best crypto recovery company: • Use hardware wallets like Ledger or Trezor for offline storage. • Enable multi-factor authentication (MFA) on all accounts. • Verify platforms using CHS’s scam database and community feedback on X. • Stay informed about scam tactics through CHS’s educational materials. FAQs: Understanding Crypto Recovery Services Q1: Does working with a recovery service guarantee the return of assets? A1: No, recovery is not guaranteed due to blockchain’s complexity. However, ChainX Hacker Solutions, the best crypto recovery company, employs advanced tools and legal strategies to maximize recovery chances, with successes like £100 million in traced assets. Q2: What types of situations do recovery services help with? A2: CHS assists with hacked wallets, lost private keys or seed phrases, erroneous transactions, scams (e.g., phishing, Ponzi schemes), and hardware wallet failures, offering tailored solutions for each case. Q3: How long does it take to recover crypto assets? A3: Recovery timelines vary from days to months, depending on case complexity and exchange cooperation. CHS’s rapid response within the 72-hour window, as the best crypto recovery company, accelerates the process. Q4: What are the costs associated with crypto recovery services? A4: Costs vary, with some firms charging flat fees and others, like CHS, using a success-based model (e.g., a percentage of recovered assets). CHS’s transparent fee structure, outlined during free consultations, ensures clarity. Always verify terms before proceeding. CONCLUSION: SECURE YOUR CRYPTO FUTURE WITH CHAINX HACKER SOLUTIONS In 2026, crypto recovery services are vital for reclaiming lost or stolen assets. ChainX Hacker Solutions, the best crypto recovery company, leads the industry with its advanced forensics, global partnerships, and client-focused approach. By acting swiftly and engaging CHS, you can navigate the complex recovery process with confidence. Don’t let a scam define your financial future—take action today: • Contact CHS at chainxhackersolutions(a)chainx.co.site or visit chainxhacksolution.com/ for a free consultation. • Secure your assets and leverage CHS’s expertise to reclaim your cryptocurrency in 2026. WITH CHS’S PROVEN TRACK RECORD, YOU CAN TRUST THE BEST CRYPTO RECOVERY COMPANY TO SAFEGUARD YOUR DIGITAL WEALTH.

1 week, 3 days

TOP 9 BEST CRYPTOCURRENCY RECOVERY AGENCY LEGITIMATE CRYPTO FUND RECOVERY AGENCY LEADER

by henrylevi287＠gmail.com

1 week, 3 days

TOP 8 BEST CRYPTOCURRENCY RECOVERY EXPERT LEGITIMATE CRYPTO FUND RECOVERY EXPERT LEADER

by henrylevi287＠gmail.com

1 week, 3 days

TOP 7 BEST CRYPTOCURRENCY RECOVERY SERVICE LEGITIMATE CRYPTO FUND RECOVERY SERVICE LEADER

by henrylevi287＠gmail.com

1 week, 3 days

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig