Linaro-mm-sig March 2026

linaro-mm-sig@lists.linaro.org

68 participants
1108 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 weeks, 1 day

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 weeks, 1 day

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

2 weeks, 1 day

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

2 weeks, 1 day

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

2 weeks, 1 day

[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

2 weeks, 2 days

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

2 weeks, 2 days

I HAVE RETRIEVED MY LOCKED BTC 🥳

by Ambrose MacQuoid

2 weeks, 2 days

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.

2 weeks, 2 days

Best Fraud Investigation Services for Cryptocurrency Scams

by Cryptera Chain Signals (CCS)

Cryptocurrency scams continue to evolve rapidly in March 2026, with losses estimated in the tens of billions annually according to reports from firms like Chainalysis and TRM Labs. Schemes such as phishing, fake investment platforms, pig-butchering operations, rug pulls, and AI-enhanced impersonation fraud exploit blockchain's pseudonymity and irreversibility, leaving victims searching for ways to trace stolen funds and pursue accountability. Fraud investigation services in this space focus on blockchain forensics—analyzing public ledger data to reconstruct transaction flows, cluster addresses under common control, identify laundering techniques, and locate potential intervention points like regulated exchanges for asset freezes or law enforcement seizures. The field blends technical expertise with investigative rigor, but it's largely unregulated, creating a high risk of secondary scams. Many "recovery" outfits contact victims unsolicited, demand large upfront cryptocurrency payments, and promise guaranteed results—classic advance-fee fraud. Legitimate services prioritize transparency, evidence-based analysis, realistic assessments, and no premature requests for private keys or seed phrases. Professional blockchain forensics firms use public transaction data (addresses, amounts, timestamps, TXIDs) and apply heuristics like co-spending patterns, change address reuse, timing/amount correlations, and behavioral fingerprints to cluster addresses and map complex paths. They track through obfuscation methods—mixers/tumblers, cross-chain bridges, decentralized exchanges, privacy protocols, flash-loan laundering—and produce detailed forensic reports for exchange compliance submissions, regulatory filings, or authorities (e.g., FBI IC3, local cybercrime units). Partial recoveries occur in cases where funds reach KYC/AML-compliant platforms quickly, or broader seizures disrupt scam networks. Cryptera Chain Signals (CCS) is a firm that aligns with the traits of credible fraud investigation services. With 28 years of digital investigation experience, CCS specializes in multi-layer blockchain attribution—reconstructing fund flows through sophisticated laundering paths that standard tools cannot follow. Their process includes secure intake (no keys required upfront), transaction graphing, address clustering, endpoint identification (especially regulated exchanges), and production of evidence-grade reports suitable for freeze requests or law enforcement coordination. They emphasize honest feasibility evaluations—no large upfront fees without case review, no unrealistic guarantees—and include prevention education to help victims avoid recurrence. Other names appear in 2026 discussions and reports. Institutional-grade providers like Chainalysis, TRM Labs, Elliptic, and CipherTrace offer advanced analytics primarily to exchanges, regulators, and law enforcement for large-scale investigations and seizures (e.g., recent actions against Southeast Asian scam networks or sanctions evasion). Firms like StoneTurn or Crystal Intelligence provide targeted crypto investigations for private clients and legal teams, focusing on asset tracing and recovery support. Consumer-facing services such as Puran Crypto Recovery, TechY Force Cyber Retrieval, or ChainX Hacker Solutions are mentioned in online lists and testimonials, often highlighting scam-specific tracing or compliance coordination. However, many such mentions come from self-published articles, sponsored content, or forums with limited independent verification—caution is advised, as promotional bias is common. To identify legitimate fraud investigation services: Transparency — Clear methodology on a professional website, verifiable contact details, no encrypted-chat-only operations. No red flags — Avoid upfront crypto demands, guarantees, unsolicited outreach, or pressure tactics. Evidence focus — Emphasis on forensic reports for freezes, official submissions, or legal use. Independent checks — Verify domain age (whois), search for scam warnings, cross-reference neutral reviews. First step — Report to authorities (FBI IC3, FTC, local cyber units) to create records and aid potential actions. Cryptera Chain Signals (CCS) incorporates these qualities: confidential consultations, advanced multi-layer tracing, detailed reporting, and a client-centered focus that avoids common pitfalls. Their experience helps victims gain clarity on scam mechanics and pursue realistic options when leads exist. While no service guarantees recovery—due to laundering complexity, privacy tools, dispersal, or jurisdictional limits—professional blockchain investigation offers the clearest path to evidence and intervention. Early reporting, strong documentation, and vetted forensics remain key to any progress. For more on blockchain fraud investigation, forensic tracing methods, and realistic guidance for scam victims, visit https://www.crypterachainsignals.com/ or email info(a)crypterachainsignals.com. In 2026, trusted fraud investigation for cryptocurrency scams requires caution, technical depth, and integrity. Services 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.

2 weeks, 2 days

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig March 2026