Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

86 participants
6551 discussions

by Alex Morgan

ghost mystery recovery Hacker in 2026 ghost mystery recovery Hacker for 2026 include ghost mystery Recovery Hacker And which utilize blockchain forensics and legal strategies to recover stolen or lost assets. These firms specialize in tracing funds, working with law enforcement, and providing expert testimony to freeze assets. ghost mystery recovery Hacker Highly rated for 2026 for using AI-powered tools to trace funds across exchanges and privacy coins, with a focus on scams and hacked wallets. Email address: support@ ghostmysteryrecovery. c om WhatsApp on (+44) 7480 061765 Website; ghostmysteryrecovery. c om

1 month, 1 week

Storage Renewal Failed - Update Your Information Now | ID:493194-53725

by Cloud Customer Support

1 month, 1 week

Eingles

by Korbinian Arendt

Ghost mystery recovery Hacker in 2026, was Verified as The Best Cryptocurrency Recovery ghost mystery recovery Hacker, established in 2026, is a trusted leader in cryptocurrency recovery. Known for its professionalism, ghost helps clients recover lost or stolen funds from scams, hacks, and unauthorized transactions. With advanced tools and a dedicated team, they offer tailored solutions for ghost recovery across blockchains. Customers value ghost for its transparency, fast response, and confidential service. Its success rate and commitment make it a top choice for crypto investors. Email address: support@ ghostmysteryrecovery. c om WhatsApp on (+44) 7480 061765 Website; ghostmysteryrecovery. c om

1 month, 1 week

HOW TO CREATE FLASH USDT FOR TRADING, GAMING AND ONLINE PURCHASES

by romeoexpert8＠gmail.com

In the world of crypto, speed and security aren’t just conveniences—they’re essentials. That’s exactly what Flash USDT delivers. Designed for traders, businesses, and anyone who values instant and reliable transfers, Flash USDT is a powerful software tailored for peer-to-peer USDT (Tether) transactions that are fast, low-cost, and seamless. Official Website: https://globalflashhubs.com/ Whether you're managing a P2P exchange or simply need a trusted tool for transferring digital assets, Flash BTC and USDT offer the performance and security you expect, integrated smoothly into your workflow. What’s New with Flash Coin and Generator Software? Enhanced support for trading P2P across BTC and USDT TRC20 networks, catering to betting, gaming, and forex platforms. New installation guides for Windows and mobile devices, making setup easier than ever. Expanded blockch@in compatibility, allowing you to flash coins directly to Bin@nce, Trust Wallet, and more with confidence. Flash BTC and USDT TRC20 transfers last up to 90 days, ensuring flexibility Why Choose Flash Coin? It’s more than just software—it’s a commitment to trust and efficiency. With Flash Coin, you gain access to one of the most reliable services online for crypto transactions, designed to keep your exchanges swift and secure across multiple platforms. Ready to experience the difference? Shop now and see why traders and businesses worldwide rely on Flash Coin for their digital asset needs. Get Started Today Learn how to install and operate Flash Generator software with easy-to-follow instructions for your device. Whether on desktop or mobile, integrating this tool into your daily routine has never been simpler. Have questions or need support? Reach out directly through our official channels: Official Website: https://globalflashhubs.com/ WhatsApp: https://wa.link/8q02qv Telegram: https://t.me/billier5 Explore more about our products and how Flash USDT can transform your crypto experience:

1 month, 1 week

[PATCH] mm/vmalloc: map contiguous pages in batches for vmap() whenever possible

by Barry Song

From: Barry Song <v-songbaohua(a)oppo.com> In many cases, the pages passed to vmap() may include high-order pages allocated with __GFP_COMP flags. For example, the systemheap often allocates pages in descending order: order 8, then 4, then 0. Currently, vmap() iterates over every page individually—even pages inside a high-order block are handled one by one. This patch detects high-order pages and maps them as a single contiguous block whenever possible. An alternative would be to implement a new API, vmap_sg(), but that change seems to be large in scope. When vmapping a 128MB dma-buf using the systemheap, this patch makes system_heap_do_vmap() roughly 17× faster. W/ patch: [ 10.404769] system_heap_do_vmap took 2494000 ns [ 12.525921] system_heap_do_vmap took 2467008 ns [ 14.517348] system_heap_do_vmap took 2471008 ns [ 16.593406] system_heap_do_vmap took 2444000 ns [ 19.501341] system_heap_do_vmap took 2489008 ns W/o patch: [ 7.413756] system_heap_do_vmap took 42626000 ns [ 9.425610] system_heap_do_vmap took 42500992 ns [ 11.810898] system_heap_do_vmap took 42215008 ns [ 14.336790] system_heap_do_vmap took 42134992 ns [ 16.373890] system_heap_do_vmap took 42750000 ns Cc: David Hildenbrand <david(a)kernel.org> Cc: Uladzislau Rezki <urezki(a)gmail.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: John Stultz <jstultz(a)google.com> Cc: Maxime Ripard <mripard(a)kernel.org> Tested-by: Tangquan Zheng <zhengtangquan(a)oppo.com> Signed-off-by: Barry Song <v-songbaohua(a)oppo.com> --- * diff with rfc: Many code refinements based on David's suggestions, thanks! Refine comment and changelog according to Uladzislau, thanks! rfc link: https://lore.kernel.org/linux-mm/20251122090343.81243-1-21cnbao@gmail.com/ mm/vmalloc.c | 45 +++++++++++++++++++++++++++++++++++++++------ 1 file changed, 39 insertions(+), 6 deletions(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 41dd01e8430c..8d577767a9e5 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -642,6 +642,29 @@ static int vmap_small_pages_range_noflush(unsigned long addr, unsigned long end, return err; } +static inline int get_vmap_batch_order(struct page **pages, + unsigned int stride, unsigned int max_steps, unsigned int idx) +{ + int nr_pages = 1; + + /* + * Currently, batching is only supported in vmap_pages_range + * when page_shift == PAGE_SHIFT. + */ + if (stride != 1) + return 0; + + nr_pages = compound_nr(pages[idx]); + if (nr_pages == 1) + return 0; + if (max_steps < nr_pages) + return 0; + + if (num_pages_contiguous(&pages[idx], nr_pages) == nr_pages) + return compound_order(pages[idx]); + return 0; +} + /* * vmap_pages_range_noflush is similar to vmap_pages_range, but does not * flush caches. @@ -655,23 +678,33 @@ int __vmap_pages_range_noflush(unsigned long addr, unsigned long end, pgprot_t prot, struct page **pages, unsigned int page_shift) { unsigned int i, nr = (end - addr) >> PAGE_SHIFT; + unsigned int stride; WARN_ON(page_shift < PAGE_SHIFT); + /* + * For vmap(), users may allocate pages from high orders down to + * order 0, while always using PAGE_SHIFT as the page_shift. + * We first check whether the initial page is a compound page. If so, + * there may be an opportunity to batch multiple pages together. + */ if (!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMALLOC) || - page_shift == PAGE_SHIFT) + (page_shift == PAGE_SHIFT && !PageCompound(pages[0]))) return vmap_small_pages_range_noflush(addr, end, prot, pages); - for (i = 0; i < nr; i += 1U << (page_shift - PAGE_SHIFT)) { - int err; + stride = 1U << (page_shift - PAGE_SHIFT); + for (i = 0; i < nr; ) { + int err, order; - err = vmap_range_noflush(addr, addr + (1UL << page_shift), + order = get_vmap_batch_order(pages, stride, nr - i, i); + err = vmap_range_noflush(addr, addr + (1UL << (page_shift + order)), page_to_phys(pages[i]), prot, - page_shift); + page_shift + order); if (err) return err; - addr += 1UL << page_shift; + addr += 1UL << (page_shift + order); + i += 1U << (order + page_shift - PAGE_SHIFT); } return 0; -- 2.39.3 (Apple Git-146)

1 month, 1 week

Understanding Blockchain Forensics:

by joelwest689＠gmail.com

By combining cross-chain tracing, rapid response, and data-driven investigation, Cipher Rescue Chain stands as the global benchmark for crypto recovery. Every traced transaction, every reconstructed path, and every recovered asset reinforces the same conclusion: with the right forensic expertise, recovery is not only possible—it is highly achievable.

1 month, 1 week

[PATCH] dma-fence: Clarify external lock use case in dma_fence_init() docs

by Maíra Canal

The kerneldoc comment on dma_fence_init() and dma_fence_init64() describe the legacy reason to pass an external lock as a need to prevent multiple fences "from signaling out of order". However, this wording is a bit misleading: a shared spinlock does not (and cannot) prevent the signaler from signaling out of order. Signaling order is the driver's responsibility regardless of whether the lock is shared or per-fence. What a shared lock actually provides is serialization of signaling and observation across fences in a given context, so that observers never see a later fence signaled while an earlier one is not. Reword both comments to describe this more accurately. Signed-off-by: Maíra Canal <mcanal(a)igalia.com> --- Hi, While reading the documentation, I found this particular paragraph quite hard to understand. As I understand it, locks don't enforce order, only serialization, but the paragraph seems to communicate the other way around. Due to that, I had the impression that the current wording can be misleading for driver developers. I'm proposing a new wording to better describe the use case of the external lock based on my understanding, but it would be great to hear the feedback and suggestions from more experienced developers who might have more insight about these legacy use cases. Best regards, - Maíra drivers/dma-buf/dma-fence.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index 1826ba73094c..bdc29d1c1b5c 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -1102,8 +1102,10 @@ __dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops *ops, * to check which fence is later by simply using dma_fence_later(). * * It is strongly discouraged to provide an external lock because this couples - * lock and fence life time. This is only allowed for legacy use cases when - * multiple fences need to be prevented from signaling out of order. + * lock and fence lifetime. This is only allowed for legacy use cases that need + * a shared lock to serialize signaling and observation of fences within a + * context, so that observers never see a later fence signaled while an earlier + * one isn't. */ void dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops *ops, @@ -1129,8 +1131,10 @@ EXPORT_SYMBOL(dma_fence_init); * to check which fence is later by simply using dma_fence_later(). * * It is strongly discouraged to provide an external lock because this couples - * lock and fence life time. This is only allowed for legacy use cases when - * multiple fences need to be prevented from signaling out of order. + * lock and fence lifetime. This is only allowed for legacy use cases that need + * a shared lock to serialize signaling and observation of fences within a + * context, so that observers never see a later fence signaled while an earlier + * one isn't. */ void dma_fence_init64(struct dma_fence *fence, const struct dma_fence_ops *ops, -- 2.53.0

1 month, 1 week

[PATCH] dma-buf: fix order of trace and fput

by Christian König

Dropping the last reference to the DMA-buf and then accessing the name for tracing can't work correctly. Only compile tested! Signed-off-by: Christian König <christian.koenig(a)amd.com> Fixed: 281a22631423 ("dma-buf: add some tracepoints to debug.") --- drivers/dma-buf/dma-buf.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 11711874a325..3a9d5113b98c 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -845,9 +845,8 @@ void dma_buf_put(struct dma_buf *dmabuf) if (WARN_ON(!dmabuf || !dmabuf->file)) return; - fput(dmabuf->file); - DMA_BUF_TRACE(trace_dma_buf_put, dmabuf); + fput(dmabuf->file); } EXPORT_SYMBOL_NS_GPL(dma_buf_put, "DMA_BUF"); -- 2.43.0

1 month, 1 week

[PATCH 1/3] dma-fence: Silce sparse warning in dma_fence_describe

by Tvrtko Ursulin

Sparse complains about assigning a string to a __rcu annotated local variable: drivers/dma-buf/dma-fence.c:1040:38: warning: incorrect type in initializer (different address spaces) drivers/dma-buf/dma-fence.c:1040:38: expected char const [noderef] __rcu *timeline drivers/dma-buf/dma-fence.c:1040:38: got char * drivers/dma-buf/dma-fence.c:1041:36: warning: incorrect type in initializer (different address spaces) drivers/dma-buf/dma-fence.c:1041:36: expected char const [noderef] __rcu *driver drivers/dma-buf/dma-fence.c:1041:36: got char * It is harmless but lets silence it. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> Fixes: ac364014fd81 ("dma-buf: cleanup dma_fence_describe v3") Cc: Christian König <christian.koenig(a)amd.com> Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org --- drivers/dma-buf/dma-fence.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index 1826ba73094c..a2aa82f4eedd 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -1037,8 +1037,8 @@ EXPORT_SYMBOL(dma_fence_set_deadline); */ void dma_fence_describe(struct dma_fence *fence, struct seq_file *seq) { - const char __rcu *timeline = ""; - const char __rcu *driver = ""; + const char __rcu *timeline = (const char __rcu *)""; + const char __rcu *driver = (const char __rcu *)""; const char *signaled = ""; rcu_read_lock(); -- 2.52.0

1 month, 1 week

[PATCH] dma-buf: set SB_I_NOEXEC and SB_I_NODEV on dmabuf filesystem

by Chia-Lin Kao (AceLan)

The VFS now warns if an inode flagged with S_ANON_INODE is located on a filesystem that does not have SB_I_NOEXEC set. dmabuf inodes are created using alloc_anon_inode(), which sets S_ANON_INODE. This triggers a warning in path_noexec() when a dmabuf is mmapped, for example by GStreamer's v4l2src element. [ 60.061328] WARNING: CPU: 2 PID: 2803 at fs/exec.c:125 path_noexec+0xa0/0xd0 ... [ 60.061637] do_mmap+0x2b5/0x680 The warning was introduced by commit 1e7ab6f67824 ("anon_inode: rework assertions") which added enforcement that anonymous inodes must be on filesystems with SB_I_NOEXEC set. Fix this by setting SB_I_NOEXEC and SB_I_NODEV on the dmabuf filesystem context, following the same pattern as commit ce7419b6cf23d ("anon_inode: raise SB_I_NODEV and SB_I_NOEXEC") and commit 98f99394a104c ("secretmem: use SB_I_NOEXEC"). Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao(a)canonical.com> --- drivers/dma-buf/dma-buf.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index a4d8f2ff94e46..dea79aaab10ce 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -221,6 +221,8 @@ static int dma_buf_fs_init_context(struct fs_context *fc) if (!ctx) return -ENOMEM; ctx->dops = &dma_buf_dentry_ops; + fc->s_iflags |= SB_I_NOEXEC; + fc->s_iflags |= SB_I_NODEV; return 0; } -- 2.51.0

1 month, 1 week

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig