All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Luigi Rizzo" <lrizzo@google.com>,
	"Luigi Rizzo" <rizzo.unipi@gmail.com>,
	"Joerg Roedel" <joro@8bytes.org>, "Will Deacon" <will@kernel.org>,
	"Robin Murphy" <robin.murphy@arm.com>,
	"Christoph Hellwig" <hch@lst.de>,
	"Marek Szyprowski" <m.szyprowski@samsung.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Vlastimil Babka" <vbabka@kernel.org>,
	"David Hildenbrand" <david@kernel.org>,
	"Jens Axboe" <axboe@kernel.dk>,
	"David S . Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@kernel.org>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Paolo Abeni" <pabeni@redhat.com>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Matthew Wilcox" <willy@infradead.org>,
	"Lorenzo Stoakes" <ljs@kernel.org>,
	"Jesper Dangaard Brouer" <hawk@kernel.org>,
	"Ilias Apalodimas" <ilias.apalodimas@linaro.org>,
	"Willem de Bruijn" <willemb@google.com>,
	"Kuniyuki Iwashima" <kuniyu@google.com>,
	"Joshua Washington" <joshwash@google.com>,
	"Harshitha Ramamurthy" <hramamurthy@google.com>,
	"Alexander Lobakin" <aleksander.lobakin@intel.com>,
	linux-mm@kvack.org
Subject: Re: [RFC PATCH v2 12/25] net/core: Use per-node PISA allocators for skb_page_frag_refill()
Date: Tue, 10 Nov 2026 23:50:43 +0000	[thread overview]
Message-ID: <sashiko-outbox-207955@kernel.org> (raw)
In-Reply-To: <20261109182533.3594984-13-lrizzo@google.com>

Thank you for your contribution! Sashiko AI review found 6 potential
issues to consider:
- [High] net: ip_make_skb() and ip6_make_skb() ignore sk_use_task_frag
  for PISA
- [Medium] net: skb_page_frag_refill_dev() checks ingress skb->dev on
  forwarded ESP packets
- [Medium] net: mismatched PISA and buddy page recycling in
  skb_page_frag_refill()
- [Medium] net: odd-offset checksum corruption in ping_getfrag() with
  PISA paged mode
- [Medium] net: plaintext TX data placed in PISA pages on MACsec in
  dst_tx_pisa_ok()
- [Low] iommu/pisa: netdev_tx_pisa_refresh() skips lower walk when
  dev.parent is set
--

commit 8f85f66c700b51ce7332c64edba9f65c4414c1f0
Author: Luigi Rizzo <lrizzo@google.com>

net/core: Use per-node PISA allocators for skb_page_frag_refill()

This commit adds per-task PISA page_frag support (current->task_frag_pisa)
and routes TX page_frag allocations to read-only PISA blocks when the
egress device has pisa_tx_bufs enabled.

> diff --git a/drivers/iommu/pisa-alloc.c b/drivers/iommu/pisa-alloc.c
> index 913706a503341..7b9d0a7acc101 100644
> --- a/drivers/iommu/pisa-alloc.c
> +++ b/drivers/iommu/pisa-alloc.c
> @@ -644,6 +644,63 @@ bool pisa_has_free_blocks_rx(const struct device *dev, unsigned int order, int n
[ ... ]
> +/* Slow path of __netdev_tx_pisa_ok(): refresh dev->pisa_tx_stamp. */
> +bool netdev_tx_pisa_refresh(struct net_device *dev, u32 now)
> +{
> +	bool ok;
> +
> +	if (dev->dev.parent) {
> +		ok = READ_ONCE(dev->dev.parent->pisa_tx_bufs);
> +	} else {
> +		rcu_read_lock();
> +		ok = netdev_walk_all_lower_dev_rcu(dev,
> +						   netdev_pisa_tx_bufs_walk,
> +						   NULL) != 0;
> +		rcu_read_unlock();
> +	}
> +	now |= ok ? PISA_TX_STAMP_OK : 0;
> +	WRITE_ONCE(dev->pisa_tx_stamp, now);
> +	return now & PISA_TX_STAMP_OK;
> +}

[Severity: Low]
Does checking dev->dev.parent before walking lower devices miss lower DMA
NICs under upper devices that set dev->dev.parent?

Stacked interfaces such as net_failover, hv_netvsc, and DSA user ports set
dev->dev.parent via SET_NETDEV_DEV() while linking the underlying PCI VF or
conduit NIC as a lower device.  When pisa_tx_bufs is enabled on that lower
device, netdev_tx_pisa_refresh() only reads the upper device's
dev->dev.parent->pisa_tx_bufs (false) and skips
netdev_walk_all_lower_dev_rcu(), leaving TX allocations on regular buddy
pages.

> diff --git a/include/net/sock.h b/include/net/sock.h
> index 173b37b2b8bb0..73906351d11db 100644
> --- a/include/net/sock.h
> +++ b/include/net/sock.h
> @@ -2670,6 +2670,95 @@ static inline struct page_frag *sk_page_frag(struct sock *sk)
[ ... ]
> +/*
> + * May TX payload routed through @dst be copied into PISA pages? Those pages
> + * stay readable by every device that mapped them for as long as they are
> + * active, so only data that leaves the host in clear qualifies: IPsec payload
> + * is still plaintext here.
> + */
> +static inline bool dst_tx_pisa_ok(const struct dst_entry *dst)
> +{
> +	bool ok = false;
> +
> +	if (!net_pisa_tx_bufs_enabled() || !dst)
> +		return false;
> +
> +	rcu_read_lock();
> +	if (!dst_xfrm(dst))
> +		ok = __netdev_tx_pisa_ok(dst_dev_rcu(dst));
> +	rcu_read_unlock();
> +	return ok;
> +}

[Severity: Medium]
Can dst_tx_pisa_ok() place unencrypted plaintext into PISA pages when
routing over software MACsec?

A MACsec net_device has dev->dev.parent == NULL and links its physical NIC
as a lower device, so netdev_tx_pisa_refresh() propagates PISA_TX_STAMP_OK
from the NIC to the MACsec interface while !dst_xfrm(dst) is true.  Socket
send paths then copy plaintext into current->task_frag_pisa before
macsec_encrypt() runs, exposing cleartext in DMA-readable (and on CoCo
guests, shared/decrypted) PISA pages and holding it in tcp_rtx_queue until
ACKed.  In addition, forcing paged = true in __ip_append_data() and
__ip6_append_data() causes macsec_encrypt() -> skb_cow_data() to
immediately reallocate skb->head and linearize the fragments.

> diff --git a/net/core/sock.c b/net/core/sock.c
> index e2401d735c5a7..695fefe316925 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
[ ... ]
> @@ -3257,13 +3258,20 @@ DEFINE_STATIC_KEY_FALSE(net_high_order_alloc_disable_key);
>   */
>  bool skb_page_frag_refill(unsigned int sz, struct page_frag *pfrag, gfp_t gfp)
>  {
> +	/* PISA pages only go into current->task_frag_pisa, see sk_page_frag_dst(). */
> +	if (is_pisa_pfrag(pfrag))
> +		gfp |= __GFP_PISA_RO;
> +
>  	if (pfrag->page) {
> +		if ((gfp & __GFP_PISA_RO) && !pisa_page_can_recycle(pfrag->page))
> +			goto drop_page;
>  		if (page_ref_count(pfrag->page) == 1) {
>  			pfrag->offset = 0;
>  			return true;
>  		}
>  		if (pfrag->offset + sz <= pfrag->size)
>  			return true;
> +drop_page:
>  		put_page(pfrag->page);
>  	}

[Severity: Medium]
Does skb_page_frag_refill() recycle a page of the wrong type when
page_ref_count(pfrag->page) == 1?

pisa_page_can_recycle() returns true for non-PISA pages:

drivers/iommu/pisa-alloc.c:pisa_page_can_recycle() {
	if (!is_pisa_pfn(pfn))
		goto out;
    ...
}

If current->task_frag_pisa or x->xfrag caches a fallback buddy page (for
example after a high-order PISA pool miss or before pisa_tx_bufs was
enabled), skb_page_frag_refill() resets pfrag->offset = 0 whenever
page_ref_count(pfrag->page) == 1 and reuses the buddy page indefinitely
instead of allocating a PISA page.  Conversely, if x->xfrag holds a PISA
page and pisa_tx_bufs is later disabled on the egress device,
!(gfp & __GFP_PISA_RO) skips pisa_page_can_recycle() and keeps recycling
and pinning the 2MB PISA frame at refcount 1.

> @@ -3289,6 +3297,39 @@ bool skb_page_frag_refill(unsigned int sz, struct page_frag *pfrag, gfp_t gfp)
>  }
>  EXPORT_SYMBOL(skb_page_frag_refill);
>  
> +/**
> + * skb_page_frag_refill_dev - GFP_ATOMIC skb_page_frag_refill() for @skb TX
> + * @sz: minimum size of the fragment we want to get
> + * @pfrag: pointer to page_frag, private to the caller
> + * @skb: packet being transmitted
> + *
> + * Pages come from the per-node DMA_TO_DEVICE PISA allocators when they are
> + * useful for @skb's egress device (__netdev_tx_pisa_ok()), otherwise from the
> + * buddy allocator. PISA pages are readable by every device that maps them
> + * while they stay active, so @pfrag must only ever hold data meant for devices,
> + * e.g. ciphertext; it may mix PISA and ordinary pages.
> + */
> +bool skb_page_frag_refill_dev(unsigned int sz, struct page_frag *pfrag,
> +			      const struct sk_buff *skb)
> +{
> +	gfp_t gfp = GFP_ATOMIC;
> +
> +	/*
> +	 * Before ip_finish_output2() populates skb->dev (e.g. esp_output),
> +	 * the egress device is carried by skb_dst(skb).
> +	 */
> +	if (net_pisa_tx_bufs_enabled()) {
> +		const struct dst_entry *dst = skb_dst(skb);
> +
> +		rcu_read_lock();
> +		if (__netdev_tx_pisa_ok(skb->dev ?: (dst ? dst_dev_rcu(dst) : NULL)))
> +			gfp |= __GFP_PISA_RO;
> +		rcu_read_unlock();
> +	}
> +	return skb_page_frag_refill(sz, pfrag, gfp);
> +}
> +EXPORT_SYMBOL(skb_page_frag_refill_dev);

[Severity: Medium]
On forwarded packets entering esp_output() or esp6_output(), doesn't
skb->dev still point to the ingress device?

In ip_forward() -> xfrm4_output() -> esp_output() (and the IPv6 equivalent),
skb->dev is not updated to the egress device until ip_output() runs after
xfrm_output() finishes.  Preferring skb->dev over dst_dev_rcu(dst) checks
pisa_tx_bufs on the ingress interface instead of the egress interface for
all forwarded ESP traffic.

> diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
> index 3396f177a18d0..a5ea530bc8b5b 100644
> --- a/net/ipv4/ip_output.c
> +++ b/net/ipv4/ip_output.c
> @@ -986,7 +986,10 @@ static int __ip_append_data(struct sock *sk,
>  
>  	exthdrlen = !skb ? rt->dst.header_len : 0;
>  	mtu = cork->gso_size ? IP_MAX_MTU : cork->fragsize;
> -	paged = !!cork->gso_size;
> +	paged = !!cork->gso_size ||
> +		(sk->sk_type != SOCK_RAW &&
> +		 (rt->dst.dev->features & NETIF_F_SG) &&
> +		 is_pisa_pfrag(pfrag));

[Severity: Medium]
Can setting paged = true for all sk->sk_type != SOCK_RAW sockets corrupt
IPv4 ICMP checksums on SOCK_DGRAM ping sockets?

IPv4 ping sockets have sk->sk_type == SOCK_DGRAM and use ping_getfrag():

net/ipv4/ping.c:ping_getfrag() {
	if (!csum_and_copy_from_iter_full(to, fraglen, &pfh->wcheck,
					  &pfh->msg->msg_iter))
		return -EFAULT;

#if IS_ENABLED(CONFIG_IPV6)
	if (pfh->family == AF_INET6) {
		skb->csum = csum_block_add(skb->csum, pfh->wcheck, odd);
		skb->ip_summed = CHECKSUM_NONE;
		pfh->wcheck = 0;
	}
#endif
	return 0;
}

When paged is true and a ping payload crosses the end of
current->task_frag_pisa.page starting from an odd pfrag->offset, the first
chunk has an odd length (pfrag->size - pfrag->offset) and the second
ping_getfrag() call starts at an odd packet offset.  Because the AF_INET
path accumulates directly into pfh->wcheck with progress = 0 and ignores
odd, the second chunk's bytes are added with inverted byte lane alignment,
producing an invalid ICMPv4 checksum.

[ ... ]

> @@ -1592,7 +1595,7 @@ struct sk_buff *ip_make_skb(struct sock *sk,
>  		return ERR_PTR(err);
>  
>  	err = __ip_append_data(sk, fl4, &queue, cork,
> -			       &current->task_frag, getfrag,
> +			       task_page_frag(cork->dst), getfrag,
>  			       from, length, transhdrlen, flags);
>  	if (err) {
>  		__ip_flush_pending_frames(sk, &queue, cork);

[Severity: High]
Can ip_make_skb() and ip6_make_skb() re-enter current->task_frag_pisa and
cause a use-after-free when a socket has sk_use_task_frag == false?

In-kernel sockets that transmit during memory reclaim or page faults (such
as SUNRPC/NFS over UDP, which sets sk->sk_use_task_frag = false in
xs_udp_finish_connecting()) call ip_make_skb() and ip6_make_skb().  Before
this patch, non-GSO sends in __ip_append_data() and __ip6_append_data() had
paged = false, so normal RPC datagrams never used pfrag.  Now ip_make_skb()
and ip6_make_skb() pass task_page_frag() without checking
sk->sk_use_task_frag, and __ip_append_data() / __ip6_append_data() force
paged = true when is_pisa_pfrag(pfrag) is true:

tcp_sendmsg_locked()
  pfrag = sk_page_frag_dst(sk, dst)  /* &current->task_frag_pisa */
  sk_page_frag_refill(sk, pfrag)
  skb_copy_to_page_nocache(..., pfrag->page, pfrag->offset, copy)
    <page fault on user buffer / direct reclaim>
      xs_udp_send_request()          /* sk->sk_use_task_frag == false */
        ip_make_skb()
          __ip_append_data(..., task_page_frag(cork->dst), ...)
            skb_page_frag_refill(..., pfrag, ...)
              put_page(pfrag->page)  /* frees outer page at refcount 1 */
  /* writes to freed pfrag->page, or corrupts pfrag->offset */

Passing sk_page_frag_dst(sk, ...) in ip_make_skb() and ip6_make_skb() would
respect sk->sk_use_task_frag and use &sk->sk_frag instead.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261109182533.3594984-1-lrizzo@google.com?part=12


  reply	other threads:[~2026-11-10 23:50 UTC|newest]

Thread overview: 108+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-03 21:22 [RFC: DMA_PMD 00/22] DMA_PMD: PMD_SIZE-backed IO buffer pools Luigi Rizzo
2026-10-03 21:22 ` [RFC: DMA_PMD 01/22] iommu/dma: introduce CONFIG_DMA_PMD and metadata table Luigi Rizzo
2026-10-03 21:44   ` Randy Dunlap
2026-10-04  9:14     ` Luigi Rizzo
2026-10-03 21:22 ` [RFC: DMA_PMD 02/22] iommu/dma: add DMA_PMD pool lifecycle and page recycle hook Luigi Rizzo
2026-10-10  2:59   ` kernel test robot
2026-10-03 21:22 ` [RFC: DMA_PMD 03/22] mm: Add split_page_compound() Luigi Rizzo
2026-10-03 21:22 ` [RFC: DMA_PMD 04/22] iommu/dma: add DMA_PMD pool block allocation Luigi Rizzo
2026-10-03 21:22 ` [RFC: DMA_PMD 05/22] iommu/dma: Global cap and shrinker for DMA_PMD pool memory Luigi Rizzo
2026-10-03 21:22 ` [RFC: DMA_PMD 06/22] iommu/dma: reserve a per-domain IOVA window for DMA_PMD pages Luigi Rizzo
2026-10-03 21:22 ` [RFC: DMA_PMD 07/22] iommu/dma: release DMA_PMD domain mappings on domain teardown Luigi Rizzo
2026-10-03 21:22 ` [RFC: DMA_PMD 08/22] iommu/dma: use per-domain IOVA window to map DMA_PMD memory Luigi Rizzo
2026-10-03 21:22 ` [RFC: DMA_PMD 09/22] iommu/dma: Add DMA_PMD arena allocator Luigi Rizzo
2026-10-08 11:25   ` kernel test robot
2026-10-03 21:22 ` [RFC: DMA_PMD 10/22] driver core: Add per-device dma_pmd_* sysfs attributes Luigi Rizzo
2026-10-03 21:22 ` [RFC: DMA_PMD 11/22] dma-mapping: Use DMA_PMD arena for dma_alloc_attrs() Luigi Rizzo
2026-10-03 21:22 ` [RFC: DMA_PMD 12/22] net/core: Use per-CPU DMA_PMD pools for skb_page_frag_refill() Luigi Rizzo
2026-10-03 21:22 ` [RFC: DMA_PMD 13/22] net/core: Use DMA_PMD for page_pool memory Luigi Rizzo
2026-10-03 21:22 ` [RFC: DMA_PMD 14/22] iommu/dma: Support decrypted and pinned DMA_PMD pages Luigi Rizzo
2026-10-03 21:22 ` [RFC: DMA_PMD 15/22] iommu/dma: Add background page scrubber for DMA_PMD pools Luigi Rizzo
2026-10-03 21:22 ` [RFC: DMA_PMD 16/22] iommu/dma: Add per-NUMA-node PMD page reservoir Luigi Rizzo
2026-10-03 21:22 ` [RFC: DMA_PMD 17/22] net/gve: Use DMA_PMD memory for RX buffers Luigi Rizzo
2026-10-03 21:22 ` [RFC: DMA_PMD 18/22] net/gve: Use DMA_PMD memory for tx header bounce buffers Luigi Rizzo
2026-10-03 21:22 ` [RFC: DMA_PMD 19/22] net/mlx5e: " Luigi Rizzo
2026-10-14 17:22   ` Dragos Tatulea
2026-10-14 17:50     ` Dragos Tatulea
2026-10-14 18:28       ` Luigi Rizzo
2026-10-03 21:22 ` [RFC: DMA_PMD 20/22] net/idpf: " Luigi Rizzo
2026-10-03 21:22 ` [RFC: DMA_PMD 21/22] net/bnxt: " Luigi Rizzo
2026-10-03 21:22 ` [RFC: DMA_PMD 22/22] iommu/dma: Add DMA_PMD statistics and debugfs Luigi Rizzo
2026-10-11  9:02 ` [RFC: DMA_PMD 00/22] DMA_PMD: PMD_SIZE-backed IO buffer pools Pranjal Shrivastava
2026-10-12 13:51 ` David Hildenbrand (Arm)
2026-10-12 14:45   ` Luigi Rizzo
2026-10-12 19:43     ` David Hildenbrand (Arm)
2026-10-13 10:42       ` Robin Murphy
2026-10-14 10:47         ` David Hildenbrand (Arm)
2026-10-14 11:05           ` Luigi Rizzo
2026-10-17 17:11       ` Luigi Rizzo
2026-10-22 20:12         ` Jason Gunthorpe
2026-10-22 21:51           ` Luigi Rizzo
2026-10-23 14:01             ` Jason Gunthorpe
2026-10-23 14:30               ` Luigi Rizzo
2026-10-23 14:50                 ` Jason Gunthorpe
2026-10-23 15:12                   ` Luigi Rizzo
2026-10-23 17:27                   ` Jakub Kicinski
2026-10-23 20:22                     ` Luigi Rizzo
2026-11-03  8:09                   ` Christoph Hellwig
2026-11-03  9:13                     ` Luigi Rizzo
2026-11-03 15:10                     ` Jason Gunthorpe
2026-11-06 17:21                       ` Naman Gulati
2026-11-06 17:30                         ` Jason Gunthorpe
2026-11-06 18:00                           ` Naman Gulati
2026-11-06 18:07                             ` Jason Gunthorpe
2026-11-06 18:17                               ` Naman Gulati
2026-11-06 18:43                                 ` Jason Gunthorpe
2026-11-06 19:01                                   ` Luigi Rizzo
2026-11-06 19:11                                   ` Naman Gulati
2026-10-12 14:49   ` Mostafa Saleh
2026-10-12 15:02     ` Luigi Rizzo
2026-10-14 17:28 ` Dragos Tatulea
2026-10-14 18:14   ` Luigi Rizzo
2026-11-09 18:25 ` [RFC PATCH v2 00/25] PISA: Pre-mapped IOVA Superpage Allocator for DMA and CoCo Luigi Rizzo
2026-11-09 18:25 ` [RFC PATCH v2 01/25] iommu/dma: Introduce CONFIG_PISA and metadata table Luigi Rizzo
2026-11-10 23:12   ` sashiko-bot
2026-11-09 18:25 ` [RFC PATCH v2 02/25] iommu/dma: Add PISA allocator lifecycle and page recycle hook Luigi Rizzo
2026-11-09 18:25 ` [RFC PATCH v2 03/25] iommu/dma: Add per-NUMA-node PISA page reservoir Luigi Rizzo
2026-11-10 23:12   ` sashiko-bot
2026-11-09 18:25 ` [RFC PATCH v2 04/25] iommu/dma: Add PISA block allocation Luigi Rizzo
2026-11-10 23:12   ` sashiko-bot
2026-11-09 18:25 ` [RFC PATCH v2 05/25] iommu/dma: Add global cap and shrinker for PISA pages Luigi Rizzo
2026-11-09 18:25 ` [RFC PATCH v2 06/25] iommu/dma: Reserve a per-domain IOVA window " Luigi Rizzo
2026-11-09 18:25 ` [RFC PATCH v2 07/25] iommu/dma: Release PISA domain mappings on domain teardown Luigi Rizzo
2026-11-10 23:12   ` sashiko-bot
2026-11-09 18:25 ` [RFC PATCH v2 08/25] iommu/dma: Use per-domain IOVA window to map PISA memory Luigi Rizzo
2026-11-10 23:12   ` sashiko-bot
2026-11-09 18:25 ` [RFC PATCH v2 09/25] driver core: Add per-device pisa_* sysfs attributes for PISA optin Luigi Rizzo
2026-11-10 23:12   ` sashiko-bot
2026-11-09 18:25 ` [RFC PATCH v2 10/25] iommu/dma: Use PISA for coherent DMA allocations Luigi Rizzo
2026-11-10 23:12   ` sashiko-bot
2026-11-09 18:25 ` [RFC PATCH v2 11/25] iommu/dma: Add per-CPU block caches to PISA allocators Luigi Rizzo
2026-11-10 23:12   ` sashiko-bot
2026-11-09 18:25 ` [RFC PATCH v2 12/25] net/core: Use per-node PISA allocators for skb_page_frag_refill() Luigi Rizzo
2026-11-10 23:50   ` sashiko-bot [this message]
2026-11-09 18:25 ` [RFC PATCH v2 13/25] net/core: Use PISA for page_pool memory Luigi Rizzo
2026-11-09 18:25 ` [RFC PATCH v2 14/25] iommu/dma: Support decrypted PISA pages Luigi Rizzo
2026-11-11  0:19   ` sashiko-bot
2026-11-09 18:25 ` [RFC PATCH v2 15/25] iommu/dma: Add background page scrubber for PISA allocators Luigi Rizzo
2026-11-11  0:37   ` sashiko-bot
2026-11-09 18:25 ` [RFC PATCH v2 16/25] mm/slub: Add SLAB_CACHE_PISA_RO for PISA-backed slab caches Luigi Rizzo
2026-11-11  1:03   ` sashiko-bot
2026-11-09 18:25 ` [RFC PATCH v2 17/25] net: Allocate small skb heads from PISA Luigi Rizzo
2026-11-11  1:33   ` sashiko-bot
2026-11-09 18:25 ` [RFC PATCH v2 18/25] iommu/dma: Migrate user pages into PISA for TX zerocopy Luigi Rizzo
2026-11-11  2:41   ` sashiko-bot
2026-11-09 18:25 ` [RFC PATCH v2 19/25] iommu/dma: Stop recycling old PISA pages when allocator waste is high Luigi Rizzo
2026-11-11  2:57   ` sashiko-bot
2026-11-09 18:25 ` [RFC PATCH v2 20/25] net/libeth: Use GFP_KERNEL when pre-filling RX rings Luigi Rizzo
2026-11-11  3:13   ` sashiko-bot
2026-11-09 18:25 ` [RFC PATCH v2 21/25] net/gve: " Luigi Rizzo
2026-11-11  3:22   ` sashiko-bot
2026-11-09 18:25 ` [RFC PATCH v2 22/25] net/gve: Use PISA memory for RX buffers Luigi Rizzo
2026-11-11  3:43   ` sashiko-bot
2026-11-09 18:25 ` [RFC PATCH v2 23/25] block, mm, iommu/dma: Support PISA for disk I/O and scrub migration Luigi Rizzo
2026-11-11  4:16   ` sashiko-bot
2026-11-09 18:25 ` [RFC PATCH v2 24/25] Documentation: Add PISA architecture documentation Luigi Rizzo
2026-11-11  4:24   ` sashiko-bot
2026-11-09 18:25 ` [RFC PATCH v2 25/25] iommu/dma: Add PISA statistics and debugfs Luigi Rizzo
2026-11-11  4:37   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-207955@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=aleksander.lobakin@intel.com \
    --cc=axboe@kernel.dk \
    --cc=corbet@lwn.net \
    --cc=dakr@kernel.org \
    --cc=davem@davemloft.net \
    --cc=david@kernel.org \
    --cc=edumazet@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hawk@kernel.org \
    --cc=hch@lst.de \
    --cc=hramamurthy@google.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=joro@8bytes.org \
    --cc=joshwash@google.com \
    --cc=kuba@kernel.org \
    --cc=kuniyu@google.com \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=lrizzo@google.com \
    --cc=m.szyprowski@samsung.com \
    --cc=pabeni@redhat.com \
    --cc=rafael@kernel.org \
    --cc=rizzo.unipi@gmail.com \
    --cc=robin.murphy@arm.com \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vbabka@kernel.org \
    --cc=will@kernel.org \
    --cc=willemb@google.com \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.