Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

49 participants
6027 discussions

Re: [PATCH 00/15] tracepoint: Avoid double static_branch evaluation at guarded call sites

by Peter Zijlstra

On Thu, Mar 12, 2026 at 11:49:23AM -0400, Mathieu Desnoyers wrote: > On 2026-03-12 11:40, Steven Rostedt wrote: > > On Thu, 12 Mar 2026 11:28:07 -0400 > > Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> wrote: > > > > > > Note, Vineeth came up with the naming. I would have done "do" but when I > > > > saw "invoke" I thought it sounded better. > > > > > > It works as long as you don't have a tracing subsystem called > > > "invoke", then you get into identifier clash territory. > > > > True. Perhaps we should do the double underscore trick. > > > > Instead of: trace_invoke_foo() > > > > use: trace_invoke__foo() > > > > > > Which will make it more visible to what the trace event is. > > > > Hmm, we probably should have used: trace__foo() for all tracepoints, as > > there's still functions that are called trace_foo() that are not > > tracepoints :-p > > One certain way to eliminate identifier clash would be to go for a > prefix to "trace_", e.g. Oh, I know!, call them __do_trace_##foo(). /me runs like hell

2 hours, 57 minutes

Re: [PATCH 01/15] tracepoint: Add trace_invoke_##name() API

by Peter Zijlstra

On Thu, Mar 12, 2026 at 11:39:06AM -0400, Vineeth Remanan Pillai wrote: > On Thu, Mar 12, 2026 at 11:13 AM Steven Rostedt <rostedt(a)goodmis.org> wrote: > > > > On Thu, 12 Mar 2026 11:04:56 -0400 > > "Vineeth Pillai (Google)" <vineeth(a)bitbyteword.org> wrote: > > > > > Add trace_invoke_##name() as a companion to trace_##name(). When a > > > caller already guards a tracepoint with an explicit enabled check: > > > > > > if (trace_foo_enabled() && cond) > > > trace_foo(args); > > > > > > trace_foo() internally repeats the static_branch_unlikely() test, which > > > the compiler cannot fold since static branches are patched binary > > > instructions. This results in two static-branch evaluations for every > > > guarded call site. > > > > > > trace_invoke_##name() calls __do_trace_##name() directly, skipping the > > > redundant static-branch re-check. This avoids leaking the internal > > > __do_trace_##name() symbol into call sites while still eliminating the > > > double evaluation: > > > > > > if (trace_foo_enabled() && cond) > > > trace_invoke_foo(args); /* calls __do_trace_foo() directly */ > > > > > > Three locations are updated: > > > - __DECLARE_TRACE: invoke form omits static_branch_unlikely, retains > > > the LOCKDEP RCU-watching assertion. > > > - __DECLARE_TRACE_SYSCALL: same, plus retains might_fault(). > > > - !TRACEPOINTS_ENABLED stub: empty no-op so callers compile cleanly > > > when tracepoints are compiled out. > > > > > > Suggested-by: Steven Rostedt <rostedt(a)goodmis.org> > > > Suggested-by: Peter Zijlstra <peterz(a)infradead.org> > > > Signed-off-by: Vineeth Pillai (Google) <vineeth(a)bitbyteword.org> > > > Assisted-by: Claude:claude-sonnet-4-6 > > > > I'm guessing Claude helped with the other patches. Did it really help with this one? > > > > Claude wrote and build tested the whole series based on my guidance > and prompt :-). I verified the series before sending it out, but > claude did the initial work. That seems like an unreasonable waste of energy. You could've had claude write a Coccinelle script for you and saved a ton of tokens.

2 hours, 58 minutes

Re: [PATCH net-next v3 1/2] dma-mapping: introduce DMA_ATTR_CC_DECRYPTED for pre-decrypted memory

by Jason Gunthorpe

On Thu, Mar 12, 2026 at 10:03:37AM +0100, Jiri Pirko wrote: > >Alot of device MMIO is decrypted by nature and can't be encrypted, so > >you'd have to use both flags. eg in VFIO we'd want to do this. > > Why both flags? Why MMIO flag is not enough? You still want to hit > "if (attrs & DMA_ATTR_MMIO) {" path, don't you? Because we will eventually have both decrypted and encrypted MMIO. > I mean, CC_DECRYPTED says the memory to be mapped was explicitly > decrypted before the call. MMIO was not explicitly decrypted, it is > decrypted by definition. For me that does not fit the CC_DECRYPTED > semantics. I would say CC_DECRYPTED means that pgprot_decrypted must be used to form a PTE, and !CC_DECRYPTED means that pgprot_encrypted() was used This flag should someday flow down into the vIOMMU driver and set the corresponding C bit the IOPTE (for AMD) exactly as the pgprot does. Less about set_memory_encrypted as that is only for DRAM. Jason

6 hours, 45 minutes

I HAVE RETRIEVED MY LOCKED BTC 🥳

by Ambrose MacQuoid

Hey everyone! I'm thrilled to announce that I have fully rec0vered my l0cked BTC from an inve stment platf0rm even after 3 months it happened. Here's a quick story. Early this year, I came across an inve stment platf0rm that gave me my profit after the first inve stment , I did the second it was successful and I tried the 3rd this time with a bigger amount of $120,000, when it was time for withdr awal I couldn't, the option was l0cked, After weeks of trying I l0st hope, fast-forward to last week I saw a post about rec0 vering l0cked or st0len fuñ ds, tho I was skeptical but I gave it a try what more could I lose?? In 2 4hrs ghosttrackhackers@gmail . com h€lped me r€trieve my full fuπds (of $120,000) including profit ($40,000). It's back safe in my w@ll€t. I know many have fallen v!ct!m too you can re@ch out to th€m for h€lp they're l€git and €asy to talk to. Goodluck. ✉️: ghosttrackhackers @ gmail . com

9 hours, 44 minutes

Re: [PATCH net-next v3 1/2] dma-mapping: introduce DMA_ATTR_CC_DECRYPTED for pre-decrypted memory

by Jason Gunthorpe

On Mon, Mar 09, 2026 at 06:51:21PM +0100, Jiri Pirko wrote: > Mon, Mar 09, 2026 at 04:18:57PM +0100, jgg(a)ziepe.ca wrote: > >On Mon, Mar 09, 2026 at 04:02:33PM +0200, Leon Romanovsky wrote: > >> On Mon, Mar 09, 2026 at 10:15:30AM -0300, Jason Gunthorpe wrote: > >> > On Sun, Mar 08, 2026 at 12:19:48PM +0200, Leon Romanovsky wrote: > >> > > >> > > > +/* > >> > > > + * DMA_ATTR_CC_DECRYPTED: Indicates memory that has been explicitly decrypted > >> > > > + * (shared) for confidential computing guests. The caller must have > >> > > > + * called set_memory_decrypted(). A struct page is required. > >> > > > + */ > >> > > > +#define DMA_ATTR_CC_DECRYPTED (1UL << 12) > >> > > > >> > > While adding the new attribute is fine, I would expect additional checks in > >> > > dma_map_phys() to ensure the attribute cannot be misused. For example, > >> > > WARN_ON(attrs & (DMA_ATTR_CC_DECRYPTED | DMA_ATTR_MMIO)), along with a check > >> > > that we are taking the direct path only. > >> > > >> > DECRYPYED and MMIO is something that needs to work, VFIO (inside a > >> > TVM) should be using that combination. > >> > >> So this sentence "A struct page is required" from the comment above is > >> not accurate. > > > >It would be clearer to say "Unless DMA_ATTR_MMIO is provided a struct > >page is required" > > > >We need to audit if that works properly, IIRC it does, but I don't > >remember.. Jiri? > > How can you do set_memory_decrypted if you don't have page/folio ? Alot of device MMIO is decrypted by nature and can't be encrypted, so you'd have to use both flags. eg in VFIO we'd want to do this. Jason

18 hours, 17 minutes

[PATCH v8 0/7] Rust bindings for gem shmem + iosys_map

by Lyude Paul

This is the next version of the shmem backed GEM objects series originally from Asahi, previously posted by Daniel Almeida. One of the major changes in this patch series is a much better interface around vmaps, which we achieve by introducing a new set of rust bindings for iosys_map. The previous version of the patch series can be found here: https://patchwork.freedesktop.org/series/156093/ This patch series may be applied on top of the driver-core/driver-core-testing branch: https://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core.git… Changelogs are per-patch Asahi Lina (2): rust: helpers: Add bindings/wrappers for dma_resv_lock rust: drm: gem: shmem: Add DRM shmem helper abstraction Lyude Paul (5): rust: drm: Add gem::impl_aref_for_gem_obj! rust: drm: gem: Add raw_dma_resv() function rust: gem: Introduce DriverObject::Args rust: drm: gem: Introduce shmem::SGTable rust: drm/gem: Add vmap functions to shmem bindings drivers/gpu/drm/nova/gem.rs | 5 +- drivers/gpu/drm/tyr/gem.rs | 3 +- rust/bindings/bindings_helper.h | 3 + rust/helpers/dma-resv.c | 13 + rust/helpers/drm.c | 56 +++- rust/helpers/helpers.c | 1 + rust/kernel/drm/gem/mod.rs | 79 +++-- rust/kernel/drm/gem/shmem.rs | 529 ++++++++++++++++++++++++++++++++ 8 files changed, 667 insertions(+), 22 deletions(-) create mode 100644 rust/helpers/dma-resv.c create mode 100644 rust/kernel/drm/gem/shmem.rs -- 2.53.0

22 hours, 29 minutes

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

by Albert Esteve

This patch series adds a new dma-buf heap driver that exposes coherent, non‑reusable reserved-memory regions as named heaps, so userspace can explicitly allocate buffers from those device‑specific pools. Motivation: we want cgroup accounting for all userspace‑visible buffer allocations (DRM, v4l2, dma‑buf heaps, etc.). That’s hard to do when drivers call dma_alloc_attrs() directly because the accounting controller (memcg vs dmem) is ambiguous. The long‑term plan is to steer those paths toward dma‑buf heaps, where each heap can unambiguously charge a single controller. To reach that goal, we need a heap backend for each dma_alloc_attrs() memory type. CMA and system heaps already exist; coherent reserved‑memory was the missing piece, since many SoCs define dedicated, device‑local coherent pools in DT under /reserved-memory using "shared-dma-pool" with non‑reusable regions (i.e., not CMA) that are carved out exclusively for coherent DMA and are currently only usable by in‑kernel drivers. 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 v3: - Reorganized changesets among patches to ensure bisectability - Removed unused dma_heap_coherent_register() leftover - Removed fallback when setting mask in coherent heap dev, since dma_set_mask() already truncates to supported masks - Moved struct rmem_assigned_device (rd) logic to of_reserved_mem_device_init_with_mem() to allow listing the device - Link to v2: https://lore.kernel.org/r/20260303-b4-dmabuf-heap-coherent-rmem-v2-0-65a465… 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: coherent: store reserved memory coherent regions dma-buf: heaps: Add Coherent heap to dmabuf heaps 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 | 417 ++++++++++++++++++++++++++++++++++ drivers/of/of_reserved_mem.c | 68 ++++-- include/linux/dma-heap.h | 5 + include/linux/dma-map-ops.h | 7 + include/linux/of_reserved_mem.h | 8 + kernel/dma/coherent.c | 34 +++ 9 files changed, 640 insertions(+), 47 deletions(-) --- base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f change-id: 20260223-b4-dmabuf-heap-coherent-rmem-91fd3926afe9 Best regards, -- Albert Esteve <aesteve(a)redhat.com>

1 day, 3 hours

Re: [PATCH] lib/scatterlist: fix sg_page_count and sg_dma_page_count

by Jason Gunthorpe

On Wed, Mar 11, 2026 at 06:53:51AM +0000, Kasireddy, Vivek wrote: > So, given the current situation, what is the right thing to do? > Should we take your patch that brings back the pages array and treat it as > a temporary fix until equivalent folio based APIs are available? IMHO, yes. It saves memory, increases performance, fixes the bug and uses the APIs properly. Jason

1 day, 6 hours

I HAVE RETRIEVED MY LOCKED BTC 🥳

by Ambrose MacQuoid

1 day, 8 hours

Professional Digital Assets Recovery and Investigation Services

by Cryptera Chain Signals (CCS)

The digital asset space in March 2026 continues to grow rapidly, but so do the risks. Phishing attacks, fake investment platforms, pig-butchering schemes, wallet exploits, rug pulls, and address-poisoning fraud result in billions in losses annually. Once cryptocurrency leaves a victim's control—whether through deception, malware, or access issues—blockchain's irreversible and pseudonymous design offers no central authority for reversal or reset. Recovery becomes a matter of investigation, forensic tracing, evidence gathering, and coordinated action rather than simple reversal. Professional digital assets recovery and investigation services focus on two primary areas: (1) restoring access to legitimately owned but locked wallets (forgotten passwords, damaged hardware, corrupted files), and (2) tracing stolen funds to map movement, identify laundering patterns, and locate potential intervention points such as regulated centralized exchanges for asset freezes or law enforcement seizures. These services rely on public blockchain data—transaction hashes (TXIDs), addresses, amounts, timestamps—and advanced analytics to reconstruct flows that basic explorers cannot follow. Legitimate providers never guarantee full recovery; blockchain immutability prevents that. Success is partial at best and depends on early detection, evidence quality, laundering complexity, and cooperation from exchanges or authorities. The industry is unregulated, creating a high risk of secondary scams: fraudsters contact victims unsolicited, demand large upfront cryptocurrency payments, promise guaranteed results, and disappear. Official warnings from the FBI, FTC, and blockchain analytics firms consistently identify these as advance-fee fraud. Trusted services share common traits: Transparent methodology explained on professional websites Free or low-cost initial consultations to review evidence (TXIDs, addresses, communications) No requests for private keys, seed phrases, or wallet access upfront Honest feasibility assessments without absolute guarantees Focus on forensic reports for exchange compliance submissions, regulatory filings, or law enforcement coordination (FBI IC3, local cyber units) Emphasis on prevention education (hardware wallets, address verification, secure backups, monitoring) Cryptera Chain Signals (CCS) is a firm that aligns with these standards of professional digital assets recovery and investigation. With 28 years of experience in digital forensics—long before cryptocurrencies became mainstream—CCS specializes in multi-layer blockchain attribution. Their process reconstructs transaction paths through complex obfuscation methods (mixers, cross-chain bridges, DEX swaps, privacy protocols, flash-loan laundering), clusters addresses using behavioral heuristics (co-spending patterns, change address reuse, timing/amount correlations), identifies high-confidence endpoints on KYC/AML-compliant exchanges, and produces detailed forensic reports suitable for freeze requests or official submissions. They prioritize secure intake, transparency—no large upfront fees without case evaluation—and realistic guidance, helping victims understand fund movements and viable next steps. Other established names in the space include institutional analytics providers like Chainalysis, TRM Labs, Elliptic, and CipherTrace, which primarily serve exchanges, regulators, and law enforcement for large-scale tracing and seizures. Consumer-facing firms such as KeychainX (often for password/seed recovery), Wallet Recovery Services, Crypto Asset Recovery, and Puran Crypto Recovery appear in forums and testimonials for access restoration or scam tracing. Many mentions, however, originate from self-published articles or sponsored content, so independent verification is essential. To identify legitimate services: Transparency — Clear website with methodology details, verifiable contact information. No red flags — Avoid upfront crypto demands, guarantees, unsolicited outreach, pressure tactics. Evidence focus — Emphasis on forensic reports for freezes, official submissions, or legal use. Independent checks — Verify domain age (whois), search scam warnings, cross-reference neutral reviews. First action — Report to authorities (FBI IC3, FTC, local police) before engaging any service—official reports create records and may aid broader actions. Cryptera Chain Signals (CCS) incorporates these qualities: confidential consultations, advanced multi-layer tracing, detailed forensic reporting, honest assessments, and a focus on client education and protection. Their experience supports victims in gaining clarity on access issues or stolen-fund movements and pursuing realistic options when leads exist. While no service guarantees recovery—due to strong encryption, complete seed loss, heavy laundering, dispersal, or jurisdictional limits—professional digital assets investigation offers the clearest path to evidence and intervention. Early action (secure remaining assets, document evidence, report officially) and choosing vetted providers remain essential. For more information on professional blockchain forensics, transaction tracing methods, and realistic guidance for digital asset recovery, visit https://www.crypterachainsignals.com/ or email info(a)crypterachainsignals.com. In 2026, trusted digital assets recovery and investigation require caution, technical depth, and integrity. Firms like Cryptera Chain Signals (CCS) represent the kind of professional, evidence-based approach that prioritizes transparency and realistic outcomes in a high-risk and often exploitative field.

1 day, 16 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig