Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

107 participants
7066 discussions

[PATCH v4 1/2] accel/rocket: Fix error path handling in rocket_job_run()

by ZhaoJinming

In rocket_job_run(), after taking an extra fence reference for job->done_fence via dma_fence_get(), the error paths have three bugs: - The dma_fence reference held by job->done_fence is never released, causing a reference leak. - pm_runtime_get_sync() increments the usage counter even on failure, but the error path does not decrement it, leaking the runtime PM reference and preventing the NPU from suspending. - A valid but unsignaled fence is returned to the DRM scheduler, which triggers WARN("Fence ... released with pending signals!") when the scheduler drops its reference. Fix by replacing pm_runtime_get_sync() with pm_runtime_resume_and_get() which auto-balances the usage counter on failure, releasing both fence references on error, and returning ERR_PTR(ret) instead of the unsignaled fence. Cc: stable(a)vger.kernel.org Fixes: 0810d5ad88a1 ("accel/rocket: Add job submission IOCTL") Signed-off-by: ZhaoJinming <zhaojinming(a)uniontech.com> --- drivers/accel/rocket/rocket_job.c | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/drivers/accel/rocket/rocket_job.c b/drivers/accel/rocket/rocket_job.c index ac51bff39833..e8a073e22ac2 100644 --- a/drivers/accel/rocket/rocket_job.c +++ b/drivers/accel/rocket/rocket_job.c @@ -310,13 +310,22 @@ static struct dma_fence *rocket_job_run(struct drm_sched_job *sched_job) dma_fence_put(job->done_fence); job->done_fence = dma_fence_get(fence); - ret = pm_runtime_get_sync(core->dev); - if (ret < 0) - return fence; + ret = pm_runtime_resume_and_get(core->dev); + if (ret < 0) { + dma_fence_put(job->done_fence); + job->done_fence = NULL; + dma_fence_put(fence); + return ERR_PTR(ret); + } ret = iommu_attach_group(job->domain->domain, core->iommu_group); - if (ret < 0) - return fence; + if (ret < 0) { + pm_runtime_put(core->dev); + dma_fence_put(job->done_fence); + job->done_fence = NULL; + dma_fence_put(fence); + return ERR_PTR(ret); + } scoped_guard(mutex, &core->job_lock) { core->in_flight_job = job; -- 2.20.1

2 weeks, 1 day

[PATCH v19 0/4] Rust bindings for gem shmem

by Lyude Paul

Most of this patch series has already been pushed upstream, this is just the second half of the patch series that has not been pushed yet + some additional changes which were required to implement changes requested by the mailing list. This patch series is originally from Asahi, previously posted by Daniel Almeida. The previous version of the patch series can be found here: https://patchwork.freedesktop.org/series/164580/ Branch with patches applied available here: https://gitlab.freedesktop.org/lyudess/linux/-/commits/rust/gem-shmem This patch series applies on top of drm-rust-next Patch-series wide changes since V15: * Fix some major rebasing errors I somehow didn't notice :( * Drop the dependency on LazyInit, use the trick that Alice suggested instead. * Fix dependency ordering so that Tyr can get the vmap stuff first without the other bits. Patch-series wide changes since V16: * Fix ordering one more time (SetOnce::reset() doesn't need to come before adding vmap functions) * Rebase against the latest DeviceContext changes from me that got pushed. Lyude Paul (4): rust: drm: gem: shmem: Add DmaResvGuard helper rust: drm: gem: shmem: Add vmap functions rust: faux: Allow retrieving a bound Device rust: drm: gem: Introduce shmem::Object::sg_table() rust/kernel/drm/gem/shmem.rs | 524 ++++++++++++++++++++++++++++++++++- rust/kernel/faux.rs | 16 +- 2 files changed, 524 insertions(+), 16 deletions(-) base-commit: fea3a2dd7d3fc1936211ced5f84420e610435730 -- 2.54.0

2 weeks, 1 day

MUYERN TRUST HACKER || Private Digital Security

by priyankaragade6＠gmail.com

It is 2026. Cryptocurrency is no longer just an investment; it is the backbone of a new global financial system. Millions of people now manage their wealth through digital assets like Bitcoin, Ethereum, and USDT. This shift has brought unprecedented financial freedom, but it has also opened the door to a new era of cybercrime. From sophisticated phishing attacks and fake investment platforms to direct wallet hacks, the methods used by scammers have become increasingly complex. Every day, victims lose access to their hard-earned digital assets. The feeling of helplessness is overwhelming—but it is not the end of the story. At MUYERN TRUST HACKER, we turn that helplessness into action. Recognized as the Best, Top, and Most Trusted Cryptocurrency Recovery Company in 2026, we have been fighting crypto crime since 2010. With over $990 Million recovered and a reported 99% success rate, we don’t just promise results; we deliver them. But how exactly do we recover what seems lost? Here is a look at our proven methodology. The Myth of "Untraceable" Crypto Many victims believe that once crypto is stolen, it is gone forever because blockchain is anonymous. This is a misconception. Blockchain is pseudonymous, not anonymous. Every transaction leaves a permanent, public footprint. While scammers use mixers and bridges to hide their tracks, they eventually need to cash out. That is where they make mistakes—and where we step in. Our 4-Step Recovery Process We combine cutting-edge technology with legal expertise to trace, freeze, and return your assets. 1. Forensic Case Assessment Recovery begins with intelligence. When you contact us, our experts conduct a deep-dive analysis of your case. We review transaction hashes, wallet addresses, and communication logs to identify the type of fraud (e.g., romance scam, investment fraud, or hack). We determine the viability of recovery before proceeding, ensuring transparency and honesty from day one. 2. Advanced Blockchain Tracing Using proprietary forensic tools, we trace the movement of your funds across multiple blockchains. Even if scammers attempt to launder money through decentralized exchanges (DEXs) or privacy protocols, our algorithms identify patterns and link illicit addresses to known entities. We follow the money trail until it reaches a point of vulnerability—usually a centralized exchange or a regulated financial institution. 3. Strategic Legal Intervention Tracing is only half the battle. To recover funds, we must act where the criminals cash out. We collaborate with: Global Exchanges: Providing irrefutable forensic evidence to freeze accounts holding stolen funds. Law Enforcement: Assisting cybercrime units with detailed investigation reports. Legal Networks: Navigating international jurisdictions to secure asset returns through legal channels. This multi-pronged approach puts immense pressure on bad actors and compliant platforms to return the assets. 4. Secure Asset Return & Protection Once funds are recovered, we facilitate their secure transfer back to your personal wallet. But our job doesn’t end there. We provide a post-recovery security audit, helping you strengthen your digital defenses to prevent future attacks. We believe in empowering our clients, not just rescuing them. Why MUYERN TRUST HACKER is the Leader in 2026 In an industry rife with secondary scams, trust is everything. Here is why thousands of victims choose us: Proven Longevity: Operating since 2010, we have evolved alongside the technology, giving us unmatched experience. Massive Impact: We have recovered over $990 Million in digital assets for individuals and businesses worldwide. High Success Rate: Our rigorous vetting process ensures a reported 99% Crypto Recovery Rate for accepted cases. Global Reach: Cybercrime has no borders, and neither do we. Our network spans major financial hubs across the globe. Don’t Let Scammers Win If you have lost cryptocurrency to fraud, hacks, or scams, time is critical. The faster you act, the higher the chance of recovery. You do not have to face this alone. Join the thousands of clients who have reclaimed their financial freedom with MUYERN TRUST HACKER. Ready to Start Your Recovery? Contact our specialist team today for a confidential, no-obligation case assessment. Email: [ muyerntrusted(at)mail-me(.)c o m ] What App: [ +1.2.0.2.7.0.3.2.2.3.9 ]

2 weeks, 1 day

[PATCH v7] dma-buf: Fix silent overflow for phys vec to sgt

by David Hu

In case MMIO size is bigger than 4G and peer2peer DMA goes through host bridge, we trigger a code path that assigns the total linked IOVA (which is greater than 4G) to mapped_len. Previously, `mapped_len` was declared as 32-bit `unsigned int`. When accumulating `size_t` lengths, this leads to a silent wrap-around. This truncation causes truncated lengths to be passed to functions like `fill_sg_entry()`. Fix this by changing `mapped_len` to `size_t` (64-bit). While at it, fix similar potential overflow issues in `calc_sg_nents` by using `check_add_overflow()` for `nents` and using `unsigned int` for the loop iterator in `fill_sg_entry` to match. Fixes: 3aa31a8bb11e ("dma-buf: provide phys_vec to scatter-gather mapping routine") Cc: stable(a)vger.kernel.org Cc: iommu(a)lists.linux.dev Reviewed-by: Pranjal Shrivastava <praan(a)google.com> Reviewed-by: Kevin Tian <kevin.tian(a)intel.com> Reviewed-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: David Hu <xuehaohu(a)google.com> --- Changes in v7: - Added a missing blank line after local variable declaration in `calc_sg_nents()` (Leon). - Collected Reviewed-by from Leon Romanovsky. Changes in v6: - Used `check_add_overflow()` in `calc_sg_nents()` for safer accumulation (Leon). - Dropped explicit `!nents` check and added a comment noting that `sg_alloc_table` handles `nents == 0` (Leon). - Collected Reviewed-by from Kevin Tian. Changes in v5: - Removed WARN_ON_ONCE from calc_sg_nents() to avoid log noise (Jason). - Added explicit check for `!nents` in dma_buf_phys_vec_to_sgt() to cleanly return -EINVAL on overflow (Jason). Changes in v4: - Added WARN_ON_ONCE() to the nents overflow check to prevent silent failures (Claude Bot). Changes in v3: - Removed leftover sentence fragment from the commit message. - Kept `nents = 0` initialization (previously stated as removed in the v2 changelog) as it is strictly required for the `+=` accumulation loop in `calc_sg_nents()`. Changes in v2: - Fixed 'IVOA' -> 'IOVA' typo and expanded commit message (Claude Bot). - Added Reverse Xmas tree formatting (Pranjal). - Folded in extra bounds checking for calc_sg_nents() (Pranjal). - Folded in type consistency fix for fill_sg_entry() (Pranjal). - Collected Reviewed-by from Pranjal Shrivastava. drivers/dma-buf/dma-buf-mapping.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/drivers/dma-buf/dma-buf-mapping.c b/drivers/dma-buf/dma-buf-mapping.c index 794acff2546a..80f6ab2f4809 100644 --- a/drivers/dma-buf/dma-buf-mapping.c +++ b/drivers/dma-buf/dma-buf-mapping.c @@ -5,12 +5,13 @@ */ #include <linux/dma-buf-mapping.h> #include <linux/dma-resv.h> +#include <linux/overflow.h> static struct scatterlist *fill_sg_entry(struct scatterlist *sgl, size_t length, dma_addr_t addr) { unsigned int len, nents; - int i; + unsigned int i; nents = DIV_ROUND_UP(length, UINT_MAX); for (i = 0; i < nents; i++) { @@ -40,8 +41,12 @@ static unsigned int calc_sg_nents(struct dma_iova_state *state, size_t i; if (!state || !dma_use_iova(state)) { - for (i = 0; i < nr_ranges; i++) - nents += DIV_ROUND_UP(phys_vec[i].len, UINT_MAX); + for (i = 0; i < nr_ranges; i++) { + unsigned int added = DIV_ROUND_UP(phys_vec[i].len, UINT_MAX); + + if (check_add_overflow(nents, added, &nents)) + return 0; + } } else { /* * In IOVA case, there is only one SG entry which spans @@ -95,9 +100,10 @@ struct sg_table *dma_buf_phys_vec_to_sgt(struct dma_buf_attachment *attach, size_t nr_ranges, size_t size, enum dma_data_direction dir) { - unsigned int nents, mapped_len = 0; struct dma_buf_dma *dma; struct scatterlist *sgl; + size_t mapped_len = 0; + unsigned int nents; dma_addr_t addr; size_t i; int ret; @@ -133,6 +139,8 @@ struct sg_table *dma_buf_phys_vec_to_sgt(struct dma_buf_attachment *attach, } nents = calc_sg_nents(dma->state, phys_vec, nr_ranges, size); + + /* sg_alloc_table will cleanly fail and return -EINVAL if nents == 0 */ ret = sg_alloc_table(&dma->sgt, nents, GFP_KERNEL | __GFP_ZERO); if (ret) goto err_free_state; -- 2.54.0.1064.gd145956f57-goog

2 weeks, 1 day

[PATCH v6] dma-buf: Fix silent overflow for phys vec to sgt

by David Hu

In case MMIO size is bigger than 4G and peer2peer DMA goes through host bridge, we trigger a code path that assigns the total linked IOVA (which is greater than 4G) to mapped_len. Previously, `mapped_len` was declared as 32-bit `unsigned int`. When accumulating `size_t` lengths, this leads to a silent wrap-around. This truncation causes truncated lengths to be passed to functions like `fill_sg_entry()`. Fix this by changing `mapped_len` to `size_t` (64-bit). While at it, fix similar potential overflow issues in `calc_sg_nents` by using `check_add_overflow()` for `nents` and using `unsigned int` for the loop iterator in `fill_sg_entry` to match. Fixes: 3aa31a8bb11e ("dma-buf: provide phys_vec to scatter-gather mapping routine") Cc: stable(a)vger.kernel.org Cc: iommu(a)lists.linux.dev Reviewed-by: Pranjal Shrivastava <praan(a)google.com> Reviewed-by: Kevin Tian <kevin.tian(a)intel.com> Signed-off-by: David Hu <xuehaohu(a)google.com> --- Changes in v6: - Used `check_add_overflow()` in `calc_sg_nents()` for safer accumulation (Leon). - Dropped explicit `!nents` check and added a comment noting that `sg_alloc_table` handles `nents == 0` (Leon). - Collected Reviewed-by from Kevin Tian. Changes in v5: - Removed WARN_ON_ONCE from calc_sg_nents() to avoid log noise (Jason). - Added explicit check for `!nents` in dma_buf_phys_vec_to_sgt() to cleanly return -EINVAL on overflow (Jason). Changes in v4: - Added WARN_ON_ONCE() to the nents overflow check to prevent silent failures (Claude Bot). Changes in v3: - Removed leftover sentence fragment from the commit message. - Kept `nents = 0` initialization (previously stated as removed in the v2 changelog) as it is strictly required for the `+=` accumulation loop in `calc_sg_nents()`. Changes in v2: - Fixed 'IVOA' -> 'IOVA' typo and expanded commit message (Claude Bot). - Added Reverse Xmas tree formatting (Pranjal). - Folded in extra bounds checking for calc_sg_nents() (Pranjal). - Folded in type consistency fix for fill_sg_entry() (Pranjal). - Collected Reviewed-by from Pranjal Shrivastava. drivers/dma-buf/dma-buf-mapping.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/drivers/dma-buf/dma-buf-mapping.c b/drivers/dma-buf/dma-buf-mapping.c index 794acff2546a..67a8ff52fb8f 100644 --- a/drivers/dma-buf/dma-buf-mapping.c +++ b/drivers/dma-buf/dma-buf-mapping.c @@ -5,12 +5,13 @@ */ #include <linux/dma-buf-mapping.h> #include <linux/dma-resv.h> +#include <linux/overflow.h> static struct scatterlist *fill_sg_entry(struct scatterlist *sgl, size_t length, dma_addr_t addr) { unsigned int len, nents; - int i; + unsigned int i; nents = DIV_ROUND_UP(length, UINT_MAX); for (i = 0; i < nents; i++) { @@ -40,8 +41,11 @@ static unsigned int calc_sg_nents(struct dma_iova_state *state, size_t i; if (!state || !dma_use_iova(state)) { - for (i = 0; i < nr_ranges; i++) - nents += DIV_ROUND_UP(phys_vec[i].len, UINT_MAX); + for (i = 0; i < nr_ranges; i++) { + unsigned int added = DIV_ROUND_UP(phys_vec[i].len, UINT_MAX); + if (check_add_overflow(nents, added, &nents)) + return 0; + } } else { /* * In IOVA case, there is only one SG entry which spans @@ -95,9 +99,10 @@ struct sg_table *dma_buf_phys_vec_to_sgt(struct dma_buf_attachment *attach, size_t nr_ranges, size_t size, enum dma_data_direction dir) { - unsigned int nents, mapped_len = 0; struct dma_buf_dma *dma; struct scatterlist *sgl; + size_t mapped_len = 0; + unsigned int nents; dma_addr_t addr; size_t i; int ret; @@ -133,6 +138,8 @@ struct sg_table *dma_buf_phys_vec_to_sgt(struct dma_buf_attachment *attach, } nents = calc_sg_nents(dma->state, phys_vec, nr_ranges, size); + + /* sg_alloc_table will cleanly fail and return -EINVAL if nents == 0 */ ret = sg_alloc_table(&dma->sgt, nents, GFP_KERNEL | __GFP_ZERO); if (ret) goto err_free_state; -- 2.54.0.1064.gd145956f57-goog

2 weeks, 1 day

[PATCH] dma-buf: enable sg_table wrapping on CONFIG_DEBUG

by Christian König

Importers notoriously abused the struct page pointers from the sg_table the DMA-buf exporter provides. This has created numerous problems ranging from crashes over random memory corruption to security issues. To find such bad importers DMA-buf already has a functionality to wrap the sg_table and set the page pointers to NULL enabled under CONFIG_DMABUF_DEBUG. Change that to just CONFIG_DEBUG to catch even more importers doing something nasty. Signed-off-by: Christian König <christian.koenig(a)amd.com> --- drivers/dma-buf/dma-buf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 71f37544a5c6..d5dfa82ed2dd 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -857,7 +857,7 @@ static int dma_buf_wrap_sg_table(struct sg_table **sg_table) struct dma_buf_sg_table_wrapper *to; int i, ret; - if (!IS_ENABLED(CONFIG_DMABUF_DEBUG)) + if (!IS_ENABLED(CONFIG_DEBUG)) return 0; /* @@ -896,7 +896,7 @@ static void dma_buf_unwrap_sg_table(struct sg_table **sg_table) { struct dma_buf_sg_table_wrapper *copy; - if (!IS_ENABLED(CONFIG_DMABUF_DEBUG)) + if (!IS_ENABLED(CONFIG_DEBUG)) return; copy = container_of(*sg_table, typeof(*copy), wrapper); -- 2.43.0

2 weeks, 1 day

Does Recuva Hacker Solutions (RHS) work?

by hobertgregory05＠gmail.com

Yes. RHS operates as a blockchain investigation service, providing professional tracing and forensic reporting. RHS has contributed to major seizures, including a December 2025 case involving over $300 million linked to an international crypto fraud scheme. RHS does not promise guaranteed recovery but delivers actionable intelligence that supports law enforcement and legal action.

2 weeks, 1 day

[PATCH v3 1/2] accel/rocket: Fix error path handling in rocket_job_run()

by ZhaoJinming

2 weeks, 2 days

[PATCH v3 0/2] libfs: set SB_I_NOEXEC and SB_I_NODEV in init_pseudo()

by John Hubbard

This began as a one-line dma-buf fix for a path_noexec() warning added by commit 1e7ab6f67824 ("anon_inode: rework assertions"). Christoph pointed out that the fix belongs higher up: a pseudo filesystem has no reason not to set SB_I_NOEXEC by default. This series does that. * Patch 1 sets both flags in init_pseudo(), so every pseudo filesystem gets them. This is the only patch that changes a flag, and the only one with Fixes:/Cc: stable. * Patch 2 drops the assignments that are now redundant in the callers that set them by hand. Most callers already set one or both flags. I audited every init_pseudo() caller. Here is what patch 1 actually changes for each. The only visible effect is on dma-buf, where SB_I_NOEXEC silences the warning. SB_I_NODEV is never consulted on these SB_NOUSER mounts, and none of the callers that gain SB_I_NOEXEC are executed from. caller had patch 1 adds --------------------------- -------- -------------- fs/anon_inodes.c both nothing new mm/secretmem.c both nothing new virt/kvm/guest_memfd.c both nothing new fs/nsfs.c both nothing new fs/pidfs.c both nothing new fs/aio.c NOEXEC NODEV drivers/dma-buf/dma-buf.c neither NOEXEC + NODEV net/socket.c neither NOEXEC + NODEV fs/pipe.c neither NOEXEC + NODEV kernel/resource.c neither NOEXEC + NODEV fs/erofs/super.c neither NOEXEC + NODEV fs/btrfs/tests/... neither NOEXEC + NODEV drivers/vfio/vfio_main.c neither NOEXEC + NODEV drivers/gpu/drm/drm_drv.c neither NOEXEC + NODEV drivers/dax/super.c neither NOEXEC + NODEV block/bdev.c neither NOEXEC + NODEV John Hubbard (2): libfs: set SB_I_NOEXEC and SB_I_NODEV by default in init_pseudo() libfs: drop redundant SB_I_NOEXEC/SB_I_NODEV in init_pseudo() callers fs/aio.c | 1 - fs/anon_inodes.c | 2 -- fs/libfs.c | 1 + fs/nsfs.c | 1 - fs/pidfs.c | 2 -- mm/secretmem.c | 2 -- virt/kvm/guest_memfd.c | 2 -- 7 files changed, 1 insertion(+), 10 deletions(-) base-commit: ba3e43a9e601636f5edb54e259a74f96ca3b8fd8 -- 2.54.0

2 weeks, 2 days

Escape Road 2: Fast Lane Escape

by lilysmith10098＠gmail.com

Escape Road 2 challenges players to stay one step ahead in a world where every corner could lead to freedom or failure. Busy streets, unpredictable traffic, and constant pursuit create an exciting environment that rewards skillful driving. Players must make rapid decisions while navigating through increasingly difficult situations. The sense of momentum grows throughout each run, making survival both challenging and satisfying. Smooth vehicle handling enhances the experience, allowing daring maneuvers and creative escapes. Escape Road 2 offers a compelling mix of action and excitement that keeps players returning for another chance to extend their journey. Play game at https://escaperoad2.io

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