Hi David,
On 16/07/2026 22:23, David Matlack wrote:
> On 2026-07-16 03:51 PM, Matt Evans wrote:
>> Hi David,
>>
>> On 15/07/2026 19:12, David Matlack wrote:
>>> On Wed, Jul 15, 2026 at 10:47 AM Matt Evans <matt(a)ozlabs.org> wrote:
>>>
>>>> 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…
>>>
>>> It'd be great to have this test upstream. I'm happy to review it when
>>> you're ready. Looks like it just needs to be redone to use the VFIO
>>> selftests library and kselftests harness. AI could probably do the
>>> conversion pretty quick :)
>>
>> For sure, I'd intended to catch up with you on best approach here. :)
>>
>> Aside from the organic structure of the test (the open-coded VFIO
>> device/group setup/init needs to go), the main issue is that it relies
>> on a hacked/out of tree QEMU "EDU++" device with a second larger BAR
>> (containing freely read-writable memory). A subset of tests run with
>> the in-tree EDU device, but coverage is too low.
>>
>> The desirable properties are:
>>
>> - Having a BAR that is pure memory (all locations present, writable
>> without disruptive side-effects) so that mapping aliases can be
>> constructed and detected. This is good to test things like non-zero
>> vm_pgoffs and VA space presentation of physically-discontiguous DMABUFs.
>>
>> - BAR >> hugepage size so we can eyeball huge mappings work (or better,
>> mechanically test for them). At least 32MB would tick this box for 4K,
>> 16K page systems.
>>
>> - Something QEMU supports*, so one can run the test in a VM/TCG system.
>>
>> There were some real device models in QEMU that could be used this way,
>> but needed a fair bit of setup; I didn't want to rathole
>> vfio_dmabuf_mmap_test on including a ton of device-specific code for
>> some video card or similar.
>>
>> I'll dig more for a simple target that provides these properties --
>> obviously it would be better to point this test at an off-the-shelf
>> device (including silicon!). And, proposing EDU extensions to the QEMU
>> folks may be useful (there're uses for a better EDU in other contexts too).
>>
>> Since this test uses MMIO for a specific [class of] function, my first
>> thought is it should be another VFIO driver-type test sibling of
>> vfio_pci_driver_test. For example, we could extend the driver-type
>> tests' backend struct vfio_pci_driver_ops for functions capable of
>> providing a Big Memory BAR, like QEMU EDU++. EDU can also memcpy, so
>> could also support vfio_pci_driver_test.
>>
>> The spirit of the device backends hiding setup of a complex device is
>> handy, and it's plausible that several backends could provide this "big
>> memory BAR" service. What do you think, any concerns with extending
>> vfio_pci_driver_ops like that?
>
> I wouldn't recommend leveraging the driver framework unless absolutely
> necessary. It makes the test harder to run.
>
> The biggest issue I see with the proposed properties is being able to
> treat the BAR as memory. That obviously will depend on the device and
> may require device-specific setup. If we decide that treating the BAR as
> memory is truly required then using the driver framework is the way to
> go. But I'm hoping we can avoid that requirement.
>
> Instead, I think you can get pretty far by inspecting /proc/pid/pagemap
> to determine if the mmap() set things up correctly, without actually
> accessing the BAR. You can use /proc/pid/pagemap to look up the PFN and
> PAGEMAP_SCAN to detect huge pages.
Hmm, possible, although that's quite a different test at that point. I
agree never touching the device has advantages, but it's harder to test
certain things if we _never_ do MMIO. The mitigation effort to get
coverage may not be the right tradeoff vs easier running. I can think
of some "easy" VFIO bugs that would be challenging to properly verify in
userspace (e.g. PFNs all having some undesired offset). The current
test method is harder to fool per unit effort in writing it.
Though, I will have a think about this no-touch flavour of test.
What were you picturing regarding populating the VMA PTEs in order to
inspect the result via /proc/pid/pagemap, whilst still upholding the
principle of not touching the device? For example,
madvise(MADV_POPULATE_WRITE) won't work on the VFIO BAR regions because
they're VM_PFNMAP/VM_IO.
> With that requirement gone, then all you really need is a device with a
> large enough BAR. And even that it not a hard requirement. I'm sure
> there are plenty of test cases that could work with smaller BARs. The
> few tests that want to exercise huge mappings can inspect the device BAR
> sizes first, and if they're all too small, SKIP() the test.
>
> If you structure the test this way, then it's easy for the test to be
> used. It can be run against any device for the basic functional
> coverage, and can be run against a device with a larger BAR for full
> coverage of huge mappings.
>
> Does QEMU emulate any devices that have 32MB or larger BARs?
Yep, looks like `-device pci-testdev,membar=64M,membar-backed=on` or
even `-device bochs-display,vgamem=64M` would be suitable.
So I'll also try moving the existing test over to one of these to at
least remove the EDU++ device dependency. (bochs-display has >1 BAR,
and some MMIO regs which are nice for a quick kick-the-tyres access test.)
Cheers,
Matt
https://fivenightsatfreddysgame.io/
Introduction
Horror games come in many forms. Some rely on monsters chasing you through dark hallways, while others create fear by making you feel trapped and helpless. One of the most famous examples of the second approach is Fnaf, short for Five Nights at Freddy’s.
What makes the game interesting is that you don’t spend most of your time running around. Instead, you sit in a small security office, watching cameras and trying to survive until morning. The idea sounds simple at first, but the tension builds surprisingly fast. Every sound becomes suspicious, every camera check feels important, and every mistake can end the night immediately.
For players who are new to horror games, Fnaf is a great example of how atmosphere and anticipation can be more frightening than constant action.
Gameplay: What You Actually Do
The basic setup is easy to understand. You play as a night security guard working at a family entertainment restaurant filled with animatronic characters. During the day they entertain guests, but at night they begin moving around the building.
Your goal is straightforward: survive from midnight until 6 AM.
To do that, you have a few tools:
• Security cameras
• Door controls
• Hallway lights
• Limited electrical power
Most of the gameplay revolves around monitoring the cameras to track where the animatronics are located. If one gets too close to your office, you may need to close a door or check a hallway light. The problem is that every action consumes power, and once the power runs out, your defenses become much weaker.
This creates the game’s main challenge: balancing information and resources. Check the cameras too often and you waste power. Ignore them for too long and an animatronic may reach your office without warning.
That constant trade-off is what keeps the game tense even after you understand the rules.
Why Fnaf Feels Different From Other Horror Games
Many horror games focus on exploration, puzzles, or combat. Fnaf takes a much more restricted approach.
You’re mostly sitting in one room.
Surprisingly, that limitation makes the experience more intense. Because you can’t freely escape danger, you’re forced to pay attention to small details:
• Footsteps
• Mechanical noises
• Camera movement
• Sudden silence
• Flickering lights
The fear comes from anticipation rather than action. You know something is moving toward you, but you’re never completely sure when it will arrive.
Another reason the game became so popular is its memorable characters. The animatronics are designed to look friendly on the surface, yet they become unsettling the longer you watch them. That contrast between a cheerful restaurant and a threatening nighttime atmosphere creates a unique style of horror.
Tips for New Players
If you’re trying Fnaf for the first time, the early nights can feel overwhelming. Here are a few simple tips that helped many players, including me, enjoy the game more.
1. Stay Calm
The game is designed to make you panic. When something suddenly appears near your office, it’s easy to start clicking buttons randomly. Taking a breath and reacting carefully usually works better.
2. Learn the Camera Layout
Spend a little time memorizing where the important rooms are located. Knowing which cameras connect to your office helps you react faster when animatronics begin moving.
3. Don’t Overuse the Doors
A common beginner mistake is keeping the doors closed all the time. This drains power quickly. Use them only when an animatronic is actually nearby.
4. Listen Carefully
Sound is extremely important. Headphones can make a big difference because audio cues often tell you more than the cameras do.
5. Expect a Few Jump Scares
Everyone gets surprised at first. Instead of trying to avoid every jump scare, treat them as part of the learning process. After a few attempts, you’ll start recognizing the warning signs earlier.
6. Take Breaks if Needed
Fnaf can be surprisingly stressful, especially during later nights. If your heart is racing after a tough attempt, there’s nothing wrong with taking a short break before trying again.
The Best Way to Experience It
In my opinion, Fnaf is most enjoyable when played in a quiet room with headphones and minimal distractions. The game relies heavily on atmosphere, so playing while multitasking removes much of the tension.
I also recommend going into the game without watching too many strategy videos first. Discovering how the animatronics behave on your own makes the experience much more memorable. Part of the fun is slowly understanding the patterns and improving night by night.
Playing with friends nearby can be entertaining too. Even people who aren’t controlling the game often react strongly to the sudden scares and close calls.
Conclusion
Fnaf remains one of the most recognizable horror games because it proves that a simple idea can create incredible tension. You don’t need complicated controls, huge maps, or constant combat to feel nervous. Sometimes sitting alone in a small office with limited power is enough.
The game rewards observation, patience, and resource management while delivering plenty of suspense along the way. Whether you’re completely new to horror games or just looking for a classic experience, Fnaf offers a unique mix of strategy and fear that still holds up years later.
If you decide to try it, don’t worry about surviving every night immediately. The fun comes from learning the patterns, reacting under pressure, and slowly becoming more confident as the nights get harder. That gradual progression is what makes the experience so memorable.
On Thu, 16 Jul 2026 21:23:22 +0000
David Matlack <dmatlack(a)google.com> wrote:
> On 2026-07-16 03:51 PM, Matt Evans wrote:
> > Hi David,
> >
> > On 15/07/2026 19:12, David Matlack wrote:
> > > On Wed, Jul 15, 2026 at 10:47 AM Matt Evans <matt(a)ozlabs.org> wrote:
> > >
> > >> 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…
> > >
> > > It'd be great to have this test upstream. I'm happy to review it when
> > > you're ready. Looks like it just needs to be redone to use the VFIO
> > > selftests library and kselftests harness. AI could probably do the
> > > conversion pretty quick :)
> >
> > For sure, I'd intended to catch up with you on best approach here. :)
> >
> > Aside from the organic structure of the test (the open-coded VFIO
> > device/group setup/init needs to go), the main issue is that it relies
> > on a hacked/out of tree QEMU "EDU++" device with a second larger BAR
> > (containing freely read-writable memory). A subset of tests run with
> > the in-tree EDU device, but coverage is too low.
> >
> > The desirable properties are:
> >
> > - Having a BAR that is pure memory (all locations present, writable
> > without disruptive side-effects) so that mapping aliases can be
> > constructed and detected. This is good to test things like non-zero
> > vm_pgoffs and VA space presentation of physically-discontiguous DMABUFs.
> >
> > - BAR >> hugepage size so we can eyeball huge mappings work (or better,
> > mechanically test for them). At least 32MB would tick this box for 4K,
> > 16K page systems.
> >
> > - Something QEMU supports*, so one can run the test in a VM/TCG system.
> >
> > There were some real device models in QEMU that could be used this way,
> > but needed a fair bit of setup; I didn't want to rathole
> > vfio_dmabuf_mmap_test on including a ton of device-specific code for
> > some video card or similar.
> >
> > I'll dig more for a simple target that provides these properties --
> > obviously it would be better to point this test at an off-the-shelf
> > device (including silicon!). And, proposing EDU extensions to the QEMU
> > folks may be useful (there're uses for a better EDU in other contexts too).
> >
> > Since this test uses MMIO for a specific [class of] function, my first
> > thought is it should be another VFIO driver-type test sibling of
> > vfio_pci_driver_test. For example, we could extend the driver-type
> > tests' backend struct vfio_pci_driver_ops for functions capable of
> > providing a Big Memory BAR, like QEMU EDU++. EDU can also memcpy, so
> > could also support vfio_pci_driver_test.
> >
> > The spirit of the device backends hiding setup of a complex device is
> > handy, and it's plausible that several backends could provide this "big
> > memory BAR" service. What do you think, any concerns with extending
> > vfio_pci_driver_ops like that?
>
> I wouldn't recommend leveraging the driver framework unless absolutely
> necessary. It makes the test harder to run.
>
> The biggest issue I see with the proposed properties is being able to
> treat the BAR as memory. That obviously will depend on the device and
> may require device-specific setup. If we decide that treating the BAR as
> memory is truly required then using the driver framework is the way to
> go. But I'm hoping we can avoid that requirement.
Could you run a test where only a known part of the BAR can be treated
as memory?
A large BAR is likely to have some areas that can be accessed as memory.
David
>
> Instead, I think you can get pretty far by inspecting /proc/pid/pagemap
> to determine if the mmap() set things up correctly, without actually
> accessing the BAR. You can use /proc/pid/pagemap to look up the PFN and
> PAGEMAP_SCAN to detect huge pages.
>
> With that requirement gone, then all you really need is a device with a
> large enough BAR. And even that it not a hard requirement. I'm sure
> there are plenty of test cases that could work with smaller BARs. The
> few tests that want to exercise huge mappings can inspect the device BAR
> sizes first, and if they're all too small, SKIP() the test.
>
> If you structure the test this way, then it's easy for the test to be
> used. It can be run against any device for the basic functional
> coverage, and can be run against a device with a larger BAR for full
> coverage of huge mappings.
>
> Does QEMU emulate any devices that have 32MB or larger BARs?
>
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)
Wikipedia Page Creations offers comprehensive content services for clients seeking professionally developed Wikipedia articles. Our company provides article writing, content editing, page updates, consultation, and ongoing support, ensuring every project is handled with care and attention to detail at https://www.wikipediapagecreations.com/. Our commitment to quality and personalized service has made them a trusted choice for clients across various industries.
We all have those moments, don't we? A frustrating day at work, a challenging interaction, or simply a build-up of everyday annoyances. Sometimes, you just need a healthy outlet to release that pent-up energy without actually harming anyone or anything important. That's where games like kick the buddy step in, offering a uniquely satisfying and surprisingly cathartic experience. Far from being just mindless destruction, these digital stress-relievers provide a humorous and accessible way to blow off steam.
https://kickthebuddy.lol/
For those unfamiliar, Kick the Buddy is a mobile and web-based game centered around a simple, yet endlessly entertaining premise: you get to virtually abuse a ragdoll character named Buddy in a multitude of creative and over-the-top ways. It’s the kind of game that doesn't take itself seriously, and that's precisely its charm. It's not about intricate storylines or strategic battles; it's about pure, unadulterated, and consequence-free catharsis.
The Gameplay Loop: A Symphony of Destruction
The core gameplay of Kick the Buddy is refreshingly straightforward. Upon starting the game, you're presented with Buddy, a perpetually cheerful (or perhaps just oblivious) ragdoll, usually standing in the center of a room. Your objective? To unleash your inner destructive tendencies upon him using a vast arsenal of weapons and gadgets.
The controls are intuitive and designed for touchscreens, making it incredibly easy to pick up and play. You simply tap and drag to throw Buddy around, or tap on weapons from a side menu to deploy them. The initial weapons are usually simple – a basic pistol, a baseball bat, or perhaps some throwing knives. As you play and earn in-game currency (often through the sheer volume of damage you inflict), you unlock more outlandish and elaborate tools of destruction.
And this is where the game truly shines. The variety of ways you can "punish" Buddy is genuinely impressive and often hilarious. Want to pepper him with machine gun fire? Go for it. Feel like freezing him solid and then smashing him with a sledgehammer? Absolutely. Fancy launching him into space with a rocket launcher or calling down an airstrike? All within the realm of possibility. There are even more esoteric options like black holes, elemental attacks, and bizarre, fantastical devices that defy easy categorization. Each weapon has its own unique animation and sound effect, adding to the satisfying feedback loop.
Beyond simply using weapons, you can also interact with Buddy directly. Drag him, spin him, bounce him off the walls – the physics engine, while not hyper-realistic, is good enough to make these interactions feel dynamic and engaging. There are also environmental hazards that can be triggered, like spikes emerging from the floor or laser grids. The goal is to inflict as much damage as possible, which then translates into the in-game currency you use to unlock more fun ways to inflict damage. It's a self-perpetuating cycle of gleeful destruction. You can experience this stress-relieving fun for yourself by checking out the official game at Kick the Buddy.
Tips for Maximizing Your Mayhem (and Your Stress Relief)
While "Kick the Buddy" might seem like a game where you can just randomly tap and destroy, a few tips can enhance your experience and make your stress-relief sessions even more effective:
Experiment with Your Arsenal: Don't stick to just one or two weapons. The joy of the game comes from discovering new and increasingly outlandish ways to "kick" Buddy. Try combining different attacks – freeze him, then hit him with a rocket, then electrocute him. The creative possibilities are endless.
Focus on Combos:Â Many weapons work well in conjunction with others. For instance, weapons that pin Buddy down (like a net) can set him up perfectly for more powerful, slower-acting weapons. Similarly, explosive weapons can launch him into environmental hazards for bonus points.
Embrace the Absurdity:Â The game is meant to be silly. Don't overthink it. The more you lean into the over-the-top nature of the destruction, the more enjoyable it becomes. Laugh at the ridiculous sound effects and Buddy's enduring resilience.
Utilize the Environment:Â Keep an eye out for interactive elements in the background. Sometimes, there are buttons or levers that can trigger unique hazards or effects, adding another layer of destructive fun.
Don't Rush:Â While it's tempting to just spam weapons, take a moment to appreciate the animations and the effects. Sometimes, the most satisfying moments come from a perfectly timed, powerful attack.
Consider Customization:Â As you progress, you'll often unlock options to customize Buddy's appearance or the background. While purely cosmetic, these can add a fresh feel to your destructive escapades.
Conclusion: A Digital Punching Bag for the Soul
"Kick the Buddy" and similar games offer a unique and genuinely beneficial form of entertainment. They provide a safe, consequence-free space to vent frustrations, unleash a little harmless aggression, and simply de-stress. It's a reminder that sometimes, the most effective way to deal with the pressures of life is to simply embrace a little absurdity and blow off some steam, even if it's just by virtually pelting a cheerful ragdoll with a barrage of rockets and lasers. So, the next time you feel a bit overwhelmed, consider giving Buddy a friendly (or not-so-friendly) visit – your sanity might just thank you for it.
Both Tvrtko [1] and I [2] have recently proposed some improvals for
drm_sched.
While taking Tvrtko's feedback into account for my patch, I realized
that both his and my patch can be fully replaced with a bigger and far
more beautiful series.
If I am not mistaken, it turns out that the entire entity->entity_idle
completion is also nothing but a workaround around the grave mistake of
not using the greatest helper with parallel programming that exists in
computer science: Locking.
This series adds locking to the last_scheduled field and all checks
related to detect the idleness of the entity. As before, the
job_scheduled event queue causes the periodic checks.
This way, we can get rid of memory barriers, RCU, a few lines of code,
make things more readable, understandable...
Tested with drm-sched-unit tests. I'm a bit busy right now, but wanted
to show you guys the idea. Before merging I'd test it more exhaustively
with Nouveau.
Greetings,
Philipp
[1] https://lore.kernel.org/dri-devel/20260611123423.39819-1-tvrtko.ursulin@iga…
[2] https://lore.kernel.org/dri-devel/20260626081942.2122144-2-phasta@kernel.or…
Philipp Stanner (5):
drm/sched: Protect entity->last_scheduled with spinlock
drm/sched: Lock spsc_queue in drm_sched_entity_pop_job()
drm/sched: Avoid lock cycle for sched_entity
drm/sched: Lock drm_sched_entity_is_idle()
drm/sched: Remove entity->entity_idle
drivers/gpu/drm/scheduler/sched_entity.c | 75 +++++++++++-------------
drivers/gpu/drm/scheduler/sched_main.c | 2 -
drivers/gpu/drm/scheduler/sched_rq.c | 5 +-
include/drm/gpu_scheduler.h | 16 ++---
4 files changed, 41 insertions(+), 57 deletions(-)
base-commit: be4f10d44757211fd656fa57f37034657f26c883
--
2.54.0
Several drivers call dma_buf_fd() — which internally calls fd_install()
— before copy_to_user() returns the fd number to userspace. If
copy_to_user() fails, the fd is already published in the caller's fd
table but the ioctl returns an error, so userspace never learns the fd
number. Worse, the window between fd_install() and copy_to_user()
allows other threads to observe and manipulate the fd (dup, close,
SCM_RIGHTS), making any "close it on the failure path" fix unsafe.
The fix is to split the allocation into three steps: reserve an fd with
get_unused_fd_flags() (not yet visible to other threads), do
copy_to_user(), and only then publish the fd with fd_install() via the
new dma_buf_fd_install() helper. On copy_to_user() failure,
put_unused_fd() + dma_buf_put() cleanly unwind with no user-visible
side effects.
Patch 1 introduces dma_buf_fd_install() in dma-buf.c (wrapping
fd_install() together with the DMA_BUF_TRACE call to preserve export
tracing) and applies the fix to dma-heap.
Patch 2 applies the same fix to fastrpc, which even had a comment
acknowledging the problem could not be fixed before.
v1: https://lore.kernel.org/dri-devel/20260703080922.1838362-1-shoubaineng@gmai…
v2: https://lore.kernel.org/dri-devel/20260710105430.3059661-1-shoubaineng@gmai…
Changes in v3:
- Split into two patches (dma-heap + fastrpc separately)
- Add dma_buf_fd_install() to preserve trace_dma_buf_fd tracepoint
(spotted by T.J. Mercier and sashiko-bot on v2)
- Add fastrpc fix using the new helper (suggested by T.J. Mercier)
Baineng Shou (2):
dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds
misc: fastrpc: don't publish fd before copy_to_user() succeeds
drivers/dma-buf/dma-buf.c | 20 ++++++++++
drivers/dma-buf/dma-heap.c | 80 +++++++++++++++++++-------------------
drivers/misc/fastrpc.c | 16 +++-----
include/linux/dma-buf.h | 1 +
4 files changed, 67 insertions(+), 50 deletions(-)
--
2.34.1
Changes since v4:
- Fix an uninitialized memory bug for FenceCbRegistration with
ManuallyDrop.
- Return FenceCtx as impl PinInit
- Make FenceCtx return an impl PinInit<T, Error> (Danilo)
- Reformat some comments
- Adjust the docu for rcu_barrier(), so that it matches the C side's
docu and our docu for rcu::synchronize_rcu().
Changes since v3:
- Add a FIXME for an encountered Rust compiler bug. (Gary)
- Add new Rust files also to DRM drivers & common infrastructure
MAINTAINERS file. (Danilo)
- Reposition ECANCELED error code. (Miguel)
- Replace refcounted FenceCtx in DriverFenceData with a reference plus
life time. (Boris)
- Re-add rcu_barrier() patch, since we now can use it for dropping the
fence context. (Danilo)
- Add forgotten R-b from Alice, and Acks for MAINTAINERS from
Christian and Sumit.
Changes since v2:
- Don't drop DriverFenceData as a whole, but only the members we
really want to drop. Gives more robustness. (Gary).
- Break apart large pin_init_from_closure(). (Danilo, Onur)
- Remove rcu_barrier() and synchronize_rcu() from FenceCtx::drop().
FenceCtx might drop in atomic context, where you must not perform
those operations. With the current way C dma_fence is designed, the
driver must wait for a grace period manually until it unloads.
- Repair the DriverFenceBorrow implementation, properly injecting a
life time into it. (Danilo)
- Fix memory layout bug for rcu_head. (Onur)
- Drop RCU patches, since this series doesn't need them anymore.
Changes since v1:
- Remove unnecessary mutable references (Alice)
- Split up unsafe comments where possible (Danilo)
- Remove PhantomData + implement FenceCtx ops trait (Boris)
- Consistently call FenceCtx generic data `T`. FenceDataType is
derived from that. (Boris)
- Add abstractions for call_rcu() and synchronize_rcu() (Danilo)
- Add ECANCELED error code in Rust (Alice)
- Remove the rcu_barrier() from FenceCtx::drop() – because we now use
call_rcu(), there can be no UAF access to the FenceCtx anymore. In
any case, it is illegal to use either call_rcu() or
synchronize_rcu() in FenceCtx::drop(), because our new
drop_driver_fence_data() can run in atomic context and might put the
last fence_ctx reference.
So we now only have to guard against module unload, which it seems
either the driver or Rust driver-core / module unload infrastructure
must solve.
- Minor formatting etc. changes
- Add C helpers to MAINTAINERS. (Danilo)
- Ensure that `Fence::is_signaled()` is fully synchronized, i.e., all
callbacks really have run. See [1] and [2]. (Myself, Christian
König)
Changes since the RFCs:
- Include support for ForeignOwnable for ARef, so that a Fence can be
stuffed into an XArray et al. (Code by Danilo)
- Implement ForeignOwnable (with new borrow type) for DriverFence, so
that it can be stuffed into an XArray.
- Include the rcu::RcuBox data type to defer dropping data with RCU
(Cody by Alice)
- Port DmaFence to RcuBox to make UAF bugs through later, new dma_fence
callbacks (backend_ops) impossible.
- Force users to pass their fence data in an RcuBox (or have it not
need drop()) through a Sealed trait.
- Document the rules for the user's DriverFence::data's drop
implementation very clearly (deadlock danger).
- rustfmt, Clippy.
- Various style suggestions, safety comments, etc. (Önur)
- Add __rust_helper prefix to helper functions. (Önur)
Changes in RFC v3:
- Omit JobQueue patches for now
- Completely redesign the memory layout: Instead of a Fence
refcounting a DriverFence, both now live in the same allocation to
allow for future support the dma_fence backend_ops callbacks which
need to do container_of. (mostly Boris's feedback)
- Allow for pre-allocating fences to avoid deadlocks when submitting
jobs to a GPU. (Boris)
- Simultaneously, allow for pre-preparing fence callback objects, so
the driver can allocate them when it sees fit. (code largely stolen
and inspired by Daniel).
- Signal fences on drop, ensure synchronization.
- Force users to set an error code when signalling.
- Write more documentation
- A ton of minor other changes.
[1] https://lore.kernel.org/dri-devel/20260608142436.265820-2-phasta@kernel.org/
[2] https://lore.kernel.org/dri-devel/20260612104251.2264707-2-phasta@kernel.or…
Alright, so since the last RFCs did not reveal significant design
issues, I decided to transition this series to a v1 and hope that we can
get it upstream.
This now includes code for more common infrastructure that dma_fence
needs, contributed by Danilo and Alice.
---
Old cover letter for RFC:
So, this is the spiritual successor of the first / second RFC [1]. v2
also contained code for drm::JobQueue, but mostly to show how the fence
code would be used. JobQueue is under heavy rework right now, so I don't
want to bother your eyes with it. The docstring examples should show how
Rust fences are supposed to be used, though.
This v3 contains a huge amount of highly valuable feedback from a
variety of people, notably Boris, but also from Alice, Gary and Danilo.
There are some TODOs open (a better trait for fence backend_ops and RCU
support), but my hope is that this effort is now finally approaching its
end.
I would greatly appreciate feedback and especially more information
about what might be missing to make this usable, which is obviously
where Daniel's and Boris's feedback will be valuable once more.
Please regard this patch just as what it's titled: an RFC, to discuss a
bit more and to inform a broader community about what the current state
is and where this is heading at.
Many regards,
Philipp
[1] https://lore.kernel.org/rust-for-linux/20260203081403.68733-2-phasta@kernel…
Danilo Krummrich (1):
rust: types: implement ForeignOwnable for ARef<T>
Philipp Stanner (4):
rust: error: Add ECANCELED error code
rust: sync: Add abstraction for rcu_barrier()
rust: Add dma_fence abstractions
MAINTAINERS: Add entry for Rust dma-buf
MAINTAINERS | 5 +
rust/bindings/bindings_helper.h | 1 +
rust/helpers/dma_fence.c | 48 ++
rust/helpers/helpers.c | 1 +
rust/kernel/dma_buf/dma_fence.rs | 894 +++++++++++++++++++++++++++++++
rust/kernel/dma_buf/mod.rs | 14 +
rust/kernel/error.rs | 1 +
rust/kernel/lib.rs | 1 +
rust/kernel/sync/aref.rs | 40 ++
rust/kernel/sync/rcu.rs | 20 +
10 files changed, 1025 insertions(+)
create mode 100644 rust/helpers/dma_fence.c
create mode 100644 rust/kernel/dma_buf/dma_fence.rs
create mode 100644 rust/kernel/dma_buf/mod.rs
base-commit: a73a398a68ca9b9e5116a617562471f16b8310c4
--
2.54.0