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