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
next prev parent reply other threads:[~2026-11-10 23:12 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 [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 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.