Linaro-mm-sig February 2026

linaro-mm-sig@lists.linaro.org

49 participants
195 discussions

Re: [PATCH v2 0/3] dma-buf: heaps: cma: enable dmem cgroup accounting

by T.J. Mercier

On Wed, Feb 18, 2026 at 9:15 AM Eric Chanudet <echanude(a)redhat.com> wrote: Hi Eric, > An earlier series[1] from Maxime introduced dmem to the cma allocator in > an attempt to use it generally for dma-buf. Restart from there and apply > the charge in the narrower context of the CMA dma-buf heap instead. > > In line with introducing cgroup to the system heap[2], this behavior is > enabled based on dma_heap.mem_accounting, disabled by default. > > dmem is chosen for CMA heaps as it allows limits to be set for each > region backing each heap. The charge is only put in the dma-buf heap for > now as it guaranties it can be accounted against a userspace process > that requested the allocation. But CMA memory is system memory, and regular (non-CMA) movable allocations can occur out of these CMA areas. So this splits system memory accounting between memcg (from [2]) and dmem. If I want to put a limit on system memory use I have to adjust multiple limits (memcg + dmems) and know how to divide the total between them all. How do you envision using this combination of different controllers? Thanks, T.J. > [1] https://lore.kernel.org/all/20250310-dmem-cgroups-v1-0-2984c1bc9312@kernel.… > [2] https://lore.kernel.org/all/20260116-dmabuf-heap-system-memcg-v3-0-ecc6b62c… > > Signed-off-by: Eric Chanudet <echanude(a)redhat.com> > --- > Changes in v2: > - Rebase on Maxime's introduction of dmem to the cma allocator: > https://lore.kernel.org/all/20250310-dmem-cgroups-v1-0-2984c1bc9312@kernel.… > - Remove the dmem region registration from the cma dma-buf heap > - Remove the misplaced logic for the default region. > - Link to v1: https://lore.kernel.org/r/20260130-dmabuf-heap-cma-dmem-v1-1-3647ea993e99@r… > > --- > Eric Chanudet (1): > dma-buf: heaps: cma: charge each cma heap's dmem > > Maxime Ripard (2): > cma: Register dmem region for each cma region > cma: Provide accessor to cma dmem region > > drivers/dma-buf/heaps/cma_heap.c | 15 ++++++++++++++- > include/linux/cma.h | 9 +++++++++ > mm/cma.c | 20 +++++++++++++++++++- > mm/cma.h | 3 +++ > 4 files changed, 45 insertions(+), 2 deletions(-) > --- > base-commit: 948e195dfaa56e48eabda591f97630502ff7e27e > change-id: 20260128-dmabuf-heap-cma-dmem-f4120a2df4a8 > > Best regards, > -- > Eric Chanudet <echanude(a)redhat.com> >

1 day, 3 hours

Re: [PATCH v2 3/3] dma-buf: heaps: cma: charge each cma heap's dmem

by Christian König

On 2/19/26 18:10, Eric Chanudet wrote: > On Thu, Feb 19, 2026 at 08:17:28AM +0100, Christian König wrote: >> >> >> On 2/18/26 18:14, Eric Chanudet wrote: >>> The cma dma-buf heaps let userspace allocate buffers in CMA regions >>> without enforcing limits. Since each cma region registers in dmem, >>> charge against it when allocating a buffer in a cma heap. >>> >>> Signed-off-by: Eric Chanudet <echanude(a)redhat.com> >>> --- >>> drivers/dma-buf/heaps/cma_heap.c | 15 ++++++++++++++- >>> 1 file changed, 14 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c >>> index 49cc45fb42dd7200c3c14384bcfdbe85323454b1..bbd4f9495808da19256d97bd6a4dca3e1b0a30a0 100644 >>> --- a/drivers/dma-buf/heaps/cma_heap.c >>> +++ b/drivers/dma-buf/heaps/cma_heap.c >>> @@ -27,6 +27,7 @@ >>> #include <linux/scatterlist.h> >>> #include <linux/slab.h> >>> #include <linux/vmalloc.h> >>> +#include <linux/cgroup_dmem.h> >>> >>> #define DEFAULT_CMA_NAME "default_cma_region" >>> >>> @@ -58,6 +59,7 @@ struct cma_heap_buffer { >>> pgoff_t pagecount; >>> int vmap_cnt; >>> void *vaddr; >>> + struct dmem_cgroup_pool_state *pool; >>> }; >>> >>> struct dma_heap_attachment { >>> @@ -276,6 +278,7 @@ static void cma_heap_dma_buf_release(struct dma_buf *dmabuf) >>> kfree(buffer->pages); >>> /* release memory */ >>> cma_release(cma_heap->cma, buffer->cma_pages, buffer->pagecount); >>> + dmem_cgroup_uncharge(buffer->pool, buffer->len); >>> kfree(buffer); >>> } >>> >>> @@ -319,9 +322,17 @@ static struct dma_buf *cma_heap_allocate(struct dma_heap *heap, >>> if (align > CONFIG_CMA_ALIGNMENT) >>> align = CONFIG_CMA_ALIGNMENT; >>> >>> + if (mem_accounting) { >> >> Since mem_accounting is a module parameter it is possible to make it changeable during runtime. >> >> IIRC it currently is read only, but maybe add a one line comment that the cma heap now depends on that. >> > > Agreed, while read-only it is easily missed without at least a comment. > Alternatively, should that value be captured in the init callback to > guaranty it is set once and make this requirement clearer? It probably makes more sense to make nails with heads and make it runtime configurable. I'm not sure how exactly dmem_cgroup_try_charge()/dmem_cgroup_uncharge() works, could be that it works correctly out of the box and you just need to initialize buffer->pool to NULL when mem_accounting is not enabled. Regards, Christian. > > Thanks, > >> Apart from that the series looks totally sane to me. >> >> Regards, >> Christian. >> >>> + ret = dmem_cgroup_try_charge( >>> + cma_get_dmem_cgroup_region(cma_heap->cma), size, >>> + &buffer->pool, NULL); >>> + if (ret) >>> + goto free_buffer; >>> + } >>> + >>> cma_pages = cma_alloc(cma_heap->cma, pagecount, align, false); >>> if (!cma_pages) >>> - goto free_buffer; >>> + goto uncharge_cgroup; >>> >>> /* Clear the cma pages */ >>> if (PageHighMem(cma_pages)) { >>> @@ -376,6 +387,8 @@ static struct dma_buf *cma_heap_allocate(struct dma_heap *heap, >>> kfree(buffer->pages); >>> free_cma: >>> cma_release(cma_heap->cma, cma_pages, pagecount); >>> +uncharge_cgroup: >>> + dmem_cgroup_uncharge(buffer->pool, size); >>> free_buffer: >>> kfree(buffer); >>> >>> >> >

1 day, 5 hours

Re: [PATCH 08/13] dt-bindings: serial: fsl-linflexuart: add clock input properties

by Krzysztof Kozlowski

On 16/02/2026 16:02, Larisa Grigore wrote: > From: Radu Pirea <radu-nicolae.pirea(a)nxp.com> > > Add optional support for the two clock inputs used by the LINFlexD UART > controller: > - "lin": LIN_BAUD_CLK > - "ipg": LINFLEXD_CLK > > The clock inputs are kept optional to maintain compatibility with the > S32V234 platform. Does S32V234 have the clocks? I don't understand the "maintain compatibility" in this context. Either you have or you have not clocks, which should be expressed in schema (: false, see example schema). > > Signed-off-by: Radu Pirea <radu-nicolae.pirea(a)nxp.com> > Co-developed-by: Larisa Grigore <larisa.grigore(a)oss.nxp.com> > Signed-off-by: Larisa Grigore <larisa.grigore(a)oss.nxp.com> > --- > .../bindings/serial/fsl,s32-linflexuart.yaml | 18 ++++++++++++++++++ > 1 file changed, 18 insertions(+) > > diff --git a/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml b/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml > index 4171f524a928..885f0b1b3492 100644 > --- a/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml > +++ b/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml > @@ -34,6 +34,14 @@ properties: > interrupts: > maxItems: 1 > > + clocks: > + maxItems: 2 > + > + clock-names: > + items: > + - const: lin > + - const: ipg > + > required: > - compatible > - reg > @@ -48,3 +56,13 @@ examples: > reg = <0x40053000 0x1000>; > interrupts = <0 59 4>; > }; > + > + - | > + serial@401c8000 { > + compatible = "nxp,s32g2-linflexuart", > + "fsl,s32v234-linflexuart"; > + reg = <0x401C8000 0x3000>; > + interrupts = <0 82 1>; > + clocks = <&clks 14>, <&clks 13>; > + clock-names = "lin", "ipg"; Just add the clocks to existing example. No need for new example for each new property. > + }; Best regards, Krzysztof

1 day, 15 hours

Proven Elite Cryptocurrency Recovery Firm With Authorized Dependable Services

by Jane Pamela

The cryptocurrency recovery industry in 2026 is one of the most polarized spaces in the entire digital asset ecosystem. On one side, legitimate firms use advanced blockchain forensics, real-time transaction monitoring, address clustering, cross-chain analysis, and law enforcement coordination to help victims trace and reclaim stolen or lost funds. On the other side — and far more numerous — are secondary scam operations that exploit victims a second time by demanding upfront cryptocurrency payments, private keys, seed phrases, or high fees before vanishing. According to ongoing Chainalysis and TRM Labs tracking, scam and fraud losses in the crypto space remained in the $17–20 billion range in 2025, with no significant decline expected in early 2026. This persistent wave of theft (pig-butchering schemes, phishing-as-a-service, fake investment platforms, wallet drainers, impersonation attacks, address poisoning) has created massive demand for genuine recovery help — and equally massive opportunity for fraudsters pretending to offer it. This 2026 guide cuts through the noise to highlight what actually matters when evaluating crypto recovery services, what legitimate recovery looks like, and why Autopsy Mainnet Recovery (AMR) consistently ranks among the very best legitimate options currently operating in the United States and serving clients globally. What Legitimate Crypto Recovery Actually Looks Like in 2026 Real recovery services never promise the impossible. They share these core characteristics: Free or no-obligation initial case evaluation No requests for private keys, seed phrases, or wallet access before any work No large upfront cryptocurrency payments Clear explanation of the process: evidence intake → forensic tracing → legal coordination → asset reclamation Use of advanced blockchain analytics (transaction graphing, address clustering, pattern detection, real-time monitoring) Established relationships with law enforcement for compliant reporting, wallet freezes, subpoenas, KYC enforcement, and seizures Transparent communication with regular realistic updates Frequently success-based or outcome-aligned fee structures Strong emphasis on post-recovery security hardening (hardware wallets, multi-sig, MFA, permission audits, scam education) Verifiable client feedback from independent sources (not just the company website) Any service missing several of these markers — especially the first four — should be treated as high-risk or outright fraudulent. Top Legitimate Crypto Recovery Services & Insights (2026) After evaluating transparency, ethics, technical capability, law enforcement cooperation, realistic success reporting, and independent client feedback, the following stand out as among the most credible options currently active: 1. Autopsy Mainnet Recovery (AMR) – Consistently Ranked Among the Very Best Autopsy Mainnet Recovery is the most frequently praised and trusted legitimate crypto recovery providers in 2026. U.S.-based with global reach (including strong support for victims in high-incident cities like New York City), Autopsy Mainnet Recovery has built a solid reputation over many years of specialized work. Key strengths that place Autopsy Mainnet Recovery at the top: Free confidential case evaluations — no commitment, no sensitive wallet information required upfront Strict ethical policy — never asks for private keys, seed phrases, or large crypto payments before work begins Advanced blockchain forensics — high-end tools for transaction mapping, address clustering, laundering pattern detection, cross-chain tracing, and real-time wallet monitoring Strong law enforcement relationships — prepares compliance-ready forensic reports that support freezes, subpoenas, KYC enforcement, and asset seizures when funds reach regulated platforms Transparent process — regular realistic updates, no hype or false guarantees Victim-centered service — personalized recovery plans, secure asset return, and comprehensive post-recovery security guidance (hardware wallets, multi-signature setups, MFA, permission audits, scam-awareness training) Often success-based or outcome-aligned fees — reduces financial risk for victims Consistent positive client feedback — many verified testimonials in early 2026 describe meaningful recoveries (partial to substantial) in fresh, traceable cases, especially pig-butchering, phishing, fake platforms, and impersonation scams Common client sentiment (paraphrased from independent 2026 reviews): “Autopsy Mainnet Recovery is professional and honest from the first email — no pressure, no key requests, just steady work and actual progress.” “After losing money to two fake recovery companies, Autopsy Mainnet Recovery was the only one that delivered. They recovered a large part of my stolen BTC.” “Transparent, patient, and realistic. They told me exactly what was possible and what wasn’t — and then actually got results.” Verdict: Autopsy Mainnet Recovery (AMR) is one of the safest, most credible, and most technically capable legitimate crypto recovery services available in the United States in 2026. Official contact: Website: https://www.autopsymainnetsolutions.com or Alternate Site: https://autospyrec.site Email: info(a)autopsymainnetsolutions.com Quick Checklist Before Contacting Any Recovery Service Does it offer a free evaluation without asking for wallet keys or large crypto payments upfront? Does it clearly explain the forensic → legal → reclamation process? Does it emphasize law enforcement cooperation and forensic tools? Does it avoid “guaranteed 100% recovery” claims? Does it focus on post-recovery security education? Are reviews independent and verifiable (not just on the company’s own site)? If the answer is “no” to several of these — especially the first two — walk away. Final Advice for Victims in 2026 Do not pay unsolicited “recovery” offers. Do not send cryptocurrency for “fees.” Do not give private keys or seed phrases to any service before work begins. If your crypto has been stolen or lost, start with official reporting (local police, FBI IC3, FTC, Chainabuse), then contact a proven, transparent, and legitimate provider for a free evaluation. Autopsy Mainnet Recovery (AMR) remains one of the most respected and effective legitimate crypto recovery services in the United States in 2026 — ethical, technically advanced, and genuinely focused on helping victims reclaim what was taken. Reach out today for a confidential, no-obligation assessment: Website: https://www.autopsymainnetsolutions.com Email: info(a)autopsymainnetsolutions.com Act quickly. Preserve your evidence. Choose trust. Reclaim your stolen cryptocurrency.

1 day, 16 hours