Linux-mm Archive on 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: 107+ 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-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox