Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

32 participants
8007 discussions

by blanchehughes54＠gmail.com

The gameplay in granny 1 https://granny-1.io focuses on stealth and puzzle-solving rather than direct combat, making awareness and patience the most important skills. Players must move quietly through corridors, avoid making noise, and pay attention to every sound since granny can hear even the smallest disturbance. The house is filled with locked doors, secret areas, and interactive objects that create a constant sense of mystery and discovery. Each item you collect, such as keys, tools, or special components, plays a role in helping you progress toward escape.

1 hour, 17 minutes

Sprunki Game Review: A Fun and Unique Music Adventure

by blanchehughes54＠gmail.com

One of the main reasons why Sprunki Game https://sprunkigames.io has become so popular is its accessibility. Players do not need any musical knowledge or experience to enjoy the game. The drag-and-drop gameplay is easy to understand, allowing anyone to start creating music within minutes. At the same time, the large number of sound combinations provides enough depth to keep players engaged for hours.

1 hour, 18 minutes

Steal Brainrot: The Viral Game Experience Full Of Chaos

by fun.cardinal.xjqt＠hidepost.net

Steal Brainrot has quickly become a popular online game that attracts players through a mix of creativity, strategy, humor, and unexpected challenges. The game delivers a unique experience where players collect unusual characters, compete with others, and build their own progress through smart decisions. With a simple concept but highly addictive gameplay, Steal Brainrot creates an entertaining environment for casual players and dedicated fans. https://stealbrainrotgame.io/ The game stands out because of its combination of funny elements and competitive mechanics. Players must think carefully about how to manage resources, protect valuable items, and discover new opportunities. Every session brings different situations, making the gameplay feel fresh and exciting. What Is Steal Brainrot? Steal Brainrot is an online multiplayer game focused on collecting and stealing valuable Brainrot characters. The main goal involves gathering rare items, improving personal collections, and competing against other players. The game uses a humorous style with creative designs that make each character memorable. Unlike traditional games that focus only on fighting or exploration, Steal Brainrot creates entertainment through interaction between players. The competition comes from trying to obtain better Brainrot characters while defending personal progress from opponents. The simple gameplay design allows beginners to understand the basic mechanics quickly. However, reaching higher levels requires planning, timing, and knowledge about available opportunities inside the game world. The Main Concept Behind Steal Brainrot The core idea of Steal Brainrot revolves around collecting Brainrot characters and increasing their value. Players start with basic resources before expanding their collection through different actions. The excitement comes from finding rare characters and deciding the best way to use them. Every Brainrot character has different levels of rarity and importance. Some characters are easier to obtain, while others require more effort and strategic thinking. This creates motivation for players who enjoy collecting and completing goals. The stealing mechanic adds another layer of challenge. Players must stay alert because other competitors can attempt to take valuable Brainrot characters. This constant risk makes every decision more meaningful. Why Steal Brainrot Becomes Popular The popularity of Steal Brainrot comes from several important factors. First, the game provides a funny and entertaining atmosphere that appeals to a wide audience. The unusual character designs and creative ideas help the game create a recognizable identity. Another reason for its success is the competitive multiplayer system. Players are not only focused on personal progress but also on interactions with other users. This creates exciting moments that encourage people to return and continue playing. The game also benefits from its easy accessibility. New players can quickly understand the basic rules without needing complicated tutorials. At the same time, experienced players can develop advanced strategies to improve performance. Gameplay Features In Steal Brainrot Steal Brainrot includes many features that make the experience more engaging. The combination of collection systems, competition, and progression creates a gameplay loop that keeps players interested. Collecting Valuable Brainrot Characters Collection is one of the most important parts of Steal Brainrot. Players spend time searching for different Brainrot characters and building stronger collections. Finding rare characters provides a sense of achievement and encourages continued exploration. The collecting system creates long-term goals because players always have new targets to discover. Whether searching for uncommon characters or improving an existing collection, players always have something to work toward. Strategic Stealing Mechanics The stealing system gives Steal Brainrot a unique competitive element. Players must decide when to attack and when to focus on protecting their own progress. A good strategy requires patience, observation, and smart timing. Successful players understand that rushing into every opportunity may create unnecessary risks. Careful planning helps increase the chance of gaining valuable Brainrot characters while avoiding major losses. Multiplayer Competition And Social Interaction Steal Brainrot becomes more exciting because of multiplayer interaction. Every player creates a different experience through personal strategies and decisions. Encounters with other players can change the direction of a game session. The social aspect also helps build a stronger community. Players can share strategies, discuss rare characters, and compete to achieve better results. This connection between players contributes to the long-lasting appeal of the game. Tips To Improve Performance In Steal Brainrot Although Steal Brainrot is easy to start, improving skills requires experience and understanding. Players who want better results should focus on smart resource management and careful decisions. Focus On Building A Strong Collection A strong collection provides more opportunities for success. Players should prioritize finding valuable Brainrot characters instead of making random decisions. Understanding which characters provide higher value can create a significant advantage. Patience is also important because rare items may require more time and effort. Consistent progress often leads to better results than quick but risky actions. Protect Important Resources Defense plays an important role in Steal Brainrot. Players should avoid exposing valuable characters unnecessarily and should always consider possible risks. Good protection strategies help maintain progress and reduce losses caused by other competitors. Balancing offense and defense creates a more effective gameplay approach. Learn From Other Players Observing experienced players can help improve skills faster. Many advanced strategies come from understanding how other users manage collections and handle competition. Learning from different play styles allows players to develop personal strategies that match their goals. The more players understand the game mechanics, the better decisions they can make. The Future Of Steal Brainrot Steal Brainrot has strong potential to continue growing because of its creative gameplay and active player interest. Games with unique concepts often attract attention when they provide memorable experiences. Future updates could introduce new Brainrot characters, additional challenges, and improved features that increase player engagement. Expanding content can help maintain excitement and encourage more people to join the community. The combination of humor, competition, and collection makes Steal Brainrot different from many other online games. Its simple design creates accessibility, while its strategic elements provide depth for long-term players. Conclusion Steal Brainrot offers a fun and competitive gaming experience through creative characters, collecting mechanics, and exciting multiplayer interactions. The game attracts players who enjoy discovering new items, creating strategies, and competing with others. With an entertaining concept and endless opportunities for improvement, Steal Brainrot continues to capture attention from gaming communities. Whether playing casually or aiming for competitive success, players can find enjoyable moments throughout the journey.

1 hour, 27 minutes

Re: [PATCH v4 01/14] dma-buf: introduce initial file I/O infrastructure

by Christian König

On 8/5/26 12:59, Pavel Begunkov wrote: > On 8/5/26 09:27, Christian König wrote: >>> + >>> + dma_resv_lock(dmabuf->resv, NULL); >>> + ctx->dev_ops->unmap(ctx, map); >>> + dma_resv_unlock(dmabuf->resv); >>> + >>> + dma_fence_put(&fence->base); >> >> You should probably set map->fence to NULL after that. > > The map is freed two lines below, but I can add it as > a defensive measure. In that case it's ok, I've just haven't seen the kfree(map) below. > ... >>> + ret = dma_resv_reserve_fences(dmabuf->resv, 1); >>> + if (WARN_ON_ONCE(ret)) { >>> + struct dma_fence *fence = &map->fence->base; >>> + >>> + dma_fence_get(fence); >>> + percpu_ref_kill(&map->refs); >>> + dma_fence_wait(fence, false); >>> + dma_fence_put(fence); >>> + return; >>> + } >>> + >>> + dma_resv_add_fence(dmabuf->resv, &map->fence->base, >>> + DMA_RESV_USAGE_KERNEL); >> >> That sequence is clearly incorrect! >> >> The fence must be created after dma_resv_reserve_fences(), otherwise you definately have an illegal memory operation here. > > I'm not sure what you mean, can you elaborate? I only cared about > pre-allocating it to avoid allocations here. We add / signal the fence > only once, no reuse. The map is going to be killed here, and if we > create a new map, it'll have its own fence. > > I can move the dma_fence_init() call here if that makes a difference? Yeah that is a good start, but you might need a bit more. Here is a summary of the usual procedure you need to follow when implementing a dma_fence backend: 1. Allocate your operation object, in this case here it's your mapping I think. 2. Prepare your operation, including all memory allocations. 3. Call dma_resv_reserve_fences() to reserve a fence slot. 4. Allocate and init your dma_fence object. After this step no memory allocation is allowed any more until your dma_fence object signals. The only exception is optional logging or crash dumping using GFP_NOWAIT (can fail trivially!) or minimal allocations using GFP_ATOMIC if you absolutely have to. 5. dma_resv_add_fence() to publish the fence. 6. dma_resv_unlock(). Having a dma_fence is certainly nice to have, but the tricky part is that memory allocations using GFP_KERNEL (or GFP_IO, GFP_FS etc...) can cycle back and wait for your dma_fence to signal which essentially can cause a deadlock very deeply inside memory management. Since those deadlocks happen only on memory contention situations they are usually just hard to reproduce but still totally break your neck if you manage to mess this up. So that needs to be super carefully implemented. Regards, Christian.

1 hour, 36 minutes

Re: [PATCH v4 01/14] dma-buf: introduce initial file I/O infrastructure

by Christian König

On 7/28/26 23:29, Pavel Begunkov wrote: > The goal is to be able to natively use dma-buf in the read-write / IO > path. This patch adds basic building blocks serving as a glue and API > between drivers and upper layer subsystems providing the uAPI. Later > patches implement it for NVMe raw block devices and expose it to the > user space via io_uring. > > There are two main objects. struct dma_buf_io_ctx and struct > dma_buf_io_map. The ctx is used during initial registration and serves > as an interface between the upper layer user like io_uring and to the > importer subsystem / driver. The map represents the actual dma map > established for the target device[s] with dma_buf_map_attachment() and > stored in a device specific format. The context is created via a new > file operation ->init_dma_buf_io_ctx. > > The ctx-map separation exists to support map invalidation (see > dma_buf_io_invalidate_mappings()). A ctx can create > multiple maps during its lifetime, but there can only be no more than > one (active) map attached to it. Invalidation drops the active map > if present, and the next map will only be attempted to be created > once there is a new request that wants to use the dma-buf IO ctx. > > The primary task of the dma_buf_io_map object is to count requests > using it and to wait for their completion when we want to destroy the > DMA map. Invalidation is delayed by inserting a dma fence, which is > signaled when all flight requests are completed. > > [un]mapping and any work with dma addresses is delegated to the > importer driver via an ops table stored in the ctx, see struct > dma_buf_io_ops. Only the target driver / subsystem knows about devices > it wants to use the dma-buf with, especially in case of multi-device > filesystems or stacking in the future. > > Signed-off-by: Pavel Begunkov <asml.silence(a)gmail.com> > --- > drivers/dma-buf/Makefile | 2 +- > drivers/dma-buf/dma-buf-io.c | 275 +++++++++++++++++++++++++++++++++++ > include/linux/dma-buf-io.h | 91 ++++++++++++ > include/linux/fs.h | 2 + > 4 files changed, 369 insertions(+), 1 deletion(-) > create mode 100644 drivers/dma-buf/dma-buf-io.c > create mode 100644 include/linux/dma-buf-io.h > > diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile > index b25d7550bacf..523731b0f83e 100644 > --- a/drivers/dma-buf/Makefile > +++ b/drivers/dma-buf/Makefile > @@ -1,6 +1,6 @@ > # SPDX-License-Identifier: GPL-2.0-only > obj-y := dma-buf.o dma-fence.o dma-fence-array.o dma-fence-chain.o \ > - dma-fence-unwrap.o dma-resv.o dma-buf-mapping.o > + dma-fence-unwrap.o dma-resv.o dma-buf-mapping.o dma-buf-io.o > obj-$(CONFIG_DMABUF_HEAPS) += dma-heap.o > obj-$(CONFIG_DMABUF_HEAPS) += heaps/ > obj-$(CONFIG_SYNC_FILE) += sync_file.o > diff --git a/drivers/dma-buf/dma-buf-io.c b/drivers/dma-buf/dma-buf-io.c > new file mode 100644 > index 000000000000..5f545a1bcf32 > --- /dev/null > +++ b/drivers/dma-buf/dma-buf-io.c > @@ -0,0 +1,275 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Common infrastructure for supporing dma-buf in the I/O path. > + * > + * Copyright (C) 2026 Pavel Begunkov <asml.silence(a)gmail.com> > + */ > +#include <linux/dma-buf-io.h> > +#include <linux/dma-resv.h> > + > +struct dma_buf_io_fence { > + struct dma_fence base; > + spinlock_t lock; > +}; Upstream has change to allow embedding the spinlock into the dma_fence, so this structure here is most likely not necessary any more. > + > +static const char *dma_buf_io_fence_drv_name(struct dma_fence *fence) > +{ > + /* default fence release kfree's the base pointer */ > + BUILD_BUG_ON(offsetof(struct dma_buf_io_fence, base)); > + > + return "dma-buf-io-ctx"; > +} > + > +static const char *dma_buf_io_fence_timeline_name(struct dma_fence *fence) > +{ > + return "dma-buf-io-ctx"; > +} > + > +const struct dma_fence_ops dma_buf_io_fence_ops = { > + .get_driver_name = dma_buf_io_fence_drv_name, > + .get_timeline_name = dma_buf_io_fence_timeline_name, > +}; > + > +static void dma_buf_io_ctx_destroy_work(struct work_struct *work) > +{ > + struct dma_buf_io_ctx *ctx = container_of(work, struct dma_buf_io_ctx, > + release_work); > + > + if (WARN_ON_ONCE(refcount_read(&ctx->refs))) > + return; > + > + ctx->dev_ops->release(ctx); > + dma_buf_put(ctx->dmabuf); > + kfree(ctx); > +} > + > +static void dma_buf_io_map_release_work(struct work_struct *work) > +{ > + struct dma_buf_io_map *map = container_of(work, struct dma_buf_io_map, > + release_work); > + struct dma_buf_io_fence *fence = map->fence; > + struct dma_buf_io_ctx *ctx = map->ctx; > + struct dma_buf *dmabuf = ctx->dmabuf; > + > + /* the release path must wait for fences */ > + if (WARN_ON_ONCE(refcount_read(&ctx->refs) == 0)) > + return; Stuff like that is usually illegal. And why are you using refcount directly instead of kref? > + > + /* Prevent from destoying the ctx while unmapping */ > + refcount_inc(&ctx->refs); > + > + /* > + * There are no more requests using the map, we can signal the fence. > + * It should be done before taking the resv lock as someone could be > + * waiting for the fence while holding the lock. > + */ > + dma_fence_signal(&fence->base); Signaling fences has a whole bunch of very strict rules associated with it. E.g. you can't alocate memory for example. Are you sure you actually need and want a dma_fence here? > + > + dma_resv_lock(dmabuf->resv, NULL); > + ctx->dev_ops->unmap(ctx, map); > + dma_resv_unlock(dmabuf->resv); > + > + dma_fence_put(&fence->base); You should probably set map->fence to NULL after that. > + percpu_ref_exit(&map->refs); > + kfree(map); > + > + if (refcount_dec_and_test(&ctx->refs)) { > + /* > + * Destruction needs to wait for I/O and dma fences. Defer it to > + * simplify locking. > + */ > + INIT_WORK(&ctx->release_work, dma_buf_io_ctx_destroy_work); > + queue_work(system_wq, &ctx->release_work); > + } > +} > + > +static void dma_buf_io_map_refs_release(struct percpu_ref *ref) > +{ > + struct dma_buf_io_map *map = container_of(ref, struct dma_buf_io_map, refs); > + > + /* might sleep, use a worker */ > + INIT_WORK(&map->release_work, dma_buf_io_map_release_work); > + queue_work(system_wq, &map->release_work); > +} > + > +int dma_buf_io_init_map(struct dma_buf_io_ctx *ctx, struct dma_buf_io_map *map) > +{ > + struct dma_buf_io_fence *fence = NULL; > + int ret; > + > + fence = kzalloc(sizeof(*fence), GFP_KERNEL); > + if (!fence) > + return -ENOMEM; > + > + ret = percpu_ref_init(&map->refs, dma_buf_io_map_refs_release, 0, GFP_KERNEL); > + if (ret) { > + kfree(fence); > + return ret; > + } > + > + spin_lock_init(&fence->lock); > + dma_fence_init(&fence->base, &dma_buf_io_fence_ops, &fence->lock, > + ctx->fence_ctx, atomic_inc_return(&ctx->fence_seq)); > + map->fence = fence; > + map->ctx = ctx; > + return 0; > +} > +EXPORT_SYMBOL_NS_GPL(dma_buf_io_init_map, "DMA_BUF"); > + > +struct dma_buf_io_map *dma_buf_io_create_map(struct dma_buf_io_ctx *ctx) > +{ > + struct dma_buf *dmabuf = ctx->dmabuf; > + struct dma_buf_io_map *map; > + long ret; > + > +retry: > + /* > + * ->dmabuf_map() will be calling dma_buf_map_attachment(), for which > + * we'll need to wait for fences. Do a bit nicer and try to wait > + * without the resv lock first. > + */ Clear NAK to that. Always wait while holding the resv lock if you can! It is absolutely not beneficial to do this outside of the lock and usually just hides problems instead and prevent fixing them. > + ret = dma_resv_wait_timeout(dmabuf->resv, DMA_RESV_USAGE_KERNEL, > + true, MAX_SCHEDULE_TIMEOUT); > + if (!ret) > + ret = -EAGAIN; > + if (ret < 0) > + return ERR_PTR(ret); > + > + ret = dma_resv_lock_interruptible(dmabuf->resv, NULL); > + if (ret) > + return ERR_PTR(ret); > + > + map = dma_buf_io_get_map(ctx); > + if (map) { > + ret = 0; > + goto out; > + } > + > + if (dma_resv_wait_timeout(dmabuf->resv, DMA_RESV_USAGE_KERNEL, > + true, 0) < 0) { > + dma_resv_unlock(dmabuf->resv); > + goto retry; > + } > + > + map = ctx->dev_ops->map(ctx); > + if (IS_ERR(map)) { > + ret = PTR_ERR(map); > + goto out; > + } > + > + percpu_ref_get(&map->refs); > + rcu_assign_pointer(ctx->map, map); > +out: > + dma_resv_unlock(dmabuf->resv); > + if (ret < 0) > + return ERR_PTR(ret); > + return map; > +} > + > +static void dma_buf_io_drop_map(struct dma_buf_io_ctx *ctx) > +{ > + struct dma_buf *dmabuf = ctx->dmabuf; > + struct dma_buf_io_map *map; > + int ret; > + > + dma_resv_assert_held(dmabuf->resv); > + > + map = rcu_dereference_protected(ctx->map, > + dma_resv_held(dmabuf->resv)); > + if (!map) > + return; > + rcu_assign_pointer(ctx->map, NULL); > + > + ret = dma_resv_reserve_fences(dmabuf->resv, 1); > + if (WARN_ON_ONCE(ret)) { > + struct dma_fence *fence = &map->fence->base; > + > + dma_fence_get(fence); > + percpu_ref_kill(&map->refs); > + dma_fence_wait(fence, false); > + dma_fence_put(fence); > + return; > + } > + > + dma_resv_add_fence(dmabuf->resv, &map->fence->base, > + DMA_RESV_USAGE_KERNEL); That sequence is clearly incorrect! The fence must be created after dma_resv_reserve_fences(), otherwise you definately have an illegal memory operation here. Regards, Christian. > + /* > + * Delay destruction until all inflight requests using the map arefence-> > + * gone. It'll also signal the fence then. > + */ > + percpu_ref_kill(&map->refs); > +} > + > +void dma_buf_io_invalidate_mappings(struct dma_buf_io_ctx *ctx) > +{ > + dma_buf_io_drop_map(ctx); > +} > +EXPORT_SYMBOL_NS_GPL(dma_buf_io_invalidate_mappings, "DMA_BUF"); > + > +static void dma_buf_io_ctx_release_work(struct work_struct *work) > +{ > + struct dma_buf_io_ctx *ctx = container_of(work, struct dma_buf_io_ctx, > + release_work); > + struct dma_buf *dmabuf = ctx->dmabuf; > + long ret; > + > + dma_resv_lock(dmabuf->resv, NULL); > + /* Remove the last map, there should be no new ones going forward. */ > + dma_buf_io_drop_map(ctx); > + dma_resv_unlock(dmabuf->resv); > + > + /* Wait until all maps are destroyed. */ > + ret = dma_resv_wait_timeout(dmabuf->resv, DMA_RESV_USAGE_KERNEL, > + false, MAX_SCHEDULE_TIMEOUT); > + > + if (WARN_ON_ONCE(ret <= 0)) > + return; > + if (WARN_ON_ONCE(rcu_dereference_protected(ctx->map, true))) > + return; > + > + if (refcount_dec_and_test(&ctx->refs)) > + dma_buf_io_ctx_destroy_work(&ctx->release_work); > +} > + > +void dma_buf_io_ctx_release(struct dma_buf_io_ctx *ctx) > +{ > + /* > + * Destruction needs to wait for I/O and dma fences. Defer it to > + * simplify locking. > + */ > + INIT_WORK(&ctx->release_work, dma_buf_io_ctx_release_work); > + queue_work(system_wq, &ctx->release_work); > +} > + > +int dma_buf_io_ctx_create(struct file *file, > + struct dma_buf_io_ctx *ctx, > + struct dma_buf *dmabuf, > + enum dma_data_direction dir) > +{ > + int ret; > + > + if (!file->f_op->init_dma_buf_io_ctx) > + return -EOPNOTSUPP; > + > + memset(ctx, 0, sizeof(*ctx)); > + ctx->fence_ctx = dma_fence_context_alloc(1); > + ctx->dir = dir; > + ctx->dmabuf = dmabuf; > + refcount_set(&ctx->refs, 1); > + get_dma_buf(dmabuf); > + > + ret = file->f_op->init_dma_buf_io_ctx(file, ctx); > + if (ret) { > + memset(ctx, 0, sizeof(*ctx)); > + dma_buf_put(dmabuf); > + return ret; > + } > + > + if (WARN_ON_ONCE(!ctx->dev_ops || > + !ctx->dev_ops->map || > + !ctx->dev_ops->unmap || > + !ctx->dev_ops->release)) > + return -EINVAL; > + > + return ret; > +} > diff --git a/include/linux/dma-buf-io.h b/include/linux/dma-buf-io.h > new file mode 100644 > index 000000000000..bcffc6202556 > --- /dev/null > +++ b/include/linux/dma-buf-io.h > @@ -0,0 +1,91 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +#ifndef __DMA_BUF_IO_H__ > +#define __DMA_BUF_IO_H__ > + > +#include <linux/dma-buf.h> > + > +struct dma_buf_io_fence; > +struct dma_buf_io_ctx; > +struct dma_buf_io_map; > + > +struct dma_buf_io_ops { > + /* > + * Create a new map for the given ctx. Called with the reservation > + * lock held. > + */ > + struct dma_buf_io_map *(*map)(struct dma_buf_io_ctx *ctx); > + > + /* > + * Clean up device specific parts of the @map. Called with the > + * reservation lock held. > + */ > + void (*unmap)(struct dma_buf_io_ctx *ctx, struct dma_buf_io_map *map); > + > + /* > + * The user tries to destroy the ctx. Release all device specific > + * parts of the token. > + */ > + void (*release)(struct dma_buf_io_ctx *); > +}; > + > +struct dma_buf_io_map { > + /* > + * Counts attached requests and other users. Device specific unmapping > + * is deferred until all refs are dropped. > + */ > + struct percpu_ref refs; > + > + struct work_struct release_work; > + struct dma_buf_io_fence *fence; > + struct dma_buf_io_ctx *ctx; > +}; > + > +struct dma_buf_io_ctx { > + struct dma_buf_io_map __rcu *map; > + struct dma_buf *dmabuf; > + enum dma_data_direction dir; > + > + atomic_t fence_seq; > + u64 fence_ctx; > + struct work_struct release_work; > + refcount_t refs; > + > + void *dev_priv; > + const struct dma_buf_io_ops *dev_ops; > +}; > + > +int dma_buf_io_ctx_create(struct file *file, > + struct dma_buf_io_ctx *ctx, > + struct dma_buf *dmabuf, > + enum dma_data_direction dir); > +void dma_buf_io_ctx_release(struct dma_buf_io_ctx *ctx); > + > +struct dma_buf_io_map *dma_buf_io_create_map(struct dma_buf_io_ctx *ctx); > + > +static inline struct dma_buf_io_map * > +dma_buf_io_get_map(struct dma_buf_io_ctx *ctx) > +{ > + struct dma_buf_io_map *map; > + > + guard(rcu)(); > + > + map = rcu_dereference(ctx->map); > + if (unlikely(!map || !percpu_ref_tryget_live_rcu(&map->refs))) > + return NULL; > + > + return map; > +} > + > +static inline void dma_buf_io_map_drop(struct dma_buf_io_map *map) > +{ > + percpu_ref_put(&map->refs); > +} > + > +/* > + * Device API > + */ > + > +void dma_buf_io_invalidate_mappings(struct dma_buf_io_ctx *ctx); > +int dma_buf_io_init_map(struct dma_buf_io_ctx *ctx, struct dma_buf_io_map *map); > + > +#endif > diff --git a/include/linux/fs.h b/include/linux/fs.h > index d10897b3a1e3..9fe349a279c7 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -1914,6 +1914,7 @@ struct dir_context { > #define COPY_FILE_SPLICE (1 << 0) > > struct io_uring_cmd; > +struct dma_buf_io_ctx; > struct offset_ctx; > > typedef unsigned int __bitwise fop_flags_t; > @@ -1962,6 +1963,7 @@ struct file_operations { > int (*uring_cmd_iopoll)(struct io_uring_cmd *, struct io_comp_batch *, > unsigned int poll_flags); > int (*mmap_prepare)(struct vm_area_desc *); > + int (*init_dma_buf_io_ctx)(struct file *, struct dma_buf_io_ctx *); > } __randomize_layout; > > /* Supports async buffered reads */

7 hours, 28 minutes

Re: [PATCH v9 3/5] rust: sync: Add abstraction for rcu_barrier()

by Gary Guo

On Wed Aug 5, 2026 at 3:59 PM BST, Philipp Stanner wrote: > rcu_barrier() is a frequently used C function which is always safe to be > called. > > Add a safe abstraction for rcu_barrier(). > > Signed-off-by: Philipp Stanner <phasta(a)kernel.org> > Tested-by: Daniel Almeida <daniel.almeida(a)collabora.com> Acked-by: Gary Guo <gary(a)garyguo.net> > --- > rust/kernel/sync/rcu.rs | 20 ++++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git a/rust/kernel/sync/rcu.rs b/rust/kernel/sync/rcu.rs > index a32bef6e490b..7031ca5d2473 100644 > --- a/rust/kernel/sync/rcu.rs > +++ b/rust/kernel/sync/rcu.rs > @@ -50,3 +50,23 @@ fn drop(&mut self) { > pub fn read_lock() -> Guard { > Guard::new() > } > + > +/// Wait until all in-flight call_rcu() callbacks complete. This misses some `` quoting but these can be applied on fixup. Best, Gary > +/// > +/// Note that this primitive does not necessarily wait for an RCU grace period > +/// to complete. For example, if there are no RCU callbacks queued anywhere > +/// in the system, then rcu_barrier() is within its rights to return > +/// immediately, without waiting for anything, much less an RCU grace period. > +/// In fact, rcu_barrier() will normally not result in any RCU grace periods > +/// beyond those that were already destined to be executed. > +/// > +/// In kernels built with CONFIG_RCU_LAZY=y, this function also hurries all > +/// pending lazy RCU callbacks. > +/// > +/// Note that this is one of the RCU primitives which must not be called in > +/// atomic context. > +#[inline] > +pub fn rcu_barrier() { > + // SAFETY: `rcu_barrier()` is always safe to be called. It just might wait for a grace period. > + unsafe { bindings::rcu_barrier() }; > +}

13 hours, 58 minutes

Re: [PATCH v9 2/5] rust: types: implement ForeignOwnable for ARef<T>

by Gary Guo

On Wed Aug 5, 2026 at 3:59 PM BST, Philipp Stanner wrote: > From: Danilo Krummrich <dakr(a)kernel.org> > > Implement ForeignOwnable for ARef<T>, making it possible for C code to > own an ARef<T>. > > Since ARef represents shared ownership, BorrowedMut is &T rather than > &mut T, matching the semantics of the underlying reference-counted type. > > Signed-off-by: Danilo Krummrich <dakr(a)kernel.org> > Reviewed-by: Alice Ryhl <aliceryhl(a)google.com> > Tested-by: Daniel Almeida <daniel.almeida(a)collabora.com> > --- > rust/kernel/sync/aref.rs | 40 ++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 40 insertions(+) > > diff --git a/rust/kernel/sync/aref.rs b/rust/kernel/sync/aref.rs > index b721b2e00b98..540766613659 100644 > --- a/rust/kernel/sync/aref.rs > +++ b/rust/kernel/sync/aref.rs > @@ -24,6 +24,11 @@ > ptr::NonNull, // > }; > > +use crate::{ > + prelude::*, > + types::ForeignOwnable, // > +}; > + > /// Types that are _always_ reference counted. > /// > /// It allows such types to define their own custom ref increment and decrement functions. > @@ -188,6 +193,41 @@ fn eq(&self, other: &ARef<U>) -> bool { > } > impl<T: AlwaysRefCounted + Eq> Eq for ARef<T> {} > > +// SAFETY: `into_foreign` returns a pointer from `NonNull::as_ptr`, so it's non-null. The > +// `ARef` invariant guarantees that `ptr` points to a valid `T`, so it's aligned to `T`. > +unsafe impl<T: AlwaysRefCounted + 'static> ForeignOwnable for ARef<T> { This doesn't need to be static, if you can add `where Self: 'a` on `Borrowed` and `BorrowedMut` instead. Best, Gary > + const FOREIGN_ALIGN: usize = core::mem::align_of::<T>(); > + > + type Borrowed<'a> = &'a T; > + type BorrowedMut<'a> = &'a T; > + > + fn into_foreign(self) -> *mut c_void { > + ARef::into_raw(self).as_ptr().cast() > + } > + > + unsafe fn from_foreign(ptr: *mut c_void) -> Self { > + // SAFETY: The safety requirements of this function ensure that `ptr` comes from a previous > + // call to `Self::into_foreign`. > + let ptr = unsafe { NonNull::new_unchecked(ptr.cast()) }; > + > + // SAFETY: `ptr` came from `into_foreign`, which consumed an `ARef` without decrementing > + // the refcount, so we can transfer the ownership to the new `ARef`. > + unsafe { ARef::from_raw(ptr) } > + } > + > + unsafe fn borrow<'a>(ptr: *mut c_void) -> &'a T { > + // SAFETY: The safety requirements of this method ensure that the object remains alive and > + // immutable for the duration of 'a. > + unsafe { &*ptr.cast() } > + } > + > + unsafe fn borrow_mut<'a>(ptr: *mut c_void) -> &'a T { > + // SAFETY: The safety requirements for `borrow_mut` are a superset of the safety > + // requirements for `borrow`. > + unsafe { <Self as ForeignOwnable>::borrow(ptr) } > + } > +} > + > impl<T, U> PartialEq<&'_ U> for ARef<T> > where > T: AlwaysRefCounted + PartialEq<U>,

14 hours, 43 minutes

Re: [RFC PATCH 10/30] vfio/pci: Export vfio dma-buf specific info for importers

by Jason Gunthorpe

On Mon, Jul 27, 2026 at 11:53:55AM -0700, Ackerley Tng wrote: > Hope you also had a chance to look at [1] that David Woodhouse is > working on :) > > [1] https://lore.kernel.org/all/1dc299af6b795a40c8887b3d84f915024f6446a9.camel@… Heh, that's awfully DMABUF like :) So, if that happens then sure we can probably create a VFIO exporter for it as well along side the DMABUF exporter Matt is working on and that should handle the shared/private steps intel needs Jason

16 hours, 10 minutes

Re: [PATCH v5 2/9] PCI/P2PDMA: Add CONFIG_PCI_P2PDMA_CORE

by Jason Gunthorpe

On Tue, Aug 04, 2026 at 10:19:11AM -0600, Logan Gunthorpe wrote: > There's a vague convention for this already: the term 'p2pmem' is often > used for cases where the driver uses the allocator, etc. (I think I had > this intention when I wrote the code and have since forgotten about > it). I've been calling it the genalloc layer and the core layer. p2pmem would be OK to refer to the genalloc stuff. So if you want to have CONFIG_PCI_P2PDMA and CONFIG_PCI_P2PMEM that seem sOk > code into it's own file, potentially renaming some functions. Then, in > the end, we would probably have a pcim_p2pdma_supported() function and a > pcim_p2pmem_supported() function, the latter being used by existing use > cases. Not quite sure why we need this? Matt, the mlx5 stuff is the same as VFIO, it just uses the "core" layer and does not use the genalloc. So there shouldn't be an issue here, if the genalloc is off then the mlx5 stuff should still work. There shouldn't be a case where CONFIG_PCI_P2PDMA=y and mlx5 is broken? Did some of APIs get mixed into the genalloc family that should not have? Jason

16 hours, 25 minutes

[PATCH v5 0/9] vfio/pci: Add mmap() for DMABUFs

by Matt Evans

Hi all, The goal of this series is to enable userspace driver designs that use VFIO to export DMABUFs representing subsets of PCI device BARs, and "vend" those buffers from a primary process to other subordinate processes by fd. These processes then mmap() the buffers and their access to the device is isolated to the exported ranges. This is an improvement on sharing the VFIO device fd to subordinate processes, which would allow unfettered access. This is achieved by enabling mmap() of vfio-pci DMABUFs, passed by fd to subordinate processes. Second, a new revocation mechanism is added to allow the primary process to forcibly revoke access to previously-shared BAR spans, even if the subordinate processes haven't cleanly exited. (The related topic of safe delegation of iommufd control to the subordinate processes is not addressed here, and is follow-up work.) The background/rationale is covered in more detail in the RFC cover letters. Feedback from the RFCs requested that, instead of creating DMABUF-specific vm_ops and .fault paths, to go the whole way and migrate the existing VFIO PCI BAR mmap() to be backed by a DMABUF too, resulting in a common vm_ops and fault handler for mmap()s of both the VFIO device and explicitly-exported DMABUFs. This will help future iommufd emulation of VFIO Type1 peer-to-peer, making it easier to get a DMABUF for a VFIO BAR as a DMA target. mmap() conversion to use DMABUF underneath has been done for vfio-pci, but not sub-drivers: nvgrace-gpu's mmap() override path is unchanged; I kept this out of scope for now not least because I don't have a thorough test setup for this system. I would prefer to help the nvgrace-gpu maintainers enable BAR mmap() DMABUFs themselves. Notes on patches ================ PCI/P2PDMA: Split pool-related cleanup out of pci_p2pdma_release() PCI/P2PDMA: Add CONFIG_PCI_P2PDMA_CORE Later in the series, vfio-pci's mmap() is going to depend on pcim_p2pdma_provider() which depended on CONFIG_PCI_P2PDMA, which in turn depended on ZONE_DEVICE. That isn't available on 32-bit and some archs, because they lack MEMORY_HOTPLUG and friends. VFIO does _not_ require actual P2P to be present for basic mmap() functionality, only for the optional CONFIG_DMA_SHARED_BUFFER feature. These split out p2pdma_core.c under CONFIG_PCI_P2PDMA_CORE (which currently contains pcim_p2pdma_provider()), and an optional CONFIG_PCI_P2PDMA which depends on ZONE_DEVICE etc. providing P2P functionality in the existing p2pdma.c. The first splits out pool cleanup from the release path, and the second does the refactor/code move to the new file. vfio/pci: Add a helper to look up PFNs for DMABUFs vfio/pci: Add a helper to create a DMABUF for a BAR-map VMA The first adds a DMABUF VMA fault handler helper to determine arbitrary-sized PFNs from ranges in DMABUF. The second refactors DMABUF export for use by the existing export feature, and adds a helper that creates a DMABUF corresponding to a VFIO BAR mmap() request. vfio/pci: Convert BAR mmap() to use a DMABUF The vfio-pci core mmap() creates a DMABUF with the helper above, and the vm_ops fault handler uses the other helper to resolve the fault. Because this depends on DMABUF structs/code, CONFIG_VFIO_PCI_CORE needs to depend on CONFIG_DMA_SHARED_BUFFER. The CONFIG_VFIO_PCI_DMABUF still conditionally enables the export support code. NOTE: The user mmap()s a device fd, but the resulting VMA's vm_file becomes that of the DMABUF. The DMABUF takes ownership of the device file and put()s it on release, which maintains the existing behaviour of a VMA keeping the VFIO device open. BAR zapping then happens via the existing vfio_pci_dma_buf_move() path, which now needs to unmap PTEs in the DMABUF's address_space. vfio/pci: Provide a user-facing name for BAR mappings There was a request for decent debug naming in /proc/<pid>/maps etc. comparable to the existing VFIO names: since the VMAs are DMABUFs, they have a "dmabuf:" prefix and can't be 100% identical to before. This is a user-visible change, but this patch at least now gives us extra info on the BDF & BAR being mapped. vfio/pci: Clean up BAR zap and revocation In general (see NOTE!) the vfio_pci_zap_bars() is now obsolete, since it unmaps PTEs in the VFIO device address_space which is now unused. This consolidates all calls (e.g. around reset) with the neighbouring vfio_pci_dma_buf_move()s into new functions, to revoke/unrevoke (making the steps clearer). NOTE: Because drivers can use their own vm_ops and override .mmap, the core must conservatively assume an overridden .mmap might still add PTEs to the VFIO device address_space and therefore still does the zap. A new flag, zap_bars_on_revoke, enables the zap when .mmap is overridden. A driver that does not need the zap can clear this to opt-out, e.g. if the driver calls down to the common mmap (and so uses DMABUFs). hisi-acc-vfio-pci does just this, and thus sets the opt-out flag. vfio/pci: Support mmap() of a VFIO DMABUF Adds mmap() for a DMABUF fd exported from vfio-pci. It was a goal to keep the VFIO device fd lifetime behaviour unchanged with respect to the DMABUFs. An application can close all device fds, and this will revoke/clean up all DMABUFs; then, no mappings or other access can be performed. When enabling mmap() of the DMABUFs, this means access through the VMA is also revoked. This complicates the fault handler because whilst the DMABUF exists, it has no guarantee that the corresponding VFIO device is still alive. Adds synchronisation ensuring the vdev is available before vdev->memory_lock is touched; this holds the device registration so that even if the buffer has been cleaned up, vdev hasn't been freed and so the lock can be safely taken. vfio/pci: Permanently revoke a DMABUF on request This is mostly a rename of `revoked` to an enum, `status`, and adding a third state for a buffer: usable, revoked temporary, revoked permanent. A new VFIO feature is added, VFIO_DEVICE_FEATURE_DMA_BUF_REVOKE, which takes a DMABUF (exported from the same device) and permanently revokes it. Thus a userspace driver can guarantee any downstream consumers of a shared fd are prevented from accessing a BAR range, and that range can be reused. NOTE: This might block userspace, waiting on importers to detach. The code doing revocation in vfio_pci_dma_buf_move() is moved, to a common function for use by ..._move() and this new feature. NOTE: See changelog, by request v4 added a condition to the existing code to elide the unnecessary invalidation/sync on the un-revoke path.) NOTE: Previous versions contained an additional feature patch, "vfio/pci: Add mmap() attributes to DMABUF feature". This has been dropped in v5 because: - The mechanism simply set vma->vm_page_prot. This would be sufficient for arm64 and other architectures. - However, (locally-run claude-opus-4-8) Sashiko flagged that, on x86, additional memtype handling is required to set up the PAT. Without this, the memtype is returned back to UC- by pfnmap_setup_cachemode() upon PTE creation. Most other sources of userspace WC mappings create PTEs eagerly with e.g. io_remap_pfn_range() which memtype_reserve() WC for the range. Getting them with lazy-fault used by vfio-pci is more complicated (e.g. perhaps registering WC for BARs with PAT/MTRRs, and deciding how to deal with aliasing...). Since this feature is not critical for this series to be useful, I've decided for now to drop it in favour of a simpler series now and revisiting this separ*ately. Testing ======= (The [RFC ONLY] userspace test program, for QEMU edu-plus, can be found in the GitHub branch below. It at least illustrates how the export, map, revoke, and close semantics interoperate.) This code has been tested in mapping DMABUFs of single/multiple ranges from multiple BARs, aliasing mmap()s, aliasing ranges across DMABUFs, vm_pgoff > 0, revocation, shutdown/cleanup scenarios, and hugepage mappings. No regressions observed on the VFIO selftests, or on our internal vfio-pci applications. VFIO on i386 has been build-tested. Dear Reviewers, =============== I was grateful for the reviews and Reviewed-Bys on previous versions. Thanks; I've added some Reviewed-Bys/Acks. I have NOT included your tags where the patch has materially changed after your review (or where requested changes ended up more than super-trivial). I hope that's okay. End === This is based on v7.2-rc3. These commits are on GitHub for easier browsing, along with "[RFC ONLY] selftests: vfio: Add standalone vfio_dmabuf_mmap_test": https://github.com/metamev/linux/compare/v7.2-rc3...dev/mev/vfio-dmabuf-mma… Thanks for reading, Matt ================================================================================ Changelog: v5: - Rebased on 7.2-rc3 - Dropped the memattr/WC feature (see explanation above). - "vfio/pci: Convert BAR mmap() to use a DMABUF": Fixed a potentially-nasty bug (which (locally-run) Sashiko found!) whereby the unmap_mapping_range() performed in cleanup was passed a range up from offset zero for the DMABUF size. Initially this was how all DMABUFs were created and an appropriate zap, but a new version kept the VFIO region index encoded in the offset -- for BAR > 0 the unmap span would then mismatch. Instead, pass size 0 to mean an "all" range. Because the goal is to shoot down everything relating to one DMABUF and the address_space can only contain things relating to that DMABUF, this is equivalent and has the bonus of never failing to match mappings... Praan, Kevin, I kept your R-Bs on this fix. - The revoke patch converts vfio_pci_dma_buf_cleanup()'s priv->vdev = NULL to a WRITE_ONCE, corresponding to the revoke function's READ_ONCE (performed to test that the VFIO and DMABUF are related). - Clarified the VFIO_DEVICE_FEATURE_DMA_BUF_REVOKE UAPI comments, documenting previously-missing error cases and their reasons. v4: https://lore.kernel.org/all/20260701171245.90111-1-matt@ozlabs.org/ v3: https://lore.kernel.org/all/20260610154327.37758-1-matt@ozlabs.org/ v2: https://lore.kernel.org/all/20260527102319.100128-1-mattev@meta.com/ v1: https://lore.kernel.org/kvm/20260416131815.2729131-1-mattev@meta.com/ RFCv2: https://lore.kernel.org/kvm/20260312184613.3710705-1-mattev@meta.com/ RFCv1: https://lore.kernel.org/all/20260226202211.929005-1-mattev@meta.com/ Tech topic: https://lore.kernel.org/linux-iommu/20250918214425.2677057-1-amastro@fb.com/ Matt Evans (9): PCI/P2PDMA: Split pool-related cleanup out of pci_p2pdma_release() PCI/P2PDMA: Add CONFIG_PCI_P2PDMA_CORE vfio/pci: Add a helper to look up PFNs for DMABUFs vfio/pci: Add a helper to create a DMABUF for a BAR-map VMA vfio/pci: Convert BAR mmap() to use a DMABUF vfio/pci: Provide a user-facing name for BAR mappings vfio/pci: Clean up BAR zap and revocation vfio/pci: Support mmap() of a VFIO DMABUF vfio/pci: Permanently revoke a DMABUF on request MAINTAINERS | 2 +- drivers/pci/Kconfig | 5 + drivers/pci/Makefile | 1 + drivers/pci/p2pdma.c | 113 +--- drivers/pci/p2pdma.h | 29 + drivers/pci/p2pdma_core.c | 122 +++++ drivers/vfio/pci/Kconfig | 5 +- drivers/vfio/pci/Makefile | 3 +- .../vfio/pci/hisilicon/hisi_acc_vfio_pci.c | 8 + drivers/vfio/pci/vfio_pci_config.c | 30 +- drivers/vfio/pci/vfio_pci_core.c | 210 +++++-- drivers/vfio/pci/vfio_pci_dmabuf.c | 515 +++++++++++++++--- drivers/vfio/pci/vfio_pci_priv.h | 53 +- include/linux/pci-p2pdma.h | 24 +- include/linux/pci.h | 2 +- include/linux/vfio_pci_core.h | 1 + include/uapi/linux/vfio.h | 25 + 17 files changed, 875 insertions(+), 273 deletions(-) create mode 100644 drivers/pci/p2pdma.h create mode 100644 drivers/pci/p2pdma_core.c -- 2.50.1 (Apple Git-155)

19 hours, 7 minutes

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig