From: sashiko-bot@kernel.org
To: "Mina Almasry" <almasrymina@google.com>,
virtualization@lists.linux.dev, linux-mm@kvack.org,
bpf@vger.kernel.org, bcm-kernel-feedback-list@broadcom.com,
imx@lists.linux.dev, linux-rdma@vger.kernel.org,
linux-hyperv@vger.kernel.org
Cc: "David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@kernel.org>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Simon Horman" <horms@kernel.org>,
"Steffen Klassert" <steffen.klassert@secunet.com>,
"Herbert Xu" <herbert@gondor.apana.org.au>,
"Willem de Bruijn" <willemb@google.com>,
"Stanislav Fomichev" <sdf@fomichev.me>,
"Pavel Begunkov" <asml.silence@gmail.com>,
"Bobby Eshleman" <bobbyeshleman@meta.com>,
"Andrew Lunn" <andrew+netdev@lunn.ch>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Jason Wang" <jasowangio@gmail.com>,
"Eugenio Pérez" <eperezma@redhat.com>,
"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"David Hildenbrand" <david@kernel.org>,
"Lorenzo Stoakes" <ljs@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
"Vlastimil Babka" <vbabka@kernel.org>,
"Mike Rapoport" <rppt@kernel.org>,
"Suren Baghdasaryan" <surenb@google.com>,
"Michal Hocko" <mhocko@suse.com>,
"Jesper Dangaard Brouer" <hawk@kernel.org>,
"Ilias Apalodimas" <ilias.apalodimas@linaro.org>,
"Alexei Starovoitov" <ast@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"John Fastabend" <john.fastabend@gmail.com>,
"Sabrina Dubroca" <sd@queasysnail.net>,
"Johannes Berg" <johannes@sipsolutions.net>,
"Byungchul Park" <byungchul@sk.com>,
"Jonathan Corbet" <corbet@lwn.net>,
"Shuah Khan" <skhan@linuxfoundation.org>,
"Randy Dunlap" <rdunlap@infradead.org>,
"Lorenzo Bianconi" <lorenzo@kernel.org>,
"Wen Gu" <guwen@linux.alibaba.com>,
"Philo Lu" <lulie@linux.alibaba.com>,
"Justin Chen" <justin.chen@broadcom.com>,
"Florian Fainelli" <florian.fainelli@broadcom.com>,
"Vikas Gupta" <vikas.gupta@broadcom.com>,
"Michael Chan" <michael.chan@broadcom.com>,
"Pavan Chebbi" <pavan.chebbi@broadcom.com>,
"Doug Berger" <opendmb@gmail.com>,
"Nicolai Buchwitz" <nb@tipi-net.de>,
"Satish Kharat" <satishkh@cisco.com>,
"Wei Fang" <wei.fang@nxp.com>, "Frank Li" <frank.li@nxp.com>,
"Shenwei Wang" <shenwei.wang@nxp.com>,
"Joshua Washington" <joshwash@google.com>,
"Harshitha Ramamurthy" <hramamurthy@google.com>,
"Jijie Shao" <shaojijie@huawei.com>,
"Jian Shen" <shenjian15@huawei.com>,
"Fan Gong" <gongfan1@huawei.com>,
"Tony Nguyen" <anthony.l.nguyen@intel.com>,
"Przemek Kitszel" <przemyslaw.kitszel@intel.com>,
"Marcin Wojtas" <marcin.s.wojtas@gmail.com>,
"Russell King" <linux@armlinux.org.uk>,
"Sunil Goutham" <sgoutham@marvell.com>,
"Geetha sowjanya" <gakula@marvell.com>,
"Ratheesh Kannoth" <rkannoth@marvell.com>,
"Subbaraya Sundeep" <sbhatta@marvell.com>,
"Bharat Bhushan" <bbhushan2@marvell.com>,
"Felix Fietkau" <nbd@nbd.name>,
"Matthias Brugger" <matthias.bgg@gmail.com>,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
"Tariq Toukan" <tariqt@nvidia.com>,
"Saeed Mahameed" <saeedm@nvidia.com>,
"Mark Bloch" <mbloch@nvidia.com>,
"Leon Romanovsky" <leon@kernel.org>,
"Ido Schimmel" <idosch@nvidia.com>,
"Petr Machata" <petrm@nvidia.com>,
"Horatiu Vultur" <horatiu.vultur@microchip.com>,
UNGLinuxDriver@microchip.com,
"Daniel Machon" <daniel.machon@microchip.com>,
"Steen Hegelund" <Steen.Hegelund@microchip.com>,
"Haiyang Zhang" <haiyangz@microsoft.com>,
"Wei Liu" <wei.liu@kernel.org>,
"Dexuan Cui" <decui@microsoft.com>,
"Yibo Dong" <dong100@mucse.com>,
"Brett Creeley" <brett.creeley@amd.com>,
"Justin Lai" <justinlai0215@realtek.com>,
"Larry Chiu" <larry.chiu@realtek.com>,
"Niklas Söderlund" <niklas.soderlund@ragnatech.se>,
"Paul Barker" <paul@pbarker.dev>,
"Masahisa Kojima" <kojima.masahisa@socionext.com>,
"Maxime Chevallier" <maxime.chevallier@bootlin.com>,
"Maxime Coquelin" <mcoquelin.stm32@gmail.com>,
"Alexandre Torgue" <alexandre.torgue@foss.st.com>,
"FUJITA Tomonori" <fujita.tomonori@gmail.com>,
"Siddharth Vadapalli" <s-vadapalli@ti.com>,
"Roger Quadros" <rogerq@kernel.org>,
"MD Danish Anwar" <danishanwar@ti.com>,
"Jiawen Wu" <jiawenwu@trustnetic.com>,
"Mengyuan Lou" <mengyuanlou@net-swift.com>,
"Ronak Doshi" <ronak.doshi@broadcom.com>,
"Ryder Lee" <ryder.lee@mediatek.com>,
"Shayne Chen" <shayne.chen@mediatek.com>,
"Sean Wang" <sean.wang@mediatek.com>,
"Juergen Gross" <jgross@suse.com>,
"Stefano Stabellini" <sstabellini@kernel.org>,
"Oleksandr Tyshchenko" <oleksandr_tyshchenko@epam.com>,
"Jordan Rhee" <jordanrhee@google.com>,
"Ankit Garg" <nktgrg@google.com>,
"Tim Hostetler" <thostet@google.com>,
"Erni Sri Satya Vennela" <ernis@linux.microsoft.com>,
"Eric Joyner" <eric.joyner@amd.com>,
"Mohammad Heib" <mheib@redhat.com>,
"Prabu Thayalan" <prabu.ponrajthayalan@amd.com>,
"Chintan Vankar" <c-vankar@ti.com>,
"Nora Schiffer" <nora.schiffer@ew.tq-group.com>,
"Alexander Sverdlin" <alex@sverdlin.org>,
"Kevin Hao" <haokexin@gmail.com>,
"Karl Mehltretter" <kmehltretter@gmail.com>,
"Aleksandr Loktionov" <aleksandr.loktionov@intel.com>,
"Meghana Malladi" <m-malladi@ti.com>,
"Jacob Keller" <jacob.e.keller@intel.com>,
"StanleyYP Wang" <StanleyYP.Wang@mediatek.com>,
Frank.Li@kernel.org, wsa+renesas@sang-engineering.com
Subject: Re: [PATCH net-next v1 4/5] net: remove skb->pp_recycle and consolidate netmem refcounting
Date: Wed, 04 Nov 2026 21:14:53 +0000 [thread overview]
Message-ID: <sashiko-outbox-198073@kernel.org> (raw)
In-Reply-To: <20261103211424.127627-5-almasrymina@google.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] page_pool: TOCTOU race in page_pool_unref_netmem() non-RMW fast path
- [High] tls: page leak between netmem kTLS records and mlx5 tx_sync_info_get()
--
commit 874363fccb05e0d08d430f57bfdafc048dfc73e0
Author: Mina Almasry <almasrymina@google.com>
net: remove skb->pp_recycle and consolidate netmem refcounting
This commit removes the per-SKB pp_recycle bitfield and updates
netmem_inc_ref(), netmem_dec_ref(), and skb_pp_recycle() to check page_pool
membership directly via netmem_is_pp(). It also updates page_pool_unref_netmem()
and napi_pp_get_page() to coordinate pp_ref_count with external struct page
references, and converts TLS and wireless fragment refcounting to netmem
helpers.
> diff --git a/include/net/page_pool/helpers.h b/include/net/page_pool/helpers.h
> index 28635ce9454e8..af3cb65c30416 100644
> --- a/include/net/page_pool/helpers.h
> +++ b/include/net/page_pool/helpers.h
> @@ -242,6 +242,11 @@ page_pool_get_dma_dir(const struct page_pool *pool)
> return pool->p.dma_dir;
> }
>
> +static inline long page_pool_ref_count(netmem_ref netmem)
> +{
> + return atomic_long_read(netmem_get_pp_ref_count_ref(netmem));
> +}
> +
> static inline void page_pool_fragment_netmem(netmem_ref netmem, long nr)
> {
> atomic_long_set(netmem_get_pp_ref_count_ref(netmem), nr);
> @@ -270,13 +275,22 @@ static inline void page_pool_fragment_page(struct page *page, long nr)
> page_pool_fragment_netmem(page_to_netmem(page), nr);
> }
>
> +static inline bool page_pool_netmem_is_exclusively_owned(netmem_ref netmem)
> +{
> + if (netmem_is_net_iov(netmem))
> + return true;
> +
> + return page_ref_count(__netmem_to_page(netmem)) == 1;
> +}
> +
> static inline long page_pool_unref_netmem(netmem_ref netmem, long nr)
> {
> atomic_long_t *pp_ref_count = netmem_get_pp_ref_count_ref(netmem);
> long ret;
>
> - /* If nr == pp_ref_count then we have cleared all remaining
> - * references to the page:
> + /* If nr == pp_ref_count and the page_pool holds the sole page
> + * reference, then we have cleared all remaining references to the
> + * page:
> * 1. 'n == 1': no need to actually overwrite it.
> * 2. 'n != 1': overwrite it with one, which is the rare case
> * for pp_ref_count draining.
> @@ -288,8 +302,15 @@ static inline long page_pool_unref_netmem(netmem_ref netmem, long nr)
> * handling by ensuring all pages have partitioned into only 1 piece
> * initially, and only overwrite it when the page is partitioned into
> * more than one piece.
> + *
> + * If an external page reference exists (page_ref_count > 1), a
> + * concurrent napi_pp_get_page() caller holding only a page reference
> + * may attempt atomic_long_inc_not_zero(pp_ref_count), so we must
> + * perform an atomic RMW subtraction to 0 and leave pp_ref_count at 0
> + * while the page is released from the pool.
> */
> - if (atomic_long_read(pp_ref_count) == nr) {
> + if (atomic_long_read(pp_ref_count) == nr &&
> + likely(page_pool_netmem_is_exclusively_owned(netmem))) {
> /* As we have ensured nr is always one for constant case using
> * the BUILD_BUG_ON(), only need to handle the non-constant case
> * here for pp_ref_count draining, which is a rare case.
[Severity: Critical]
Can the non-RMW fast path in page_pool_unref_netmem() race with a caller
that converts a struct page reference into a pp_ref_count reference, causing
an in-use page to be recycled into the pool?
With netmem_inc_ref() now calling napi_pp_get_page(), callers holding a
struct page reference such as zerocopy_fill_skb_from_iter() convert their
page_ref_count into a pp_ref_count:
net/core/datagram.c:zerocopy_fill_skb_from_iter() {
...
skb_fill_page_desc_noacc(skb, frag++, head, start, size);
netmem_inc_ref(page_to_netmem(head));
last_head = head;
refs++;
}
if (refs)
page_ref_sub(last_head, refs);
}
Consider a page_pool page with pp_ref_count == 1 (held by an SKB being freed
on CPU 0) and page_ref_count == 2 (1 held by the page_pool, 1 held by GUP in
zerocopy_fill_skb_from_iter() on CPU 1):
CPU 0 CPU 1
napi_pp_put_page()
page_pool_put_full_netmem()
page_pool_unref_netmem(netmem, 1)
atomic_long_read(pp_ref_count) == 1
(true; pp_ref_count stays 1)
zerocopy_fill_skb_from_iter()
netmem_inc_ref()
napi_pp_get_page()
atomic_long_inc_not_zero(pp_ref_count)
(pp_ref_count: 1 -> 2)
page_ref_sub(last_head, 1)
(page_ref_count: 2 -> 1)
page_pool_netmem_is_exclusively_owned()
page_ref_count(page) == 1 (true!)
returns 0 (leaving pp_ref_count == 2)
__page_pool_put_page()
__page_pool_page_can_be_recycled() (true)
recycles page into pool while CPU 1's TX SKB still references it!
Similarly, on weakly ordered architectures, because atomic_long_read() and
page_ref_count() are both relaxed loads with no barrier between them, when
pp_ref_count == 2 and page_ref_count == 1, CPU 0 can speculatively load
page_ref_count == 1 before CPU 1 maps the page via tcp_zerocopy_receive() ->
vm_insert_pages() (page_ref_count: 1 -> 2) and drops its pp_ref_count
(2 -> 1). CPU 0 then reads pp_ref_count == 1 and returns 0 with pp_ref_count
left at 1 instead of 0 while __page_pool_put_page() ->
page_pool_return_netmem() releases the page from the pool.
[ ... ]
> diff --git a/net/tls/tls_device.c b/net/tls/tls_device.c
> index 4cdfbb57ecff0..670fdeeeae567 100644
> --- a/net/tls/tls_device.c
> +++ b/net/tls/tls_device.c
[ ... ]
> @@ -269,7 +271,7 @@ static void tls_append_frag(struct tls_record_info *record,
> skb_frag_fill_page_desc(frag, pfrag->page, pfrag->offset,
> size);
> ++record->num_frags;
> - get_page(pfrag->page);
> + netmem_inc_ref(page_to_netmem(pfrag->page));
> }
>
> pfrag->offset += size;
> @@ -302,7 +304,7 @@ static int tls_push_record(struct sock *sk,
> sg_set_page(&offload_ctx->sg_tx_data[i], skb_frag_page(frag),
> skb_frag_size(frag), skb_frag_off(frag));
> sk_mem_charge(sk, skb_frag_size(frag));
> - get_page(skb_frag_page(frag));
> + netmem_inc_ref(skb_frag_netmem(frag));
> }
> sg_mark_end(&offload_ctx->sg_tx_data[record->num_frags - 1]);
[Severity: High]
Does switching tls_append_frag() and tls_push_record() to netmem_inc_ref()
cause a page leak during mlx5 kTLS TX resync when page_pool pages are
spliced into a hardware-offloaded TLS socket?
When a page_pool page is appended to a kTLS record (for example via
MSG_SPLICE_PAGES in tls_device_sendmsg() -> tls_push_data()),
tls_append_frag() and tls_push_record() now increment pp_ref_count via
netmem_inc_ref() -> napi_pp_get_page() instead of incrementing struct page
_refcount, leaving page_ref_count(page) == 1.
However, the mlx5 kTLS TX resync path in
drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_tx.c still manipulates
raw struct page _refcount on record->frags[i]:
tx_sync_info_get() {
...
while (remaining > 0) {
skb_frag_t *frag = &record->frags[i];
page_ref_inc(skb_frag_page(frag));
remaining -= skb_frag_size(frag);
info->frags[i++] = *frag;
}
}
and in mlx5e_ktls_tx_handle_ooo() and mlx5e_ktls_tx_handle_resync_dump_comp():
void mlx5e_ktls_tx_handle_resync_dump_comp(struct mlx5e_txqsq *sq,
struct mlx5e_tx_wqe_info *wi,
u32 *dma_fifo_cc)
{
...
mlx5e_tx_dma_unmap(sq->pdev, dma);
page_ref_dec(wi->resync_dump_frag_page);
stats->tls_dump_packets++;
stats->tls_dump_bytes += wi->num_bytes;
}
If the TCP ACK for the record arrives while the resync DUMP WQE is in
flight, tls_tcp_clean_acked() -> destroy_record() -> netmem_dec_ref() ->
napi_pp_put_page() runs while page_ref_count(page) > 1 (elevated by
page_ref_inc() / page_ref_add() in mlx5). Because page_ref_count(page) > 1,
__page_pool_page_can_be_recycled() returns false and __page_pool_put_page()
calls page_pool_return_netmem(), which unmaps the page from the pool, clears
pp_magic, and drops the page_pool's _refcount via put_page().
When the DUMP WQE later completes in mlx5e_ktls_tx_handle_resync_dump_comp()
(or unwinds at err_out in mlx5e_ktls_tx_handle_ooo()), page_ref_dec()
decrements page->_refcount to 0 without freeing the page to the page
allocator, leaking the page.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261103211424.127627-1-almasrymina@google.com?part=4
next prev parent reply other threads:[~2026-11-04 21:14 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-03 21:14 [PATCH net-next v1 0/5] net: deprecate skb->pp_recycle and skb_mark_for_recycle() Mina Almasry
2026-11-03 21:14 ` [PATCH net-next v1 1/5] net: skbuff: skip managed zerocopy frags in skb_frag_ref() Mina Almasry
2026-11-04 21:14 ` sashiko-bot
2026-11-03 21:14 ` [PATCH net-next v1 2/5] net: skbuff: refcount spliced page_pool frags via skb_pipe_buf_ops Mina Almasry
2026-11-04 21:14 ` sashiko-bot
2026-11-03 21:14 ` [PATCH net-next v1 3/5] net: datagram: refcount page_pool frags in zerocopy_fill_skb_from_iter() Mina Almasry
2026-11-04 21:14 ` sashiko-bot
2026-11-05 12:45 ` Loktionov, Aleksandr
2026-11-03 21:14 ` [PATCH net-next v1 4/5] net: remove skb->pp_recycle and consolidate netmem refcounting Mina Almasry
2026-11-04 21:14 ` sashiko-bot [this message]
2026-11-06 19:36 ` Mina Almasry
2026-11-03 21:14 ` [PATCH net-next v1 5/5] net: remove skb_mark_for_recycle() Mina Almasry
2026-11-04 21:14 ` sashiko-bot
2026-11-05 16:35 ` [PATCH net-next v1 0/5] net: deprecate skb->pp_recycle and skb_mark_for_recycle() Jesper Dangaard Brouer
2026-11-06 17:53 ` Mina Almasry
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-198073@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=StanleyYP.Wang@mediatek.com \
--cc=Steen.Hegelund@microchip.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=akpm@linux-foundation.org \
--cc=aleksandr.loktionov@intel.com \
--cc=alex@sverdlin.org \
--cc=alexandre.torgue@foss.st.com \
--cc=almasrymina@google.com \
--cc=andrew+netdev@lunn.ch \
--cc=angelogioacchino.delregno@collabora.com \
--cc=anthony.l.nguyen@intel.com \
--cc=asml.silence@gmail.com \
--cc=ast@kernel.org \
--cc=bbhushan2@marvell.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=bobbyeshleman@meta.com \
--cc=bpf@vger.kernel.org \
--cc=brett.creeley@amd.com \
--cc=byungchul@sk.com \
--cc=c-vankar@ti.com \
--cc=corbet@lwn.net \
--cc=daniel.machon@microchip.com \
--cc=daniel@iogearbox.net \
--cc=danishanwar@ti.com \
--cc=davem@davemloft.net \
--cc=david@kernel.org \
--cc=decui@microsoft.com \
--cc=dong100@mucse.com \
--cc=edumazet@kernel.org \
--cc=eperezma@redhat.com \
--cc=eric.joyner@amd.com \
--cc=ernis@linux.microsoft.com \
--cc=florian.fainelli@broadcom.com \
--cc=frank.li@nxp.com \
--cc=fujita.tomonori@gmail.com \
--cc=gakula@marvell.com \
--cc=gongfan1@huawei.com \
--cc=guwen@linux.alibaba.com \
--cc=haiyangz@microsoft.com \
--cc=haokexin@gmail.com \
--cc=hawk@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=horatiu.vultur@microchip.com \
--cc=horms@kernel.org \
--cc=hramamurthy@google.com \
--cc=idosch@nvidia.com \
--cc=ilias.apalodimas@linaro.org \
--cc=imx@lists.linux.dev \
--cc=jacob.e.keller@intel.com \
--cc=jasowangio@gmail.com \
--cc=jgross@suse.com \
--cc=jiawenwu@trustnetic.com \
--cc=johannes@sipsolutions.net \
--cc=john.fastabend@gmail.com \
--cc=jordanrhee@google.com \
--cc=joshwash@google.com \
--cc=justin.chen@broadcom.com \
--cc=justinlai0215@realtek.com \
--cc=kmehltretter@gmail.com \
--cc=kojima.masahisa@socionext.com \
--cc=kuba@kernel.org \
--cc=larry.chiu@realtek.com \
--cc=leon@kernel.org \
--cc=liam@infradead.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=ljs@kernel.org \
--cc=lorenzo@kernel.org \
--cc=lulie@linux.alibaba.com \
--cc=m-malladi@ti.com \
--cc=marcin.s.wojtas@gmail.com \
--cc=matthias.bgg@gmail.com \
--cc=maxime.chevallier@bootlin.com \
--cc=mbloch@nvidia.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=mengyuanlou@net-swift.com \
--cc=mheib@redhat.com \
--cc=mhocko@suse.com \
--cc=michael.chan@broadcom.com \
--cc=mst@redhat.com \
--cc=nb@tipi-net.de \
--cc=nbd@nbd.name \
--cc=niklas.soderlund@ragnatech.se \
--cc=nktgrg@google.com \
--cc=nora.schiffer@ew.tq-group.com \
--cc=oleksandr_tyshchenko@epam.com \
--cc=opendmb@gmail.com \
--cc=pabeni@redhat.com \
--cc=paul@pbarker.dev \
--cc=pavan.chebbi@broadcom.com \
--cc=petrm@nvidia.com \
--cc=prabu.ponrajthayalan@amd.com \
--cc=przemyslaw.kitszel@intel.com \
--cc=rdunlap@infradead.org \
--cc=rkannoth@marvell.com \
--cc=rogerq@kernel.org \
--cc=ronak.doshi@broadcom.com \
--cc=rppt@kernel.org \
--cc=ryder.lee@mediatek.com \
--cc=s-vadapalli@ti.com \
--cc=saeedm@nvidia.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=satishkh@cisco.com \
--cc=sbhatta@marvell.com \
--cc=sd@queasysnail.net \
--cc=sdf@fomichev.me \
--cc=sean.wang@mediatek.com \
--cc=sgoutham@marvell.com \
--cc=shaojijie@huawei.com \
--cc=shayne.chen@mediatek.com \
--cc=shenjian15@huawei.com \
--cc=shenwei.wang@nxp.com \
--cc=skhan@linuxfoundation.org \
--cc=sstabellini@kernel.org \
--cc=steffen.klassert@secunet.com \
--cc=surenb@google.com \
--cc=tariqt@nvidia.com \
--cc=thostet@google.com \
--cc=vbabka@kernel.org \
--cc=vikas.gupta@broadcom.com \
--cc=virtualization@lists.linux.dev \
--cc=wei.fang@nxp.com \
--cc=wei.liu@kernel.org \
--cc=willemb@google.com \
--cc=wsa+renesas@sang-engineering.com \
--cc=xuanzhuo@linux.alibaba.com \
/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.