Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

58 participants
6149 discussions

Phishing Attacks on Wallets: How Hackers Drain Your Crypto in Minutes

by luisannete22＠gmail.com

Phishing remains one of the most common ways scammers steal crypto—often through fake websites, malicious emails, or compromised links. 1. The Bait Victims receive urgent messages: "Your wallet is at risk—verify here" or fake airdrop/claim links from trusted projects. Clicking leads to spoofed sites mimicking MetaMask, Ledger, or exchanges. Users enter seed phrases, private keys, or approve malicious transactions. 2. Instant Drainage Once credentials or approvals are obtained: Scammers sweep funds to their address. Drainers auto-transfer everything (tokens, NFTs). 3. Rapid Laundering Funds move fast: Split and peeled into smaller amounts. Bridged to other chains. Mixed or swapped to break links. 4. Cash-Out Deposited to exchanges, often KYC-bypassed via layered accounts. Where Tracing Can Intervene Phishing thefts leave clear on-chain trails if reported quickly. Real-Time Monitoring: Track outgoing sweeps and downstream hops. Pattern Recognition: Identify common drainer signatures or exchange deposit clusters. Freeze Potential: Exchanges can halt if illicit origin proven early. Firms like Cryptera Chain Signals (CCS) excel at rapid phishing investigations, using AI-powered tracing to follow funds across chains and facilitate exchange freezes. In 2026, they've helped recover significant portions in time-sensitive cases. Visit https://www.crypterachainsignals.com/ for crypto scam recovery support, or email info(a)crypterachainsignals.com to get started. Protect yourself with hardware wallets and bookmark verification never enter seeds online.

1 week, 6 days

Romance Scams in Crypto: The Slow-Burn Theft Exposed Cryptera Chain Signals

by luisannete22＠gmail.com

The rise of cryptocurrency has amplified romance scams, where fraudsters build emotional trust over weeks or months before requesting funds. These "pig butchering" operations are particularly devastating because victims often send large sums willingly. 1. Building False Trust Scammers create fake profiles on dating apps or social media, posing as successful investors or entrepreneurs. They share "proof" of crypto gains to lure victims into trading platforms they control. Conversations escalate to "exclusive opportunities" like private presales or high-yield pools. Victims are guided to deposit crypto into wallets or fake exchanges. 2. The Extraction Phase Once trust is established, scammers pressure victims to invest more, promising quick returns. Funds go to scammer-controlled addresses. Fake dashboards show fabricated profits to encourage further deposits. 3. Obfuscation Tactics After extraction, funds are quickly moved: Split across dozens of wallets. Hopped through bridges to privacy-focused chains. Mixed via services or converted to privacy coins like Monero. 4. Final Laundering Cleaned funds hit centralized exchanges for fiat withdrawal, often via mule accounts. Recovery window closes fast once converted. Where Tracing Can Intervene Quick action is essential in romance scams due to the emotional manipulation factor. Immediate Reporting: Preserve all chat logs, transaction IDs, and screenshots. Blockchain Analysis: Trace patterns like repeated small deposits or specific bridge usage. Exchange Cooperation: Provide evidence to freeze incoming deposits. Blockchain investigation firms like Cryptera Chain Signals (CCS) specialize in tracing romance scam funds through complex paths, identifying endpoints, and assisting with freeze requests. With advanced forensics and a track record of hundreds of recoveries (including 2026 cases), they help victims map flows and pursue actionable steps before full laundering. For professional help with romance scam or crypto fraud recovery, visit the Cryptera Chain Signals website at https://www.crypterachainsignals.com/. Contact them directly via email at info(a)crypterachainsignals.com or through their secure inquiry form. Emotional scams hurt deeply, but blockchain transparency offers hope—act swiftly and seek expert help.

1 week, 6 days

[PATCH v2 0/6] dma-buf: heaps: add coherent reserved-memory heap

by Albert Esteve

This patch introduces a new heap driver to expose DT non‑reusable "shared-dma-pool" coherent regions as dma-buf heaps, so userspace can allocate buffers from each reserved, named region. Because these regions are device‑dependent, each heap instance binds a heap device to its reserved‑mem region via a newly introduced helper function -namely, of_reserved_mem_device_init_with_mem()- so coherent allocations use the correct dev->dma_mem. Charging to cgroups for these buffers is intentionally left out to keep review focused on the new heap; I plan to follow up based on Eric’s [1] and Maxime’s [2] work on dmem charging from userspace. This series also makes the new heap driver modular, in line with the CMA heap change in [3]. [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.… [3] https://lore.kernel.org/all/20260303-dma-buf-heaps-as-modules-v3-0-24344812… Signed-off-by: Albert Esteve <aesteve(a)redhat.com> --- Changes in v2: - Removed dmem charging parts - Moved coherent heap registering logic to coherent.c - Made heap device a member of struct dma_heap - Split dma_heap_add logic into create/register, to be able to access the stored heap device before registered. - Avoid platform device in favour of heap device - Added a wrapper to rmem device_init() op - Switched from late_initcall() to module_init() - Made the coherent heap driver modular - Link to v1: https://lore.kernel.org/r/20260224-b4-dmabuf-heap-coherent-rmem-v1-1-dffef4… --- Albert Esteve (5): dma-buf: dma-heap: split dma_heap_add of_reserved_mem: add a helper for rmem device_init op dma-buf: heaps: Add Coherent heap to dmabuf heaps dma: coherent: register to coherent heap dma-buf: heaps: coherent: Turn heap into a module John Stultz (1): dma-buf: dma-heap: Keep track of the heap device struct drivers/dma-buf/dma-heap.c | 138 +++++++++-- drivers/dma-buf/heaps/Kconfig | 9 + drivers/dma-buf/heaps/Makefile | 1 + drivers/dma-buf/heaps/coherent_heap.c | 429 ++++++++++++++++++++++++++++++++++ drivers/of/of_reserved_mem.c | 27 ++- include/linux/dma-heap.h | 16 ++ include/linux/dma-map-ops.h | 7 + include/linux/of_reserved_mem.h | 8 + kernel/dma/coherent.c | 34 +++ 9 files changed, 642 insertions(+), 27 deletions(-) --- base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f change-id: 20260223-b4-dmabuf-heap-coherent-rmem-91fd3926afe9 Best regards, -- Albert Esteve <aesteve(a)redhat.com>

1 week, 6 days

Re: [PATCH v2 3/6] of_reserved_mem: add a helper for rmem device_init op

by Albert Esteve

On Tue, Mar 3, 2026 at 2:13 PM Maxime Ripard <mripard(a)redhat.com> wrote: > > On Tue, Mar 03, 2026 at 01:33:46PM +0100, Albert Esteve wrote: > > Add a helper function wrapping internal reserved memory > > device_init call and expose it externally. > > > > Use the new helper function within of_reserved_mem_device_init_by_idx(). > > > > Signed-off-by: Albert Esteve <aesteve(a)redhat.com> > > --- > > drivers/of/of_reserved_mem.c | 27 +++++++++++++++++++++++---- > > include/linux/of_reserved_mem.h | 8 ++++++++ > > 2 files changed, 31 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c > > index 1fd28f8056108..3a350bef8f11e 100644 > > --- a/drivers/of/of_reserved_mem.c > > +++ b/drivers/of/of_reserved_mem.c > > @@ -605,6 +605,28 @@ struct rmem_assigned_device { > > static LIST_HEAD(of_rmem_assigned_device_list); > > static DEFINE_MUTEX(of_rmem_assigned_device_mutex); > > > > +/** > > + * of_reserved_mem_device_init_with_mem() - assign reserved memory region to > > + * given device > > + * @dev: Pointer to the device to configure > > + * @rmem: Reserved memory region to assign > > + * > > + * This function assigns respective DMA-mapping operations based on the > > + * reserved memory region already provided in @rmem to the @dev device, > > + * without walking DT nodes. > > + * > > + * Returns error code or zero on success. > > + */ > > +int of_reserved_mem_device_init_with_mem(struct device *dev, > > + struct reserved_mem *rmem) > > +{ > > + if (!dev || !rmem || !rmem->ops || !rmem->ops->device_init) > > + return -EINVAL; > > + > > + return rmem->ops->device_init(rmem, dev); > > +} > > +EXPORT_SYMBOL_GPL(of_reserved_mem_device_init_with_mem); > > + > > /** > > * of_reserved_mem_device_init_by_idx() - assign reserved memory region to > > * given device > > @@ -643,14 +665,11 @@ int of_reserved_mem_device_init_by_idx(struct device *dev, > > rmem = of_reserved_mem_lookup(target); > > of_node_put(target); > > > > - if (!rmem || !rmem->ops || !rmem->ops->device_init) > > - return -EINVAL; > > - > > rd = kmalloc_obj(struct rmem_assigned_device); > > if (!rd) > > return -ENOMEM; > > > > - ret = rmem->ops->device_init(rmem, dev); > > + ret = of_reserved_mem_device_init_with_mem(dev, rmem); > > if (ret == 0) { > > rd->dev = dev; > > rd->rmem = rmem; > > I think you need to take the allocation of rd, and everything below. > Otherwise, your device, despite being attechd, wouldn't be listed > anywhere. True, I did not pay enough attention to that part. I will fix it in the next version. > > Maxime

1 week, 6 days

Primatz Guard Recovery: Addressing Romance Scams Linked to Digital Assets

by phillipsmathew895＠gmail.com

Romance scams begin with emotional trust-building, often through social media or messaging apps. Scammers later introduce supposed crypto or digital asset investment opportunities and persuade victims to transfer funds. Once payments are made, communication fades and funds become difficult to retrieve. Primatz Guard Recovery supports victims by reviewing financial trails, identifying scam tactics, and providing guidance on recovery steps with no consultation charges. Staying cautious with online relationships and avoiding financial commitments based on emotional pressure remains essential. Homepage: Primatz Guard Recovery

2 weeks

How To Recover Lost Funds From Online Investment Scam - Reach Out To Betafort Recovery

by glennkael8＠gmail.com

With professionalism and integrity, Betafort Recovery assures that their clients get the finest possible help in retrieving their lost digital assets. With a staff of professionals dedicated to assisting individuals in navigating the recovery process, they provide 24 hour support to guarantee that customers receive timely and effective assistance when they need it the most. Testimonials from delighted clients demonstrate Betafort Recovery abilities in recovering lost digital assets, emphasizing their dedication to client satisfaction and good outcomes. NO UPFRONT FEES REQUIRED. Online presence: Betafort Recovery

2 weeks

Re: [PATCH v2 4/6] dma-buf: heaps: Add Coherent heap to dmabuf heaps

by Albert Esteve

On Tue, Mar 3, 2026 at 2:20 PM Maxime Ripard <mripard(a)redhat.com> wrote: > > Hi, > > On Tue, Mar 03, 2026 at 01:33:47PM +0100, Albert Esteve wrote: > > 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 the heap device to each memory region so > > coherent allocations use the correct dev->dma_mem, and > > it defers registration until module_init when normal > > allocators are available. > > > > Signed-off-by: Albert Esteve <aesteve(a)redhat.com> > > --- > > drivers/dma-buf/dma-heap.c | 4 +- > > drivers/dma-buf/heaps/Kconfig | 9 + > > drivers/dma-buf/heaps/Makefile | 1 + > > drivers/dma-buf/heaps/coherent_heap.c | 426 ++++++++++++++++++++++++++++++++++ > > include/linux/dma-heap.h | 11 + > > include/linux/dma-map-ops.h | 7 + > > 6 files changed, 456 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c > > index 88189d4e48561..ba87e5ac16ae2 100644 > > --- a/drivers/dma-buf/dma-heap.c > > +++ b/drivers/dma-buf/dma-heap.c > > @@ -390,8 +390,8 @@ struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info) > > > > heap = dma_heap_create(exp_info); > > if (IS_ERR(heap)) { > > - pr_err("dma_heap: failed to create heap (%d)\n", PTR_ERR(heap)); > > - return PTR_ERR(heap); > > + pr_err("dma_heap: failed to create heap (%ld)\n", PTR_ERR(heap)); > > + return ERR_CAST(heap); > > This looks unrelated and should possibly be squashed into the previous > patch that introduces dma_heap_create()? > > > +static int coherent_heap_init_dma_mask(struct device *dev) > > +{ > > + int ret; > > + > > + ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(64)); > > + if (!ret) > > + return 0; > > + > > + /* Fallback to 32-bit DMA mask */ > > + return dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32)); > > +} > > Why do you need to mess with the DMA mask? I'd expect that device to be > able to access everything. When I tested I was getting: "reserved memory is beyond device's set DMA address range", so I tested if it was fixed with dma_coerce_mask_and_coherent() and/or dma_set_mask_coherent(). I did not debug the value of coherent_dma_mask, but given the error I assume it was not set properly? Ultimately, using the 64 bit mask fixed it, and I added a 32-bit fallback to ensure support for 32-bit systems. > > > +static int __coherent_heap_register(struct reserved_mem *rmem) > > +{ > > + struct dma_heap_export_info exp_info; > > + struct coherent_heap *coh_heap; > > + struct device *heap_dev; > > + int ret; > > + > > + if (!rmem || !rmem->name) > > + return -EINVAL; > > + > > + coh_heap = kzalloc_obj(*coh_heap); > > + if (!coh_heap) > > + return -ENOMEM; > > + > > + coh_heap->rmem = rmem; > > + coh_heap->name = kstrdup(rmem->name, GFP_KERNEL); > > + if (!coh_heap->name) { > > + ret = -ENOMEM; > > + goto free_coherent_heap; > > + } > > + > > + exp_info.name = coh_heap->name; > > + exp_info.ops = &coherent_heap_ops; > > + exp_info.priv = coh_heap; > > + > > + coh_heap->heap = dma_heap_create(&exp_info); > > + if (IS_ERR(coh_heap->heap)) { > > + ret = PTR_ERR(coh_heap->heap); > > + goto free_name; > > + } > > + > > + heap_dev = dma_heap_get_dev(coh_heap->heap); > > + ret = coherent_heap_init_dma_mask(heap_dev); > > + if (ret) { > > + pr_err("coherent_heap: failed to set DMA mask (%d)\n", ret); > > + goto destroy_heap; > > + } > > + > > + ret = of_reserved_mem_device_init_with_mem(heap_dev, rmem); > > + if (ret) { > > + pr_err("coherent_heap: failed to initialize memory (%d)\n", ret); > > + goto destroy_heap; > > + } > > + > > + ret = dma_heap_register(coh_heap->heap); > > + if (ret) { > > + pr_err("coherent_heap: failed to register heap (%d)\n", ret); > > + goto destroy_heap; > > + } > > I guess it's more of a comment about your previous patch, but it's not > clear to me why you needed to split dma_heap_add into dma_heap_create / > _register. Can you expand a bit? So first I tried to just use dma_heap_add() and then use the heap_dev afterward to call of_reserved_mem_device_init_with_mem(), but if that call failed, the error path required some kind dma_heap_remove() function as the heap was already registered by then. In the CMA heap for example, dma_heap_add() is invoked at the end of the `init` function. Therefore, you do not have this issue, if it failed it means the heap was not added and you just need to clean everything else. However, performing a remove() does not sound like something that can be done safely. I've spent some time thinking on alternatives, but splitting felt the best pattern. This way I can: 1. Create the device 2. Call of_reserved_mem_device_init_with_mem 3. Register the heap This places registration at the end, making every error path and cleanup easy to handle. Also, the `dma_heap_add()` code already seemed to handle these two parts/phases implicitly with device_create(), so splitting felt architecturally sound. > > > diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h > > index 1b0ea43ba66c3..77e6cb66ffce1 100644 > > --- a/include/linux/dma-heap.h > > +++ b/include/linux/dma-heap.h > > @@ -9,10 +9,12 @@ > > #ifndef _DMA_HEAPS_H > > #define _DMA_HEAPS_H > > > > +#include <linux/errno.h> > > #include <linux/types.h> > > > > struct dma_heap; > > struct device; > > +struct reserved_mem; > > > > /** > > * struct dma_heap_ops - ops to operate on a given heap > > @@ -53,4 +55,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 */ > > Do you still need that now that you switched to an iterator-like > function? > > > diff --git a/include/linux/dma-map-ops.h b/include/linux/dma-map-ops.h > > index 60b63756df821..c87e5e44e5383 100644 > > --- a/include/linux/dma-map-ops.h > > +++ b/include/linux/dma-map-ops.h > > @@ -12,6 +12,7 @@ > > > > struct cma; > > struct iommu_ops; > > +struct reserved_mem; > > > > struct dma_map_ops { > > void *(*alloc)(struct device *dev, size_t size, > > @@ -161,6 +162,7 @@ int dma_alloc_from_dev_coherent(struct device *dev, ssize_t size, > > int dma_release_from_dev_coherent(struct device *dev, int order, void *vaddr); > > int dma_mmap_from_dev_coherent(struct device *dev, struct vm_area_struct *vma, > > void *cpu_addr, size_t size, int *ret); > > +struct reserved_mem *dma_coherent_get_reserved_region(unsigned int idx); > > #else > > static inline int dma_declare_coherent_memory(struct device *dev, > > phys_addr_t phys_addr, dma_addr_t device_addr, size_t size) > > @@ -172,6 +174,11 @@ static inline int dma_declare_coherent_memory(struct device *dev, > > #define dma_release_from_dev_coherent(dev, order, vaddr) (0) > > #define dma_mmap_from_dev_coherent(dev, vma, vaddr, order, ret) (0) > > static inline void dma_release_coherent_memory(struct device *dev) { } > > +static inline > > +struct reserved_mem *dma_coherent_get_reserved_region(unsigned int idx) > > +{ > > + return NULL; > > +} > > #endif /* CONFIG_DMA_DECLARE_COHERENT */ > > > > #ifdef CONFIG_DMA_GLOBAL_POOL > > To preserve bisectability, you shouldn't do it that way. Introduce this > function into a preliminary patch, and then use it in this one. > > Maxime

2 weeks

Forgot Your Crypto Wallet Password? Here's What to Do

by hamtonbecky＠gmail.com

Forgetting the password to your crypto wallet can be incredibly stressful, especially with valuable assets at stake. Unlike traditional accounts, most non-custodial crypto wallets (like MetaMask, Exodus, Electrum, or hardware wallets) don't offer simple "forgot password" resets. Recovery depends entirely on your wallet type and backups. Key Recovery Options If You Have Your Recovery Phrase (Seed Phrase) This is the most reliable method. Most wallets use a 12- or 24-word recovery phrase to restore access. Uninstall/reinstall the wallet app or extension. Choose "Import" or "Recover" wallet. Enter your seed phrase. Set a new password. This works for wallets like Crypto.com, Bitcoin.com, and many others. Always store your seed phrase securely offline. For Custodial Wallets/Exchanges If your funds are on a platform like Blockchain.com (trading account) or an exchange, use their official "Forgot Password" feature. Enter your email/phone, verify identity, and reset via link or support. These are easier since the platform holds keys. Try Remembering or Brute-Forcing (Limited Success) Brainstorm variations based on hints, patterns, or old passwords. For some wallets (e.g., Bitcoin Core .dat files), advanced users try tools like Hashcat or John the Ripper on their own hardware. This is time-consuming, technical, and often unsuccessful for strong passwords. If Nothing Works Without the seed phrase or backups, self-recovery is usually impossible due to crypto's strong security design. Many users permanently lose access. If you need expert help, reach out to Cryptera Chain Signals (CCS), a specialized firm in crypto fund recovery and wallet restoration. They assist with inaccessible wallets and related issues using advanced forensics and tracing. Website: https://www.crypterachainsignals.com/ Email: info(a)crypterachainsignals.com Important Warnings Never share your seed phrase, private keys, or password with anyone. Beware of scams promising guaranteed recovery for upfront fees. Prevention is key: Back up your seed phrase securely and use strong, memorable passwords. Act quickly and carefully your funds depend on it. Good luck!

2 weeks

[PATCH v3 0/8] 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 v3: - Squashed cma_get_name and cma_alloc/release patches - Fixed typo in Export dev_get_cma_area commit title - Fixed compilation failure with DMA_CMA but not OF_RESERVED_MEM - Link to v2: https://lore.kernel.org/r/20260227-dma-buf-heaps-as-modules-v2-0-454aee7e06… 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 (8): 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 dma: contiguous: Export dev_get_cma_area() mm: cma: Export cma_alloc(), cma_release() and 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 | 18 ++++++++++-------- kernel/dma/contiguous.c | 37 ++++++++++++++++++++++++++++++++++--- mm/cma.c | 3 +++ 7 files changed, 60 insertions(+), 29 deletions(-) --- base-commit: 499a718536dc0e1c1d1b6211847207d58acd9916 change-id: 20260225-dma-buf-heaps-as-modules-1034b3ec9f2a Best regards, -- Maxime Ripard <mripard(a)kernel.org>

2 weeks

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

by Albert Esteve

Hi Maxime! On Thu, Feb 26, 2026 at 11:12 AM Maxime Ripard <mripard(a)redhat.com> wrote: > > Hi Albert, > > Thanks for your patch! > > On Tue, Feb 24, 2026 at 08:57:33AM +0100, Albert Esteve wrote: > > 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 > > I'm not sure we need to make it configurable. Distros are going to set > it to the user with the highest number of regions anyway. How about > using MAX_RESERVED_REGIONS for now? Makes sense, will do. > > > > > [...] > > > > +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 > > We might want to leave the dmem accounting out for now so we can focus > on the heap itself. That being said, it ended up being pretty trivial > for CMA, so maybe it's not too much of a concern. Sure. That allows us to follow the same patterns once the CMA series lands. I will strip all dmem accounting parts for v2. > > > > > [...] > > > > +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"; > > If the reserved region has no name, we probably shouldn't expose it to > userspace at all. Using unknown will probably create some bugs if you > have several, but also it's pretty like to have a name at some point and > thus we wouldn't have a stable name for the uAPI. Agreed. I will return an error code if no name is present. > > > + 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; > > + } > > Similarly, we shouldn't use the coherent_ prefix for the heap name. If > the backing allocator ever changes (and between contiguous and coherent, > the difference is just a single property value in the DT), then the name > would change and userspace would break. We should directly use the name > of the region here. > > > + 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; > > + } > > We probably should use a faux_device here instead of a platform_device, > but more importantly, the heap itself already has a device allocated for > it (dev_ret in dma_heap_add). > > It's not in struct dma_heap yet, but there's a patch that moves it there > that we should probably carry: > https://lore.kernel.org/r/20210120210937.15069-2-john.stultz@linaro.org/ Thanks for sharing the link! I will pick the patch. > > > + if (rmem->ops && rmem->ops->device_init) { > > + ret = rmem->ops->device_init(rmem, &coh_heap->pdev->dev); > > + if (ret) > > + goto pdev_unregister; > > + } > > I'm not really a fan of calling ops directly. Maybe we should create an > of_reserved_mem_device_init_with_mem function that would do it for us > (and would be called by of_reserved_mem_device_init_by_idx and the > likes). Agreed. > > > + 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 > > Same comment than for CMA here: it should really be created by the > coherent memory region itself. > > > + 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; > > +} > > I appreciate you did it like we did for CMA, but if we ever want to make > that heap a module you'll end up with a dependency from the core kernel > on a module which doesn't work. The best here might be to wait a bit > until we have somewhat of an agreement on > > https://lore.kernel.org/r/20260225-dma-buf-heaps-as-modules-v1-0-2109225a09… > > > +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); > > Why do you need a late_initcall here? Isn't module_init enough? When I tested this initially, I relied on direct invocations from cma/coherent.c to register new coherent heap areas. However it failed in `kzalloc_obj` calls within the register function. Then I read the article about boot time memory management[1] and saw other drivers collected info for deferred initialization at late_initcall(), similar to what I tried to do here. I honestly did not try with module_init(). Since I will refactor this part to follow your previous comments, I will try to update if possible. [1] https://docs.kernel.org/core-api/boot-time-mm.html > > > +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); > > + } > > I think this should be split into a patch of its own. It's going to be > reviewed (and possibly merged) by another maintainer, through another > tree. That's fine. I will split it into another series then. I guess I can send it with a Based-On: tag or similar to link two series together? BR, Albert > > Maxime

2 weeks

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig