Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba(a)kernel.org>:
On Wed, 05 Aug 2026 13:42:42 -0700 you wrote:
> 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.
>
> [...]
Here is the summary with links:
- [net-next,v8,1/3] net: devmem: allow rx-page-size > PAGE_SIZE per dmabuf binding
https://git.kernel.org/netdev/net-next/c/b27a8560eec9
- [net-next,v8,2/3] selftests/net: ncdevmem: add -b option to set rx-page-size on bind
https://git.kernel.org/netdev/net-next/c/3e8c9ec4eb75
- [net-next,v8,3/3] selftests/net: devmem.py: add check_rx_large_niov
https://git.kernel.org/netdev/net-next/c/8ac4255c1e0c
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
On Fri, Aug 7, 2026 at 3:12 AM Baineng Shou <shoubaineng(a)gmail.com> wrote:
>
> Add a test case that verifies no file descriptor is leaked when
> DMA_HEAP_IOCTL_ALLOC succeeds internally but copy_to_user() fails
> to deliver the fd number back to userspace.
>
> The failure is triggered by placing the ioctl argument in a private
> anonymous page and flipping it to PROT_READ (via mprotect) between
> the kernel's copy_from_user() and copy_to_user() calls. With the
> buggy kernel the ioctl returns -EFAULT but leaves an extra open fd
> in the process's fd table; with the fixed kernel the fd count is
> unchanged.
>
> This serves as a regression test for:
> "dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds"
>
> Suggested-by: Sumit Semwal <sumit.semwal(a)linaro.org>
> Signed-off-by: Baineng Shou <shoubaineng(a)gmail.com>
Reviewed-by: T.J. Mercier <tjmercier(a)google.com>
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> {
> + const FOREIGN_ALIGN: usize = core::mem::align_of::<T>();
> +
> + type Borrowed<'a> = &'a T;
> + type BorrowedMut<'a> = &'a T;
> +
`#[inline]` here and all others.
Best,
Gary
> + 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 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
On Wed, 2026-08-05 at 10:50 +0200, Andreas Hindborg wrote:
> "Philipp Stanner" <phasta(a)kernel.org> writes:
>
> > One often cannot allocate in the kernel with the desired flags, most
> > notably in atomic context. Pre-allocating the memory is the preferred
> > solution in such situations.
> >
> > Add support for xa_reserve() in the Rust abstractions of xarray. Create
> > a Reservation object similar to a lock-guard, that can be dropped once
> > the reservation is no longer needed or once the index was stored to.
> >
> > Signed-off-by: Philipp Stanner <phasta(a)kernel.org>
> > ---
> > Please regard this more as an RFC.
> >
> > I need pre-allocating in XArray for DmaFence. How exactly we achieve
> > this is open for discussion.
>
> Do you need to actually reserve a key, or do you just need atomic
> allocation?
I would just have needed a position to store to, but the fence sequence
number would be the only reasonable index, so you'd also reserve a key.
Anyways, please forget about this for now, we abstained from using the
XArray in the current revision (v8) of this patch series.
Thx
P.