Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

69 participants
6233 discussions

Re: [RFC v2 PATCH 06/10] vfio/pci: Remove vfio_pci_zap_bars()

by Christian König

On 3/12/26 19:46, Matt Evans wrote: > vfio_pci_zap_bars() and the wrapper > vfio_pci_zap_and_down_write_memory_lock() are redundant as of > "vfio/pci: Convert BAR mmap() to use a DMABUF". The DMABUFs used for > BAR mappings already zap PTEs via the existing > vfio_pci_dma_buf_move(), which notifies changes to the BAR space > (e.g. around reset). > > Remove the old functions, and the various points needing to zap BARs > become slightly cleaner. No a full review, but it looks like you now take the DMA buf reservation lock while holding vdev->memory_lock. I strongly recommend enabling lockdep while testing that, just to be on the sure side that all locks are taken in a consistend order. Regards, Christian. > > Signed-off-by: Matt Evans <mattev(a)meta.com> > --- > drivers/vfio/pci/vfio_pci_config.c | 18 ++++++------------ > drivers/vfio/pci/vfio_pci_core.c | 30 +++++++----------------------- > drivers/vfio/pci/vfio_pci_priv.h | 1 - > 3 files changed, 13 insertions(+), 36 deletions(-) > > diff --git a/drivers/vfio/pci/vfio_pci_config.c b/drivers/vfio/pci/vfio_pci_config.c > index b4e39253f98d..c7ed28be1104 100644 > --- a/drivers/vfio/pci/vfio_pci_config.c > +++ b/drivers/vfio/pci/vfio_pci_config.c > @@ -590,12 +590,9 @@ static int vfio_basic_config_write(struct vfio_pci_core_device *vdev, int pos, > virt_mem = !!(le16_to_cpu(*virt_cmd) & PCI_COMMAND_MEMORY); > new_mem = !!(new_cmd & PCI_COMMAND_MEMORY); > > - if (!new_mem) { > - vfio_pci_zap_and_down_write_memory_lock(vdev); > + down_write(&vdev->memory_lock); > + if (!new_mem) > vfio_pci_dma_buf_move(vdev, true); > - } else { > - down_write(&vdev->memory_lock); > - } > > /* > * If the user is writing mem/io enable (new_mem/io) and we > @@ -712,12 +709,9 @@ static int __init init_pci_cap_basic_perm(struct perm_bits *perm) > static void vfio_lock_and_set_power_state(struct vfio_pci_core_device *vdev, > pci_power_t state) > { > - if (state >= PCI_D3hot) { > - vfio_pci_zap_and_down_write_memory_lock(vdev); > + down_write(&vdev->memory_lock); > + if (state >= PCI_D3hot) > vfio_pci_dma_buf_move(vdev, true); > - } else { > - down_write(&vdev->memory_lock); > - } > > vfio_pci_set_power_state(vdev, state); > if (__vfio_pci_memory_enabled(vdev)) > @@ -908,7 +902,7 @@ static int vfio_exp_config_write(struct vfio_pci_core_device *vdev, int pos, > &cap); > > if (!ret && (cap & PCI_EXP_DEVCAP_FLR)) { > - vfio_pci_zap_and_down_write_memory_lock(vdev); > + down_write(&vdev->memory_lock); > vfio_pci_dma_buf_move(vdev, true); > pci_try_reset_function(vdev->pdev); > if (__vfio_pci_memory_enabled(vdev)) > @@ -993,7 +987,7 @@ static int vfio_af_config_write(struct vfio_pci_core_device *vdev, int pos, > &cap); > > if (!ret && (cap & PCI_AF_CAP_FLR) && (cap & PCI_AF_CAP_TP)) { > - vfio_pci_zap_and_down_write_memory_lock(vdev); > + down_write(&vdev->memory_lock); > vfio_pci_dma_buf_move(vdev, true); > pci_try_reset_function(vdev->pdev); > if (__vfio_pci_memory_enabled(vdev)) > diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c > index 41224efa58d8..9e9ad97c2f7f 100644 > --- a/drivers/vfio/pci/vfio_pci_core.c > +++ b/drivers/vfio/pci/vfio_pci_core.c > @@ -319,7 +319,7 @@ static int vfio_pci_runtime_pm_entry(struct vfio_pci_core_device *vdev, > * The vdev power related flags are protected with 'memory_lock' > * semaphore. > */ > - vfio_pci_zap_and_down_write_memory_lock(vdev); > + down_write(&vdev->memory_lock); > vfio_pci_dma_buf_move(vdev, true); > > if (vdev->pm_runtime_engaged) { > @@ -1229,7 +1229,7 @@ static int vfio_pci_ioctl_reset(struct vfio_pci_core_device *vdev, > if (!vdev->reset_works) > return -EINVAL; > > - vfio_pci_zap_and_down_write_memory_lock(vdev); > + down_write(&vdev->memory_lock); > > /* > * This function can be invoked while the power state is non-D0. If > @@ -1613,22 +1613,6 @@ ssize_t vfio_pci_core_write(struct vfio_device *core_vdev, const char __user *bu > } > EXPORT_SYMBOL_GPL(vfio_pci_core_write); > > -static void vfio_pci_zap_bars(struct vfio_pci_core_device *vdev) > -{ > - struct vfio_device *core_vdev = &vdev->vdev; > - loff_t start = VFIO_PCI_INDEX_TO_OFFSET(VFIO_PCI_BAR0_REGION_INDEX); > - loff_t end = VFIO_PCI_INDEX_TO_OFFSET(VFIO_PCI_ROM_REGION_INDEX); > - loff_t len = end - start; > - > - unmap_mapping_range(core_vdev->inode->i_mapping, start, len, true); > -} > - > -void vfio_pci_zap_and_down_write_memory_lock(struct vfio_pci_core_device *vdev) > -{ > - down_write(&vdev->memory_lock); > - vfio_pci_zap_bars(vdev); > -} > - > u16 vfio_pci_memory_lock_and_enable(struct vfio_pci_core_device *vdev) > { > u16 cmd; > @@ -2487,10 +2471,11 @@ static int vfio_pci_dev_set_hot_reset(struct vfio_device_set *dev_set, > } > > /* > - * Take the memory write lock for each device and zap BAR > - * mappings to prevent the user accessing the device while in > - * reset. Locking multiple devices is prone to deadlock, > - * runaway and unwind if we hit contention. > + * Take the memory write lock for each device and > + * revoke all DMABUFs, which will prevent any access > + * to the device while in reset. Locking multiple > + * devices is prone to deadlock, runaway and unwind if > + * we hit contention. > */ > if (!down_write_trylock(&vdev->memory_lock)) { > ret = -EBUSY; > @@ -2498,7 +2483,6 @@ static int vfio_pci_dev_set_hot_reset(struct vfio_device_set *dev_set, > } > > vfio_pci_dma_buf_move(vdev, true); > - vfio_pci_zap_bars(vdev); > } > > if (!list_entry_is_head(vdev, > diff --git a/drivers/vfio/pci/vfio_pci_priv.h b/drivers/vfio/pci/vfio_pci_priv.h > index 37ece9b4b5bd..e201c96bbb14 100644 > --- a/drivers/vfio/pci/vfio_pci_priv.h > +++ b/drivers/vfio/pci/vfio_pci_priv.h > @@ -78,7 +78,6 @@ void vfio_config_free(struct vfio_pci_core_device *vdev); > int vfio_pci_set_power_state(struct vfio_pci_core_device *vdev, > pci_power_t state); > > -void vfio_pci_zap_and_down_write_memory_lock(struct vfio_pci_core_device *vdev); > u16 vfio_pci_memory_lock_and_enable(struct vfio_pci_core_device *vdev); > void vfio_pci_memory_unlock_and_restore(struct vfio_pci_core_device *vdev, > u16 cmd);

2 weeks, 1 day

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, 2 days

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, 2 days

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, 2 days

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, 2 days

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, 3 days

[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, 3 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, 3 days

I HAVE RETRIEVED MY LOCKED BTC 🥳

by Ambrose MacQuoid

2 weeks, 3 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, 4 days

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig