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 18/25] iommu/dma: Migrate user pages into PISA for TX zerocopy
Date: Wed, 11 Nov 2026 02:41:47 +0000	[thread overview]
Message-ID: <sashiko-outbox-208107@kernel.org> (raw)
In-Reply-To: <20261109182533.3594984-19-lrizzo@google.com>

Thank you for your contribution! Sashiko AI review found 5 potential
issues to consider:
- [High] iommu/pisa: unkillable PAGE_SIZE walk under mmap_read_lock in
  pisa_madvise()
- [High] mm/madvise: missing MADV_PISA definitions on alpha, mips,
  parisc, and xtensa
- [Medium] iommu/pisa: alloc_tag corruption via pgalloc_tag_swap() in
  pisa_user_migrate()
- [Medium] iommu/pisa: pisa_user_max_4k_pages not restored on error in
  pisa_user_max_set()
- [Medium] net: pisa_zc_iter() migrates user pages before checking
  dst_tx_pisa_ok()
--

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

iommu/dma: Migrate user pages into PISA for TX zerocopy

This commit adds support for migrating private anonymous order-0 user pages
into per-node PISA allocators via madvise(MADV_PISA / MADV_NOPISA) and
automatically during MSG_ZEROCOPY transmissions.

> diff --git a/drivers/iommu/pisa-user.c b/drivers/iommu/pisa-user.c
> new file mode 100644
> index 0000000000000..a16909d429aca
> --- /dev/null
> +++ b/drivers/iommu/pisa-user.c
> @@ -0,0 +1,278 @@

[ ... ]

> +static int pisa_user_max_set(const char *val, const struct kernel_param *kp)
> +{
> +	unsigned long max_pages;
> +	int ret;
> +
> +	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
> +		return -EOPNOTSUPP;
> +	ret = kstrtoul(val, 0, &max_pages);
> +	if (ret)
> +		return ret;
> +	WRITE_ONCE(pisa_user_max_4k_pages, max_pages);
> +	if (max_pages) {
> +		if (!pisa_nodes[first_memory_node].pa[0][0])
> +			return 0;
> +		if (!pisa_user_init())
> +			return -ENOMEM;
> +		static_branch_enable(&pisa_user_key);
> +	} else {
> +		static_branch_disable(&pisa_user_key);
> +	}
> +	return 0;
> +}

[Severity: Medium]
Does this leave pisa_user_max_4k_pages updated if pisa_user_init() fails and
returns -ENOMEM?  Sysfs will report the new non-zero limit after the write
failed, and a later madvise(MADV_PISA) call can then succeed in
pisa_user_init() while pisa_user_key remains disabled.

[ ... ]

> +/* new_folio_t for migration into PISA memory. */
> +static struct folio *pisa_user_new_folio(struct folio *src, unsigned long private)
> +{
> +	struct pisa_user_mtc *mtc = (void *)private;
> +	int nid = folio_nid(src);
> +	struct page *page;
> +
> +	if (mtc->budget <= 0)
> +		return NULL;
> +	page = pisa_alloc(pisa_nodes[nid].user_pa, mtc->gfp);
> +	if (!page)
> +		return NULL;
> +	if (pisa_meta_of_pfn(page_to_pfn(page))->flags & PISA_DECRYPTED) {
> +		put_page(page);
> +		mtc->budget = 0;
> +		return NULL;
> +	}
> +	mtc->budget--;
> +	return page_folio(page);
> +}
> +
> +/* new_folio_t for migration out of PISA memory: allocators never serve these. */
> +static struct folio *pisa_user_old_folio(struct folio *src, unsigned long private)
> +{
> +	return __folio_alloc_node(GFP_HIGHUSER_MOVABLE | __GFP_NOWARN, 0, folio_nid(src));
> +}
> +
> +/* Migrate the isolated folios on @list; failures are put back. */
> +static void pisa_user_migrate(struct list_head *list, bool to_pisa, gfp_t gfp)
> +{
> +	struct pisa_user_mtc mtc = { .gfp = gfp, .budget = LONG_MAX };
> +	enum migrate_mode mode = MIGRATE_SYNC;
> +
> +	if (list_empty(list))
> +		return;
> +	if (to_pisa) {
> +		mtc.budget = pisa_user_budget();
> +		if (!gfpflags_allow_blocking(gfp))
> +			mode = MIGRATE_ASYNC;
> +	}
> +	if (migrate_pages(list, to_pisa ? pisa_user_new_folio : pisa_user_old_folio,
> +			  NULL, (unsigned long)&mtc, mode, MR_SYSCALL, NULL))
> +		putback_movable_pages(list);
> +}

[Severity: Medium]
Does migrate_pages() corrupt page allocation profiling counters when
CONFIG_MEM_ALLOC_PROFILING is enabled?

When a 2MB PISA page is allocated in __pisa_page_alloc() and split in
split_page_compound(), pgalloc_tag_split() assigns __pisa_page_alloc()'s
alloc_tag to all 512 blocks, and __pisa_free_page() recycles individual
blocks without calling pgalloc_tag_sub().  However, migrate_pages() calls
folio_migrate_flags() -> pgalloc_tag_swap(dst, src).  Migrating a user folio
into a PISA block swaps __pisa_page_alloc()'s tag onto the old buddy folio
(which is immediately freed, decrementing __pisa_page_alloc()'s tag while
the PISA block is still allocated) and places the user folio's tag onto the
PISA block, where it is never decremented when __pisa_free_page() recycles
the block.  Migrating out via MADV_NOPISA similarly leaves
pisa_user_old_folio()'s tag stranded on the recycled PISA block.

[ ... ]

> +int pisa_madvise(struct vm_area_struct *vma, unsigned long start, unsigned long end, bool to_pisa)
> +{
> +	gfp_t gfp = GFP_USER | __GFP_NOWARN;
> +	struct folio_walk fw;
> +	unsigned long addr;
> +	unsigned int n = 0;
> +	LIST_HEAD(list);
> +
> +	if (vma->vm_flags & (VM_SHARED | VM_IO | VM_PFNMAP | VM_HUGETLB))
> +		return -EINVAL;
> +	if (to_pisa && !pisa_user_init())
> +		return -EOPNOTSUPP;
> +	lru_add_drain();
> +	for (addr = start; addr < end; addr += PAGE_SIZE) {
> +		struct folio *folio = folio_walk_start(&fw, vma, addr, 0);
> +
> +		if (folio) {
> +			if (pisa_user_want(folio, to_pisa) && !pisa_user_busy(folio, 0) &&
> +			    isolate_folio_to_list(folio, &list))
> +				n++;
> +			folio_walk_end(&fw, vma);
> +		}
> +		if (n == PISA_USER_BATCH) {
> +			pisa_user_migrate(&list, to_pisa, gfp);
> +			n = 0;
> +		}
> +		cond_resched();
> +	}
> +	pisa_user_migrate(&list, to_pisa, gfp);
> +	return 0;
> +}

[Severity: High]
Can an unprivileged user stall a task in an unkillable loop holding
mmap_read_lock by calling madvise(MADV_NOPISA) or madvise(MADV_PISA) on a
multi-terabyte unpopulated anonymous mapping?

Unlike walk_page_range_vma(), which skips empty PGD, P4D, PUD, and PMD
entries at once, this loop steps by PAGE_SIZE across the entire [start, end)
range and calls folio_walk_start() on every 4KB address without checking
fatal_signal_pending(), and MADV_NOPISA reaches it even when
pisa.user_max_4K_pages is 0.  Using walk_page_range_vma() or checking
pisa_user_enabled() and fatal_signal_pending() would avoid walking empty
page table levels and allow SIGKILL to abort the walk.

> diff --git a/include/uapi/asm-generic/mman-common.h b/include/uapi/asm-generic/mman-common.h
> index ef1c27fa3c570..c4332db8e56ff 100644
> --- a/include/uapi/asm-generic/mman-common.h
> +++ b/include/uapi/asm-generic/mman-common.h
> @@ -81,6 +81,8 @@
>  
>  #define MADV_GUARD_INSTALL 102		/* fatal signal on access to range */
>  #define MADV_GUARD_REMOVE 103		/* unguard range */
> +#define MADV_PISA		210	/* move pages into PISA memory */
> +#define MADV_NOPISA		211	/* move pages out of PISA memory */

[Severity: High]
Does mm/madvise.c fail to build on alpha, mips, parisc, and xtensa?

Those four architectures do not include asm-generic/mman-common.h in their
arch/*/include/uapi/asm/mman.h headers, while mm/madvise.c references
MADV_PISA and MADV_NOPISA unconditionally.

> diff --git a/net/core/datagram.c b/net/core/datagram.c
> index ecc30a6f83023..40f20d0faa859 100644
> --- a/net/core/datagram.c
> +++ b/net/core/datagram.c

[ ... ]

> +static bool pisa_zc_iter(int *ret, struct sk_buff *skb, struct iov_iter *from, size_t *length,
> +			 const struct sock *sk, struct page **pages, int max_pages,
> +			 unsigned int orig_len, size_t *start, ssize_t *copied)
> +{
> +	unsigned int i, nr;
> +	ssize_t keep;
> +
> +	if (!pisa_user_enabled() || !user_backed_iter(from))
> +		return false;
> +
> +	/* Move user pages into PISA memory, then look them up again. */
> +	if (pisa_upgrade_user_pages(pages, DIV_ROUND_UP(*start + *copied, PAGE_SIZE))) {
> +		iov_iter_revert(from, *copied);
> +		*copied = iov_iter_get_pages2(from, pages, *length, max_pages, start);
> +		if (*copied < 0) {
> +			*ret = -EFAULT;
> +			return true;
> +		}
> +	}
> +
> +	/* Only TCP (which sets skb->sk at transmit time) handles short appends/-EXDEV. */
> +	if (!sk || skb->sk)
> +		return false;
> +
> +	/* Only plain MSG_ZEROCOPY ubufs (not io_uring/vhost/devmem). */
> +	if (skb_zcopy(skb) && skb_zcopy(skb)->ops != &msg_zerocopy_ubuf_ops)
> +		return false;
> +
> +	/* Egress device must have pisa_tx_bufs enabled so the copy uses a PISA page_frag. */
> +	if (!dst_tx_pisa_ok(__sk_dst_get(sk)))
> +		return false;

[Severity: Medium]
Should pisa_zc_iter() check sk and dst_tx_pisa_ok(__sk_dst_get(sk)) before
calling pisa_upgrade_user_pages()?

Calling pisa_upgrade_user_pages() first migrates user pages into PISA even
when the egress device has pisa_tx_bufs disabled, when sending over
loopback or virtual devices, or when the socket is routed over IPsec
(where __dst_tx_pisa_ok() excludes dst_xfrm(dst) to keep plaintext out of
shared 2MB PISA pages).  Because __iommu_dma_map() checks is_pisa_phys()
rather than dev->pisa_tx_bufs, migrating pages on a device with
pisa_tx_bufs disabled also causes pisa_map_phys() to install 2MB PISA IOMMU
mappings on that device.

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


  reply	other threads:[~2026-11-11  2:41 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
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 [this message]
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-208107@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