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.
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.
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.
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.
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() };
> +}
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>,
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
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
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)