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 10/25] iommu/dma: Use PISA for coherent DMA allocations
Date: Tue, 10 Nov 2026 23:12:15 +0000	[thread overview]
Message-ID: <sashiko-outbox-207865@kernel.org> (raw)
In-Reply-To: <20261109182533.3594984-11-lrizzo@google.com>

Thank you for your contribution! Sashiko AI review found 4 potential
issues to consider:
- [Medium] iommu/pisa: unsafe list_for_each_entry() in
  pisa_alloc_coherent()
- [Medium] iommu/pisa: NULL deref in is_swiotlb_for_alloc() in KUnit
  test
- [Medium] iommu/dma: incomplete DMA range check in
  pisa_alloc_coherent()
- [Low] iommu/dma: uninitialized stack device in
  test_coherent_alloc_and_free()
--

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

iommu/dma: Use PISA for coherent DMA allocations

This commit serves coherent DMA allocations up to 2MB from the per-NUMA-node
order-0 read-write PISA allocator when dev->pisa_coherent is enabled.

> diff --git a/drivers/iommu/pisa-alloc.c b/drivers/iommu/pisa-alloc.c
> index b0d968aa9181c..25e4645310678 100644
> --- a/drivers/iommu/pisa-alloc.c
> +++ b/drivers/iommu/pisa-alloc.c
> @@ -10,6 +10,8 @@
>  #include <linux/bitops.h>
>  #include <linux/cache.h>
>  #include <linux/device.h>
> +#include <linux/dma-direct.h>
> +#include <linux/dma-map-ops.h>
>  #include <linux/dma-mapping.h>
>  #include <linux/pisa.h>
>  #include <linux/export.h>
> @@ -697,6 +699,150 @@ unsigned long pisa_alloc_bulk(struct pisa_alloc *pa, gfp_t gfp,
>  	return i;
>  }
>  
> +/* Find and reserve @nblocks aligned contiguous blocks in @meta under @pa->lock. */
> +static struct page *pisa_take_contig(struct pisa_meta *meta, unsigned int nblocks,
> +				     unsigned long align_mask)
> +{
> +	DECLARE_BITMAP(busy, PISA_MAX_BLOCKS);
> +	struct pisa_alloc *pa = meta->pa;
> +	unsigned int bpp = PISA_BLOCKS(0), i;
> +	bool poisoned = false;
> +	unsigned long off;
> +	struct page *page;
> +
> +	if (pisa_meta_avail(meta) < nblocks)
> +		return NULL;
> +
> +	bitmap_or(busy, meta->clean_bitmap, meta->dirty_bitmap, bpp);
> +	bitmap_complement(busy, busy, bpp);
> +
> +	off = 0;
> +	for (;;) {
> +		off = bitmap_find_next_zero_area(busy, bpp, off, nblocks, align_mask);
> +		if (off >= bpp) {
> +			if (poisoned) {
> +				if (meta->on_list == PISA_LIST_IDLE_CLEAN ||
> +				    meta->on_list == PISA_LIST_IDLE_DIRTY)
> +					pa->num_idle_pages--;
> +				pisa_place_meta(meta);
> +			}
> +			return NULL;
> +		}
> +
> +		page = pfn_to_page(pisa_meta_to_pfn(meta) + off);
> +		for (i = 0; i < nblocks; i++) {
> +			if (!pisa_block_poisoned(pa, page + i))
> +				continue;
> +			if (__test_and_clear_bit(off + i, meta->clean_bitmap))
> +				meta->nr_clean--;
> +			else if (__test_and_clear_bit(off + i, meta->dirty_bitmap))
> +				meta->nr_dirty--;
> +			__set_bit(off + i, busy);
> +			poisoned = true;
> +			off += i + 1;
> +			break;
> +		}
> +		if (i == nblocks)
> +			break;
> +	}

[ ... ]

> +void *pisa_alloc_coherent(struct page **pagep, struct device *dev,
> +			  struct iommu_domain *domain, size_t size,
> +			  gfp_t gfp, unsigned long attrs)
> +{
> +	bool should_release = false;
> +	struct list_head *lists[3];
> +	unsigned long align_mask, flags;
> +	unsigned int nblocks, i;
> +	struct pisa_meta *meta;
> +	struct pisa_alloc *pa;
> +	struct page *page = NULL;
> +
> +	size = PAGE_ALIGN(size);
> +	if (!pagep || !dev || !READ_ONCE(dev->pisa_coherent) ||
> +	    !dev_is_dma_coherent(dev) || !size || size > PISA_SIZE)
> +		return NULL;
> +	if (min_not_zero(dev->coherent_dma_mask, dev->bus_dma_limit) <= DMA_BIT_MASK(32))
> +		return NULL;
> +	if ((current_gfp_context(gfp) & ~(__GFP_ZERO | __GFP_NOWARN)) != GFP_KERNEL ||
> +	    (attrs & ~DMA_ATTR_NO_WARN))
> +		return NULL;
> +
> +	if (domain) {
> +		struct pisa_window *win = pisa_dma_window(domain);
> +
> +		if (!win || pisa_window_declined(win) || !(domain->pgsize_bitmap & PISA_SIZE))
> +			return NULL;
> +	} else if (is_swiotlb_for_alloc(dev) ||
> +		   force_dma_unencrypted(dev) ||
> +		   !dma_coherent_ok(dev, PFN_PHYS(max_pfn) - 1, 1)) {
> +		return NULL;
> +	}
> +
> +	pa = pisa_node_pa(dev_to_node(dev), 0, false);
> +	if (!pa)
> +		return NULL;
> +
> +	nblocks = size >> PAGE_SHIFT;
> +	align_mask = (1UL << get_order(size)) - 1;
> +	lists[0] = &pa->partial;
> +	lists[1] = &pa->partial_dirty;
> +	lists[2] = &pa->idle;
> +
> +	spin_lock_irqsave(&pa->lock, flags);
> +	for (i = 0; i < ARRAY_SIZE(lists) && !page; i++) {
> +		list_for_each_entry(meta, lists[i], list) {
> +			page = pisa_take_contig(meta, nblocks, align_mask);
> +			if (page)
> +				break;
> +		}
> +	}

[Severity: Medium]
Can list_for_each_entry() walk off lists[i] onto a different list when
pisa_take_contig() encounters a poisoned block?

If pisa_take_contig() clears a poisoned block in meta and then fails to
find nblocks contiguous blocks (off >= bpp), it calls pisa_place_meta(meta)
before returning NULL.  pisa_place_meta() can move meta->list to another
list (for example from pa->idle to pa->partial, or from pa->partial to
pa->partial_dirty or pa->full).  Because pisa_take_contig() returns NULL,
list_for_each_entry() does not break; it follows meta->list.next on the new
list while testing for termination against lists[i], and then treats the
new list's head embedded in struct pisa_alloc as a struct pisa_meta.  Using
list_for_each_entry_safe() avoids following relinked nodes.

[ ... ]

> diff --git a/drivers/iommu/pisa-kunit.c b/drivers/iommu/pisa-kunit.c
> index ab64657ad5c58..72ee8986b4802 100644
> --- a/drivers/iommu/pisa-kunit.c
> +++ b/drivers/iommu/pisa-kunit.c
> @@ -352,6 +352,72 @@ static void test_map_and_domain_lifecycle(struct kunit *test)
>  }
>  #endif /* CONFIG_IOMMU_DMA */
>  
> +static void test_coherent_alloc_and_free(struct kunit *test)
> +{
> +	struct device dev = { .init_name = "pisa_kunit", .numa_node = NUMA_NO_NODE,
> +			      .coherent_dma_mask = DMA_BIT_MASK(64),
> +			      .pisa_coherent = true };

[Severity: Medium]
Does passing this stack-allocated struct device with a NULL domain to
pisa_alloc_coherent() cause a NULL pointer dereference when
CONFIG_DMA_RESTRICTED_POOL is enabled?

Because dev is neither initialized via device_initialize() nor
swiotlb_dev_init(), dev.dma_io_tlb_mem is NULL.  When
test_coherent_alloc_and_free() later calls pisa_alloc_coherent() with
domain == NULL, pisa_alloc_coherent() calls is_swiotlb_for_alloc(dev),
which dereferences dev->dma_io_tlb_mem->for_alloc under
CONFIG_DMA_RESTRICTED_POOL=y.

[ ... ]

> +	/* Freeing p1 returns its 16 order-0 pages; next 64K alloc reuses them. */
> +	KUNIT_EXPECT_TRUE(test, pisa_free_coherent(p1, SZ_64K));
> +	v3 = pisa_alloc_coherent(&p3, &dev, NULL, SZ_64K, GFP_KERNEL, 0);
> +	KUNIT_ASSERT_NOT_NULL(test, v3);
> +	KUNIT_EXPECT_PTR_EQ(test, p3, p1);
> +
> +	KUNIT_EXPECT_TRUE(test, pisa_free_coherent(p2, SZ_64K));
> +	KUNIT_EXPECT_TRUE(test, pisa_free_coherent(p3, SZ_64K));
> +}

[Severity: Low]
In addition to the uninitialized dev.dma_io_tlb_mem above, does this call
with domain == NULL fail the test and leak p2 on Confidential Computing
guests?

When domain is NULL, pisa_alloc_coherent() rejects the allocation if
force_dma_unencrypted(&dev) is true, so v3 is NULL and
KUNIT_ASSERT_NOT_NULL(test, v3) aborts before pisa_free_coherent(p2, SZ_64K)
runs (until commit "iommu/dma: Support decrypted PISA pages" later in the
series).

[ ... ]

> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 25e9a86835fd3..11052b65e573b 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -244,6 +245,12 @@ void *dma_direct_alloc(struct device *dev, size_t size,
>  	if (attrs & DMA_ATTR_NO_WARN)
>  		gfp |= __GFP_NOWARN;
>  
> +	cpu_addr = pisa_alloc_coherent(&page, dev, NULL, size, gfp, attrs);
> +	if (cpu_addr) {
> +		*dma_handle = phys_to_dma_direct(dev, page_to_phys(page), false);
> +		return cpu_addr;
> +	}

[Severity: Medium]
Can dma_direct_alloc() return a valid cpu_addr with *dma_handle set to
DMA_MAPPING_ERROR (or an out-of-mask DMA address) when dev->dma_range_map
does not cover all of system RAM?

pisa_alloc_coherent() only checks dma_coherent_ok(dev, PFN_PHYS(max_pfn) - 1, 1)
before allocating, and dma_direct_alloc() does not check
dma_coherent_ok(dev, page_to_phys(page), size) on the allocated page.  If
dev->dma_range_map covers the top of RAM at max_pfn - 1 but has holes in
lower RAM (where !dma_direct_all_ram_mapped(dev) is true, as in
a409d9600959 ("dma-mapping: fix dma_addressing_limited() if dma_range_map
can't cover all system RAM")) or translates regions with different offsets,
pisa_alloc_coherent() can return a page outside dev->dma_range_map and
phys_to_dma_direct() will set *dma_handle to DMA_MAPPING_ERROR.

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


  reply	other threads:[~2026-11-10 23:12 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 [this message]
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
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-207865@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