DMA_HEAP_IOCTL_ALLOC allocates a dma-buf and installs an fd into the
caller's fd table via fd_install() before dma_heap_ioctl() copies the
result back to userspace. If the trailing copy_to_user() fails, the
ioctl returns -EFAULT and userspace never learns the fd number, but
the fd (and the underlying dma-buf reference) remain in the caller's
fd table and are leaked for the lifetime of the process.
The failure is easily reachable from userspace: pass a struct
dma_heap_allocation_data that lives in a page whose protection is
flipped to PROT_READ between copy_from_user() and copy_to_user()
(e.g. via mprotect()). Each such ioctl leaks one dmabuf fd; repeating
the call quickly fills /proc/<pid>/fd with anonymous "/dmabuf:"
entries that only go away when the process exits.
Fix it by closing the installed fd (and clearing the fd field of the
kernel-side copy) when copy_to_user() fails after a successful
allocation, so the error path matches what userspace observes: no fd
was returned, therefore no fd is left behind.
Fixes: c02a81fba74f ("dma-buf: Add dma-buf heaps framework")
Cc: stable(a)vger.kernel.org
Signed-off-by: Baineng Shou <shoubaineng(a)gmail.com>
---
Reproducer (full source, gcc -o poc poc.c; run as root):
// poc.c -- leak one dma-buf fd per DMA_HEAP_IOCTL_ALLOC
// when copy_to_user() fails
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <sys/mman.h>
#include <linux/dma-heap.h>
int main(int argc, char **argv)
{
int n = argc > 1 ? atoi(argv[1]) : 100;
long ps = sysconf(_SC_PAGESIZE);
int heap = open("/dev/dma_heap/system", O_RDWR | O_CLOEXEC);
if (heap < 0)
return perror("open"), 1;
for (int i = 0; i < n; i++) {
/* Put a valid request in a page, then make the page
* read-only: copy_from_user() still succeeds and the
* dma-buf is allocated and fd_install()'d, but the
* trailing copy_to_user() fails and the fd, never
* returned to us, is leaked.
*/
struct dma_heap_allocation_data *req =
mmap(NULL, ps, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
memset(req, 0, sizeof(*req));
req->len = ps;
req->fd_flags = O_RDWR | O_CLOEXEC;
mprotect(req, ps, PROT_READ);
ioctl(heap, DMA_HEAP_IOCTL_ALLOC, req); /* -EFAULT */
munmap(req, ps);
}
printf("done: check ls -l /proc/%d/fd for %d leaked fds\n",
getpid(), n);
pause();
return 0;
}
Before the fix, ./poc 10 leaves 10 anonymous dmabuf fds in the
caller's fd table:
# ls -l /proc/$(pgrep poc)/fd
lrwx------ 1 root root 64 Jan 1 00:03 3 -> /dev/dma_heap/system
lrwx------ 1 root root 64 Jan 1 00:03 4 -> /dmabuf:
lrwx------ 1 root root 64 Jan 1 00:03 5 -> /dmabuf:
lrwx------ 1 root root 64 Jan 1 00:03 6 -> /dmabuf:
lrwx------ 1 root root 64 Jan 1 00:03 7 -> /dmabuf:
lrwx------ 1 root root 64 Jan 1 00:03 8 -> /dmabuf:
lrwx------ 1 root root 64 Jan 1 00:03 9 -> /dmabuf:
lrwx------ 1 root root 64 Jan 1 00:03 10 -> /dmabuf:
lrwx------ 1 root root 64 Jan 1 00:03 11 -> /dmabuf:
lrwx------ 1 root root 64 Jan 1 00:03 12 -> /dmabuf:
lrwx------ 1 root root 64 Jan 1 00:03 13 -> /dmabuf:
After the fix, only /dev/dma_heap/system remains open; the
anonymous "/dmabuf:" entries are gone.
drivers/dma-buf/dma-heap.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index a76bf3f8b071..0dd7a84b06bf 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -18,6 +18,7 @@
#include <linux/uaccess.h>
#include <linux/xarray.h>
#include <uapi/linux/dma-heap.h>
+#include <linux/fdtable.h>
#define DEVNAME "dma_heap"
@@ -181,8 +182,16 @@ static long dma_heap_ioctl(struct file *file, unsigned int ucmd,
goto err;
}
- if (copy_to_user((void __user *)arg, kdata, out_size) != 0)
+ if (copy_to_user((void __user *)arg, kdata, out_size) != 0) {
+ if (kcmd == DMA_HEAP_IOCTL_ALLOC && ret == 0) {
+ struct dma_heap_allocation_data *h = (void *)kdata;
+
+ close_fd(h->fd);
+ h->fd = -1;
+ }
ret = -EFAULT;
+ }
+
err:
if (kdata != stack_kdata)
kfree(kdata);
--
2.34.1
Hi all,
This series is based on previous RFCs/discussions:
Tech topic: https://lore.kernel.org/linux-iommu/20250918214425.2677057-1-amastro@fb.com/
RFCv1: https://lore.kernel.org/all/20260226202211.929005-1-mattev@meta.com/
RFCv2: https://lore.kernel.org/kvm/20260312184613.3710705-1-mattev@meta.com/
The background/rationale is covered in more detail in the RFC cover
letters. The TL;DR is:
The goal 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.)
As well as isolation and revocation, another advantage to accessing a
BAR through a VMA backed by a DMABUF is that it's straightforward to
mmap() the buffer with access attributes, such as write-combining.
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. Secondly, refactor
DMABUF export for use by the existing export feature and add 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, 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).
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; no
mappings or other access can be performed now. 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
By weight, this is mostly a rename of revoked to an enum, status.
There are now 3 states for a buffer, usable and revoked
temporary/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.)
vfio/pci: Add mmap() attributes to DMABUF feature
Adds a new VFIO feature, VFIO_DEVICE_FEATURE_DMA_BUF_MEMATTR.
After a DMABUF is exported, this feature is used to set a memory
attribute that will be used by future mmap()s of the DMABUF fd. It
doesn't affect existing maps.
The default is UC, and via the feature one can specify CPU access
as WC. The attribute is an enum/scalar rather than
bitmap/cumulative. The attributes follow a "try-fail" model where
a client can request an attribute and either succeed or fail with
ENOENT if it's unknown; if future attributes are platform-specific
then their support can be probed.
Since it's just UC/WC for now, there is no reservation or numeric
structure to the namespace yet, but we could support
system/arch-specific values in future by carving out base +
arch-specific + IMPDEF ranges.
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, attribute, 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. I've lightly tested WC mappings also (by observing
resulting PTEs as having the correct attributes...). 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
from several of you; I've added some Reviewed-Bys.
But, various changes were also requested and I'm erring on the
conservative side: I have NOT included your Reviewed-Bys where the
patch has 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.1.
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/8cd9520d35a6...dev/mev/vfio-dmabuf…
Thanks for reading,
Matt
================================================================================
Changelog:
v4:
- Rebased on v7.1
- 1/9: Split the p2pdma.c pool release code into a new patch, making
the second patch a pure code-move exercise. Reworded the commit
messages, comment cleanups.
- 2/9 Look up PFNs helper: renamed DMABUF range search loop variables
for clarity, and simplified search loop and fallthrough/exit logic.
Moved WARN to ratelimited warnings. Rearranged pfn arithmetic to
avoid potential overflow. Clarified comments, better explanation
of vma_pgoff_adjust, spelling.
- 4/9 convert BAR mmap(): Trivial comment change, move. Used 'true'
instead of '1' for unmap_mapping_range() arg, consistent with
elsewhere in vfio-pci.
- 5/9 User-facing name for mappings: Uses kasprintf() instead.
- 6/9 Clean up BAR zap: Renamed functions to simplify/shorten names,
emphasising "revoke/unrevoke" actions. (Then internally this will
do a DMABUF revoke and possibly a PTE zap.)
NOTE: We debated ordering of a previous zap before a transition
to D0 before reset. The conclusion was the current patch is OK.
- 7/9 mmap() of a DMABUF: Added helper vfio_pci_set_vma_ops() to keep
ops struct static/local. Squashed vfio_pci_dma_buf_mmap() comments
for space/clarity.
- 8/9 DMABUF revoke: Fix typos in commit message. Implement request
to add a condition to revocation path to only invalidate/wait when
a buffer is being revoked (avoiding it on un-revoke).
NOTE: This means a (small) change to the code moved from
vfio_pci_dma_buf_move.
NOTE: Also, we discussed adding warnings for setting a state
matching the existing state; I didn't add them after all, because
these situations can occur in normal usage (e.g. a revoke of a
buffer from a device in D3, or a cleanup of a lingering
user-revoked buffer).
v3:
https://lore.kernel.org/all/20260610154327.37758-1-matt@ozlabs.org/
- Refactor p2pdma.c: split out pcim_p2pdma_provider() into a new
p2pdma_core.c under CONFIG_PCI_P2PDMA_CORE.
- vfio_pci_dma_buf_find_pfn() cleanups: Rename parameter to priv,
remove bad WARN, move unnecessary addition out of inner loop.
- vfio_pci_core_mmap_prep_dmabuf() cleanups: Remove uint32_t, remove
unnecessary const variable.
- Conversion of BAR mmap() to DMABUF: VFIO_PCI_DMABUF depends on
VFIO_PCI_CORE. vfio_pci_mmap_huge_fault(): move dev_dbg() outside
of lock (argh), remove READ_ONCE(vdev)/move priv->vdev read and
improve comment explanation.
- On revoke, BAR zap defaults to on if .mmap is overridden by a
driver (and implements an opt-out for the hisi_acc_vfio_pci driver,
which overrides mmap() with a simple wrapper that ends up using the
common DMABUF mmap() rather than custom mappings).
- Reworded commit "vfio/pci: Support mmap() of a VFIO DMABUF" message
for clarity. Reworded vfio_pci_mmap_huge_fault() comment for
accuracy (vdev validity depends on not being revoked).
Added comment in mmap() explaining belt-and-braces approach for
early detecting a map of a revoked buffer.
- Revoke now uses VFIO_DEVICE_FEATURE_DMA_BUF rather than a new
ioctl(); instead of the revoke helper taking 'revoked/permanently'
bools, it's become vfio_pci_dma_buf_set_status() taking a single
status enum. Added a READ_ONCE() for the lockless test of
priv->vdev (flags it as intentional, even if it's in practice going
to be a single-copy atomic read).
- Removed GET on vfio_pci_core_feature_dma_buf_memattr(), removed
unnecessary taking of memory_lock, fixed error return values. In
particular, removes ENOTSUPP, and uses ENOENT to indicate an
unknown attribute enum value was passed to SET. In the discussion
here,
https://lore.kernel.org/all/20260602131417.41366391@shazbot.org/
we'd agreed on EOPNOTSUPP before I realised that's already used
elsewhere. ENOENT uniquely indicates an unknown attribute.
v2:
https://lore.kernel.org/all/20260527102319.100128-1-mattev@meta.com/
- Rebase on VFIO next, picking up Alex's
vfio_pci_dma_buf_move()/vfio_pci_dma_buf_cleanup() fixes, and
dropping "vfio/pci: Fix vfio_pci_dma_buf_cleanup() double-put"
- Added "PCI/P2PDMA: Add CONFIG_PCI_P2PDMA_CORE" so that the
newly-added vfio-pci hard dependency on the P2PDMA provider instead
pulls in the _CORE variant and not the full-fat CONFIG_PCI_P2PDMA.
This means that the core of vfio-pci does not need ZONE_DEVICE, but
if it's available then enabling P2PDMA in turn enables DMABUF
export. Fixes basic VFIO operation on 32b or other platforms without
ZONE_DEVICE.
- Fixed comment inaccuracy in vfio_pci_dma_buf_revoke() and cleaned
up vdev validity test.
- vfio_pci_dma_buf_find_pfn(): use PAGE_ALIGN(), better span variable
naming, OVF check
- Made vm_pgoffs use consistent (keeping the resource index at the
top and masking where offset is used). For BAR mmap, use new
vma_pgoff_adjust to create the DMABUF with the exact mmap()ed span
instead of from the start of the BAR with an invisible portion
before the mapping.
- Added VFIO_DEVICE_FEATURE_DMA_BUF_MEMATTR to set memory attributes,
instead of using the export `flags` field.
- vfio_pci_ioctl_reset: Moved vfio_pci_zap_revoke_bars()
(effectively, vfio_pci_dma_buf_move()) back after D0 transition.
Note, if a BAR zap is needed, it's done in this function so now
happens after this D0 transition with the _move; it was done before
it at the time of the memory_lock taking.
- Minimised vfio_pci_dma_buf_mmap() (removed redundant span check),
added READ_ONCE for memattr
- Misc fixes: comment in DMABUF name generation, removed superfluous
READ_ONCE from faulthandler
v1:
https://lore.kernel.org/kvm/20260416131815.2729131-1-mattev@meta.com/
- Cleanup of the common DMABUF-aware VMA vm_ops fault handler and
export code.
- Fixed a lot of races, particularly faults racing with DMABUF
cleanup (if the VFIO device fds close, for example).
- Added nicer human-readable names for VFIO mmap() VMAs
RFCv2: Respin based on the feedback/suggestions:
https://lore.kernel.org/kvm/20260312184613.3710705-1-mattev@meta.com/
- Transform the existing VFIO BAR mmap path to also use DMABUFs
behind the scenes, and then simply share that code for
explicitly-mapped DMABUFs. Jason wanted to go that direction to
enable iommufd VFIO type 1 emulation to pick up a DMABUF for an IO
mapping.
- Revoke buffers using a VFIO device fd ioctl
RFCv1:
https://lore.kernel.org/all/20260226202211.929005-1-mattev@meta.com/
Matt Evans (10):
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
vfio/pci: Add mmap() attributes to DMABUF feature
MAINTAINERS | 2 +-
drivers/pci/Kconfig | 10 +-
drivers/pci/Makefile | 1 +
drivers/pci/p2pdma.c | 109 +---
drivers/pci/p2pdma.h | 29 +
drivers/pci/p2pdma_core.c | 118 ++++
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 | 211 +++++--
drivers/vfio/pci/vfio_pci_dmabuf.c | 568 +++++++++++++++---
drivers/vfio/pci/vfio_pci_priv.h | 63 +-
include/linux/pci-p2pdma.h | 24 +-
include/linux/pci.h | 2 +-
include/linux/vfio_pci_core.h | 1 +
include/uapi/linux/vfio.h | 47 ++
17 files changed, 960 insertions(+), 271 deletions(-)
create mode 100644 drivers/pci/p2pdma.h
create mode 100644 drivers/pci/p2pdma_core.c
--
2.50.1 (Apple Git-155)
Every devmem dmabuf binding hands the page_pool PAGE_SIZE niovs today.
On NICs that consume one descriptor per netmem, this caps a single RX
descriptor at PAGE_SIZE and burns CPU on buffer churn.
In this series, we add a bind-time netlink attribute,
NETDEV_A_DMABUF_RX_BUF_SIZE, that lets userspace request a larger niov size
(power of two >= PAGE_SIZE). Drivers must opt in via
queue_mgmt_ops.QCFG_RX_PAGE_SIZE.
Selftests use udmabuf, but udmabuf sgtables were previously hardcoded to
PAGE_SIZE. This series modifies udmabuf to respect folio sizes in its exported
sgtable. The result is that when backing udmabuf with MFD_HUGETLB 2MB pages,
the sgtable is populated with 2MB entries, allowing devmem's gen_pool to carve
out large (eg. 64K) niovs.
Measurements
------------
Setup: kperf devmem RX/TX cuda, 4 flows, 64 MB messages, 60s, dctcp,
num-rx-queues=4, dmabuf-rx/tx-size-mb=2048, 10 runs per niov size,
mlx5.
niov RX dev Gbps RX flow avg Gbps app sys %
----- ---------------- ----------------- ----------------
4K 300.63 +/- 53.21 75.16 +/- 13.30 54.15 +/- 10.23
16K 321.35 +/- 28.20 80.34 +/- 7.05 41.05 +/- 8.87
32K 347.63 +/- 2.20 86.91 +/- 0.55 44.54 +/- 3.51
64K 332.11 +/- 14.26 83.03 +/- 3.56 35.47 +/- 3.11
RX app sys % drops ~19% from 4K to 64K.
kperf support (not yet merged):
https://github.com/facebookexperimental/kperf/commit/8837577f920876bce6986e…
Signed-off-by: Bobby Eshleman <bobbyeshleman(a)meta.com>
---
Changes in v4:
- ncdevmem: fix the possible overflow in ncdevmem (Sashiko)
- drop the udmabuf patch because the fix is now already in net-next
- silenced two pylint complaints in devmem_lib.py
- Link to v3: https://lore.kernel.org/r/20260612-tcpdm-large-niovs-v3-0-a3b693e76fcb@meta…
Changes in v3:
- fix a bunch of non-reverse christmas tree declarations (Stan)
- remove extra uint32 cast for getpagesize() (Stan)
- remove overzealous strtoul checking (Stan)
- remove value checks that the kernel already performs on rx_buf_size
(Stan)
- Link to v2: https://lore.kernel.org/r/20260611-tcpdm-large-niovs-v2-0-ee2bf15e7523@meta…
Changes in v2:
- Use NL_SET_ERR_MSG_FMT for sg alignment failure details (Stan)
- Keep -E2BIG (not a direct ask, but seemed preferred, Stan)
- Update udmabuf commit message and comments explaining why
"one sg ent per folio" is useful (Christian)
- Set/restore nr_hugepages in py harness (Stan)
- Link to v1: https://lore.kernel.org/r/20260603-tcpdm-large-niovs-v1-0-f37a4ac6726c@meta…
---
Bobby Eshleman (3):
net: devmem: allow rx-buf-size > PAGE_SIZE per dmabuf binding
selftests/net: ncdevmem: add -b option to set rx-buf-size on bind
selftests/net: devmem.py: add check_rx_large_niov
Documentation/netlink/specs/netdev.yaml | 8 +++
include/uapi/linux/netdev.h | 1 +
net/core/devmem.c | 55 +++++++++++---------
net/core/devmem.h | 13 +++--
net/core/netdev-genl-gen.c | 5 +-
net/core/netdev-genl.c | 19 ++++++-
tools/include/uapi/linux/netdev.h | 1 +
tools/testing/selftests/drivers/net/hw/devmem.py | 12 ++++-
.../testing/selftests/drivers/net/hw/devmem_lib.py | 59 +++++++++++++++++++++-
tools/testing/selftests/drivers/net/hw/ncdevmem.c | 36 +++++++++++--
.../testing/selftests/drivers/net/hw/nk_devmem.py | 11 +++-
11 files changed, 180 insertions(+), 40 deletions(-)
---
base-commit: 805185b7c7a1069e407b6f7b3bc98e44d415f484
change-id: 20260602-tcpdm-large-niovs-56523a3a1077
Best regards,
--
Bobby Eshleman <bobbyeshleman(a)meta.com>
From: Xiang Gao <gaoxiang17(a)xiaomi.com>
The kernel-doc comments for vmapping_counter and vmap_ptr in struct
dma_buf reference "@lock" as the protecting lock, but struct dma_buf
no longer has a "lock" member. The mutex was removed in favor of using
the dma_resv lock exclusively. The implementation correctly uses
dma_resv_assert_held(dmabuf->resv) in dma_buf_vmap() and
dma_buf_vunmap(), so update the documentation to reference @resv
instead.
Signed-off-by: gaoxiang17 <gaoxiang17(a)xiaomi.com>
---
include/linux/dma-buf.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 133b9e637b55..ef6d93fd7a2c 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -322,13 +322,13 @@ struct dma_buf {
* @vmapping_counter:
*
* Used internally to refcnt the vmaps returned by dma_buf_vmap().
- * Protected by @lock.
+ * Protected by @resv.
*/
unsigned vmapping_counter;
/**
* @vmap_ptr:
- * The current vmap ptr if @vmapping_counter > 0. Protected by @lock.
+ * The current vmap ptr if @vmapping_counter > 0. Protected by @resv.
*/
struct iosys_map vmap_ptr;
--
2.34.1
Exploring the World of Vehicle Engineering in Drive Mad
Drive Mad changes how we think about traditional racing games. You are not just pushing a gas pedal to win. You are managing the weight and the center of gravity of your machine. Every car has a different personality in this game. Some are heavy and stable while others are light and bouncy. Choosing the right vehicle for the level is your first strategic step.
The levels in Drive Mad are more like mechanical puzzles than race tracks. You have to understand the triggers that move the obstacles. A platform might drop only when you reach a certain point. You must time your approach to avoid the trap. It requires you to observe the environment before you take action. This brain work makes the game much more satisfying than simple racing titles.
You will encounter many moments of frustration during your progress. This is the main appeal of the game for many players. You learn from every mistake you make on the road. Eventually you find the perfect rhythm to clear the most difficult gaps. The feeling of success after a hard level is unmatched. Keep your focus sharp and your hands ready to drive.
https://drivinggames.io