* Re: [RFC] connectat()/bindat() or an alternative design
From: John Ericson @ 2026-06-30 20:22 UTC (permalink / raw)
To: Cong Wang
Cc: Li Chen, Andy Lutomirski, Christian Brauner, Jens Axboe,
network dev, linux-fsdevel
In-Reply-To: <66eb8227-85b6-4684-a4fa-e3e17ac2fa45@app.fastmail.com>
I'm bumping this and adding new recipients again in light of the
discussion happening elsewhere in
<https://lore.kernel.org/all/a49ce818-f38d-41b0-bbf7-80b8aad998b1@app.fastmail.com/>.
I don't want to count my chickens before they are hatched, but it is
looking to me like a consensus in that thread is building around the
ability to opt into intentionally empty/unusable root and working
directories (at least with nullfs, maybe but less likely with other
mechanisms instead).
That new functionality concretizes the motivation for what I am
proposing in this thread: in such a world, there is little to no point
binding listening sockets in the file system, because the containing
directory would have to be conveyed by file descriptor anyways --- might
as well just directly convey the socket to connect to by file
descriptor. Likewise, abstract sockets are not appealing, because the
abstract socket namespace is either too coarse-grained (leaking info in
the same way root/cwd would), or too cumbersome to keep it from leaking.
To recap (with some slight changes, like renames), my latest proposal (a
new version, not either of the two variations in the original email) is
new syscalls `bind_unix_anon` and `connectat`, supporting a workflow
like this:
/* server */
int lfd = socket(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC, 0);
int addrfd = bind_unix_anon(
lfd,
/*flags, for the future*/0);
listen(lfd, 64);
/* client, handed `addrfd` */
int cfd = socket(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC, 0);
connectat(addrfd, cfd, AT_EMPTY_PATH);
Or, more radically, `bind_unix_anon` and `connectat` could let one skip
the initial `socket` calls by returning those new sockets directly:
/* server */
int fds[2];
bind_unix_anon(
SOCK_STREAM | SOCK_CLOEXEC,
/*flags, for the future*/0,
fds);
int lfd = fds[0], addrfd = fds[1];
listen(lfd, 64);
/* client, handed `addrfd` */
int cfd = connectat(
addrfd,
SOCK_STREAM | SOCK_CLOEXEC,
AT_EMPTY_PATH);
(Note that in this variation `bind_unix_anon` would return *two* file
descriptors: one for the server, with the permission to listen, and the
other for clients, with just the privilege to `connectat`.) (Maybe
`bind_unix_anon` should furthermore `listen` right away on `lfd` too?)
Of course, it would be nice to have io_uring versions of these too. But
I don't know what the usual process is for that (regular first? io_uring
first? both at the same time?)
Thanks,
John
P.S. For anyone just getting CC'd now, the first message in this thread
is
<https://lore.kernel.org/all/b1af80fc-a57c-408d-bdfe-fa6bae26eaca@app.fastmail.com/>.
Hope that might save people a few keypresses :).
^ permalink raw reply
* Re: [PATCH v2 7/7] pci: fix UAF when probe runs concurrent to dyn ID removal
From: Danilo Krummrich @ 2026-06-30 20:25 UTC (permalink / raw)
To: Gary Guo
Cc: Bjorn Helgaas, Zhenzhong Duan, Greg Kroah-Hartman,
Rafael J. Wysocki, Damien Le Moal, Niklas Cassel, GOTO Masanori,
YOKOTA Hiroshi, James E.J. Bottomley, Martin K. Petersen,
Vaibhav Gupta, Jens Taprogge, Ido Schimmel, Petr Machata,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-pci, driver-core, linux-kernel, linux-ide,
linux-scsi, industrypack-devel, netdev, Sashiko
In-Reply-To: <20260630-pci_id_fix-v2-7-b834a98c0af2@garyguo.net>
On Tue Jun 30, 2026 at 1:09 PM CEST, Gary Guo wrote:
> -static const struct pci_device_id *pci_match_device(struct pci_driver *drv,
> - struct pci_dev *dev)
> +static bool pci_match_device(struct pci_driver *drv,
> + struct pci_dev *dev,
> + struct pci_device_id *id)
> {
> struct pci_dynid *dynid;
> const struct pci_device_id *found_id = NULL;
> @@ -196,30 +198,33 @@ static const struct pci_device_id *pci_match_device(struct pci_driver *drv,
> /* When driver_override is set, only bind to the matching driver */
> ret = device_match_driver_override(&dev->dev, &drv->driver);
> if (ret == 0)
> - return NULL;
> + return false;
>
> dev_id = pci_id_from_device(dev);
> /* Look at the dynamic ids first, before the static ones */
> - spin_lock(&drv->dynids.lock);
> - list_for_each_entry(dynid, &drv->dynids.list, node) {
> - if (pci_match_one_id(&dynid->id, &dev_id)) {
> - found_id = &dynid->id;
> - break;
> + {
> + guard(spinlock)(&drv->dynids.lock);
> + list_for_each_entry(dynid, &drv->dynids.list, node) {
> + if (pci_match_one_id(&dynid->id, &dev_id)) {
> + *id = dynid->id;
> + return true;
> + }
> }
> }
Should be scoped_guard(spinlock, &drv->dynids.lock). It also looks like dynid
could be moved into the scoped_guard().
^ permalink raw reply
* Re: Please backport bridge multicast exponential field encoding fix series to stable kernels
From: Greg KH @ 2026-06-30 20:29 UTC (permalink / raw)
To: Ujjal Roy
Cc: Sasha Levin, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Nikolay Aleksandrov, Ido Schimmel,
David Ahern, Shuah Khan, Andy Roulin, Yong Wang, Petr Machata,
stable, Ujjal Roy, bridge, Kernel, Kernel, linux-kselftest
In-Reply-To: <CAE2MWkkON7HuB+Szc1VhaPL8ZTYMAyfzmPM_7FkXvOPnjnF5rQ@mail.gmail.com>
On Wed, Jul 01, 2026 at 01:33:07AM +0530, Ujjal Roy wrote:
> On Thu, Jun 25, 2026 at 8:20 PM Ujjal Roy <royujjal@gmail.com> wrote:
> >
> > On Thu, Jun 25, 2026 at 4:12 PM Sasha Levin <sashal@kernel.org> wrote:
> > >
> > > > Please backport the 5-patch bridge multicast exponential field
> > > > encoding series (726fa7da2d8c, 12cfb4ecc471, 95bfd196f0dc,
> > > > e51560f4220a, 529dbe762de0) to the stable kernels.
> > >
> > > I tried, but it doesn't apply to 7.1. Could you provide a backport please?
> > >
> > > --
> > > Thanks,
> > > Sasha
> >
> > I will create patches on top of 7.1. But tell me what about all other
> > stable releases? I have to create patches to all stables and how to
> > share the patches to you? Via this email or any other process? I am a
> > fresh on backporting my changes to all stables.
>
> I have prepared the patches for stable releases mentioned in kernel.org.
>
> And I am waiting for your response so that I can send you the patchset.
Please just send the patches :)
^ permalink raw reply
* Re: [PATCH V2] MAINTAINERS: Update Jason Wang's email address
From: patchwork-bot+netdevbpf @ 2026-06-30 20:32 UTC (permalink / raw)
To: Jason Wang; +Cc: mst, virtualization, netdev, eperezma, kvm, linux-kernel
In-Reply-To: <20260629014525.16297-1-jasowang@redhat.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 29 Jun 2026 09:45:24 +0800 you wrote:
> I will use jasowangio@gmail.com for future review and discussion.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> Changes since V1:
> - Add mailmap entry
>
> [...]
Here is the summary with links:
- [V2] MAINTAINERS: Update Jason Wang's email address
https://git.kernel.org/netdev/net/c/1398b1014909
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next v4] vsock/virtio: rewrite MSG_ZEROCOPY flag handling
From: patchwork-bot+netdevbpf @ 2026-06-30 20:32 UTC (permalink / raw)
To: Arseniy Krasnov
Cc: stefanha, sgarzare, davem, edumazet, kuba, pabeni, mst, jasowang,
bobbyeshleman, xuanzhuo, eperezma, horms, kvm, virtualization,
netdev, linux-kernel, oxffffaa, rulkc
In-Reply-To: <20260628182052.951760-1-avkrasnov@rulkc.org>
Hello:
This patch was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Sun, 28 Jun 2026 21:20:52 +0300 you wrote:
> Logically it was based on TCP implementation, so to make further support
> easier, rewrite it in the TCP way (like in 'tcp_sendmsg_locked()'). By
> this way, patch also adds handling case when 'msg_ubuf' is already set.
>
> Signed-off-by: Arseniy Krasnov <avkrasnov@rulkc.org>
> ---
> Changelog v1->v2:
> * Rebase on last 'net-next'. Don't need 'skb_zcopy_set()' now - it was
> already added.
> Changelog v2->v3:
> * Update commit message.
> * Remove one empty line.
> Changelog v3->v4:
> * Update commit message.
>
> [...]
Here is the summary with links:
- [net-next,v4] vsock/virtio: rewrite MSG_ZEROCOPY flag handling
https://git.kernel.org/netdev/net-next/c/f456c1922c49
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH bpf 0/2] bpf, sockmap: fix copied_seq left behind when a stream parser is removed
From: Sechang Lim @ 2026-06-30 20:50 UTC (permalink / raw)
To: Eric Dumazet, Neal Cardwell, John Fastabend, Jakub Sitnicki,
Jiayuan Chen, David S. Miller, Jakub Kicinski, Paolo Abeni,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Eduard Zingerman, Kumar Kartikeya Dwivedi, Shuah Khan
Cc: Kuniyuki Iwashima, Simon Horman, Martin KaFai Lau, Song Liu,
Yonghong Song, Jiri Olsa, Emil Tsalapatis, Ihor Solodrai, netdev,
bpf, linux-kernel, linux-kselftest
A stream-parser sockmap socket can be removed with SK_PASS data still
parked on its ingress_msg queue. The copied_seq rollback for that data is
never repaid, leaving copied_seq behind sk_receive_queue, so the native
tcp_recvmsg() warns. Patch 1 settles copied_seq on removal. Patch 2 adds a
selftest.
Sechang Lim (2):
bpf, sockmap: settle copied_seq when a stream parser is removed
selftests/bpf: test sockmap strparser recover with undelivered ingress
net/ipv4/tcp_bpf.c | 9 +++
.../selftests/bpf/prog_tests/sockmap_basic.c | 59 +++++++++++++++++++
2 files changed, 68 insertions(+)
--
2.43.0
^ permalink raw reply
* [PATCH bpf 1/2] bpf, sockmap: settle copied_seq when a stream parser is removed
From: Sechang Lim @ 2026-06-30 20:50 UTC (permalink / raw)
To: Eric Dumazet, Neal Cardwell, John Fastabend, Jakub Sitnicki,
Jiayuan Chen, David S. Miller, Jakub Kicinski, Paolo Abeni,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Eduard Zingerman, Kumar Kartikeya Dwivedi, Shuah Khan
Cc: Kuniyuki Iwashima, Simon Horman, Martin KaFai Lau, Song Liu,
Yonghong Song, Jiri Olsa, Emil Tsalapatis, Ihor Solodrai, netdev,
bpf, linux-kernel, linux-kselftest
In-Reply-To: <20260630205043.184894-1-rhkrqnwk98@gmail.com>
tcp_bpf_strp_read_sock() rolls tp->copied_seq back by the SK_PASS bytes
parked on the psock ingress_msg queue; tcp_bpf_recvmsg_parser() repays it
as those bytes are delivered. When the socket leaves the sockmap they are
purged undelivered and nothing repays the rollback, so copied_seq is left
behind sk_receive_queue and the native tcp_recvmsg() warns:
TCP recvmsg seq # bug: copied 66913561, seq 6691356A, rcvnxt 66913572, fl 40
WARNING: net/ipv4/tcp.c:2733 at tcp_recvmsg_locked+0x2d0/0x1270
tcp_recvmsg+0xba/0x340
inet_recvmsg+0x7a/0x370
sock_recvmsg+0xef/0x110
__sys_recvfrom+0x132/0x1e0
Settle copied_seq to the parser's consume point as the socket leaves the
sockmap so it cannot trail the receive queue.
Fixes: 36b62df5683c ("bpf: Fix wrong copied_seq calculation")
Signed-off-by: Sechang Lim <rhkrqnwk98@gmail.com>
---
net/ipv4/tcp_bpf.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/net/ipv4/tcp_bpf.c b/net/ipv4/tcp_bpf.c
index cc0bd73f36b6..918f8da02c39 100644
--- a/net/ipv4/tcp_bpf.c
+++ b/net/ipv4/tcp_bpf.c
@@ -715,6 +715,15 @@ int tcp_bpf_update_proto(struct sock *sk, struct sk_psock *psock, bool restore)
}
if (restore) {
+#if IS_ENABLED(CONFIG_BPF_STREAM_PARSER)
+ /*
+ * Settle the copied_seq rollback for the now-discarded
+ * ingress_msg data so it cannot trail the receive queue
+ */
+ if (sk_psock_test_state(psock, SK_PSOCK_RX_STRP_ENABLED) &&
+ before(tcp_sk(sk)->copied_seq, psock->copied_seq))
+ WRITE_ONCE(tcp_sk(sk)->copied_seq, psock->copied_seq);
+#endif
if (inet_csk_has_ulp(sk)) {
/* TLS does not have an unhash proto in SW cases,
* but we need to ensure we stop using the sock_map
--
2.43.0
^ permalink raw reply related
* [PATCH bpf 2/2] selftests/bpf: test sockmap strparser recover with undelivered ingress
From: Sechang Lim @ 2026-06-30 20:50 UTC (permalink / raw)
To: Eric Dumazet, Neal Cardwell, John Fastabend, Jakub Sitnicki,
Jiayuan Chen, David S. Miller, Jakub Kicinski, Paolo Abeni,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Eduard Zingerman, Kumar Kartikeya Dwivedi, Shuah Khan
Cc: Kuniyuki Iwashima, Simon Horman, Martin KaFai Lau, Song Liu,
Yonghong Song, Jiri Olsa, Emil Tsalapatis, Ihor Solodrai, netdev,
bpf, linux-kernel, linux-kselftest
In-Reply-To: <20260630205043.184894-1-rhkrqnwk98@gmail.com>
Park SK_PASS data on a stream-parser socket's ingress_msg queue, drop the
socket from the sockmap without reading it, then check the native stack
still delivers data queued afterwards. Without the fix copied_seq is left
behind sk_receive_queue and tcp_recvmsg_locked() warns instead of
delivering.
Signed-off-by: Sechang Lim <rhkrqnwk98@gmail.com>
---
.../selftests/bpf/prog_tests/sockmap_basic.c | 59 +++++++++++++++++++
1 file changed, 59 insertions(+)
diff --git a/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c b/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c
index cb3229711f93..86b584f5491e 100644
--- a/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c
+++ b/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c
@@ -1292,6 +1292,63 @@ static int wait_for_fionread(int fd, int expected, unsigned int timeout_ms)
return avail;
}
+static void test_sockmap_strp_recover_undelivered(void)
+{
+ struct test_sockmap_pass_prog *skel = NULL;
+ int c0 = -1, p0 = -1, c1 = -1, p1 = -1;
+ char buf[10] = "0123456789", rcv[11];
+ int err, map, verdict, parser, sent, recvd, avail, zero = 0;
+
+ skel = test_sockmap_pass_prog__open_and_load();
+ if (!ASSERT_OK_PTR(skel, "open_and_load"))
+ return;
+
+ if (create_socket_pairs(AF_INET, SOCK_STREAM, &c0, &c1, &p0, &p1))
+ goto out;
+
+ map = bpf_map__fd(skel->maps.sock_map_rx);
+
+ verdict = bpf_program__fd(skel->progs.prog_skb_verdict);
+ err = bpf_prog_attach(verdict, map, BPF_SK_SKB_STREAM_VERDICT, 0);
+ if (!ASSERT_OK(err, "bpf_prog_attach"))
+ goto out;
+
+ parser = bpf_program__fd(skel->progs.prog_skb_verdict_ingress_strp);
+ err = bpf_prog_attach(parser, map, BPF_SK_SKB_STREAM_PARSER, 0);
+ if (!ASSERT_OK(err, "bpf_prog_attach"))
+ goto out;
+
+ err = bpf_map_update_elem(map, &zero, &p1, BPF_ANY);
+ if (!ASSERT_OK(err, "bpf_map_update(p1)"))
+ goto out;
+
+ sent = xsend(c1, buf, sizeof(buf), 0);
+ if (!ASSERT_EQ(sent, sizeof(buf), "xsend(c1) bpf"))
+ goto out;
+
+ avail = wait_for_fionread(p1, sizeof(buf), 1000);
+ if (!ASSERT_EQ(avail, sizeof(buf), "fionread"))
+ goto out;
+
+ err = bpf_map_delete_elem(map, &zero);
+ if (!ASSERT_OK(err, "map_delete(p1)"))
+ goto out;
+
+ sent = xsend(c1, buf, sizeof(buf), 0);
+ if (!ASSERT_EQ(sent, sizeof(buf), "xsend(c1) native"))
+ goto out;
+ recvd = recv_timeout(p1, rcv, sizeof(buf), MSG_DONTWAIT, 1);
+ ASSERT_EQ(recvd, sent, "recv(p1) native after drop");
+
+out:
+ close(c0);
+ close(p0);
+ close(c1);
+ close(p1);
+
+ test_sockmap_pass_prog__destroy(skel);
+}
+
/* it is used to send data to via native stack and BPF redirecting */
static void test_sockmap_multi_channels(int sotype)
{
@@ -1447,6 +1504,8 @@ void test_sockmap_basic(void)
test_sockmap_copied_seq(false);
if (test__start_subtest("sockmap recover with strp"))
test_sockmap_copied_seq(true);
+ if (test__start_subtest("sockmap strp recover undelivered"))
+ test_sockmap_strp_recover_undelivered();
if (test__start_subtest("sockmap tcp multi channels"))
test_sockmap_multi_channels(SOCK_STREAM);
if (test__start_subtest("sockmap udp multi channels"))
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net-next v2] ipv4: igmp: remove multicast group from hash table on device destruction
From: Kuniyuki Iwashima @ 2026-06-30 21:13 UTC (permalink / raw)
To: idosch
Cc: davem, dsahern, edumazet, horms, jedrzej.jagielski, kuba,
linux-kernel, netdev, pabeni, xiyou.wangcong, yuyanghuang
In-Reply-To: <20260630165934.GA1227354@shredder>
From: Ido Schimmel <idosch@nvidia.com>
Date: Tue, 30 Jun 2026 19:59:34 +0300
> On Tue, Jun 30, 2026 at 04:55:22PM +0900, Yuyang Huang wrote:
> > > Hi,
> > >
> > > why sending this to net-next not to net if that's a bug fix?
> > >
> > > In the v1 thread it was said
> > > >This is a long-standing bug, not a recent regression.
> > >
> > > so why do not cc stable kernel to get rid of this bug from
> > > stable kernels in such case?
> >
> > Thanks for the advise, will send this patch to stable kernel.
>
> Please target v3 at net and add a trace given you're claiming for a
> use-after-free. That way we know that the problem is real and not a
> false-positive from some tool. You can reproduce it by adding enough
> delay in inetdev_destroy():
I guess delay was added between ip_mc_destroy_dev() and
RCU_INIT_POINTER(dev->ip_ptr, NULL) ?
I feel like we should clear it first and destroy everything
as done in IPv6 addrconf_ifdown().
>
> BUG: KASAN: slab-use-after-free in ip_check_mc_rcu+0x2cc/0x500
> Read of size 4 at addr ffff88810c571208 by task mausezahn/419
>
> CPU: 2 UID: 0 PID: 419 Comm: mausezahn Not tainted 7.1.0-virtme-g15d4a7c23bf6 #17 PREEMPT(lazy)
> Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> Call Trace:
> <IRQ>
> dump_stack_lvl+0x4d/0x70
> print_report+0x153/0x4c2
> kasan_report+0xda/0x110
> ip_check_mc_rcu+0x2cc/0x500
> ip_route_input_rcu.part.0+0x13d/0xbc0
> ip_route_input_noref+0xb6/0x110
> ip_rcv_finish_core+0x41b/0x1d90
> ip_rcv_finish+0xea/0x1b0
> ip_rcv+0xb7/0x1b0
> __netif_receive_skb_one_core+0xfc/0x180
> process_backlog+0x1ea/0x5e0
> __napi_poll+0x97/0x480
> net_rx_action+0x97c/0xfa0
> handle_softirqs+0x18c/0x4f0
> do_softirq+0x42/0x60
> </IRQ>
>
^ permalink raw reply
* [PATCH net] mac802154: wait for RCU readers when removing interfaces
From: Yousef Alhouseen @ 2026-06-30 21:18 UTC (permalink / raw)
To: Alexander Aring, Stefan Schmidt, Miquel Raynal
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Marcel Holtmann, linux-wpan, netdev, linux-kernel,
stable, syzbot+36256deb69a588e9290e, Yousef Alhouseen
Queue wake, stop, and disable paths walk local->interfaces under RCU.
The bulk hardware teardown path removes entries with list_del() and
immediately unregisters their netdevices, so an asynchronous transmit
completion can follow a poisoned list node in ieee802154_wake_queue().
Match ieee802154_if_remove(): use list_del_rcu() and wait for existing
readers before unregistering each interface.
Fixes: 592dfbfc72f5 ("mac820154: move interface unregistration into iface")
Reported-by: syzbot+36256deb69a588e9290e@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=36256deb69a588e9290e
Cc: stable@vger.kernel.org
Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
---
net/mac802154/iface.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/mac802154/iface.c b/net/mac802154/iface.c
index 000be60d9580..73d82a015184 100644
--- a/net/mac802154/iface.c
+++ b/net/mac802154/iface.c
@@ -703,7 +703,8 @@ void ieee802154_remove_interfaces(struct ieee802154_local *local)
mutex_lock(&local->iflist_mtx);
list_for_each_entry_safe(sdata, tmp, &local->interfaces, list) {
- list_del(&sdata->list);
+ list_del_rcu(&sdata->list);
+ synchronize_rcu();
unregister_netdevice(sdata->dev);
}
--
2.55.0
^ permalink raw reply related
* Re: [RFC PATCH bpf-next v1 0/7] xdp: RX checksum metadata hint and checksum assertion over redirect
From: Stanislav Fomichev @ 2026-06-30 21:18 UTC (permalink / raw)
To: Vladimir Vdovin
Cc: bpf, netdev, ast, daniel, andrii, martin.lau, sdf, hawk,
john.fastabend, kuba, lorenzo
In-Reply-To: <20260630191510.81402-1-deliran@verdict.gg>
On 06/30, Vladimir Vdovin wrote:
> This series lets XDP programs work with the hardware RX checksum verdict:
> read what the NIC concluded about a packet, and carry a "the L4 checksum
> is correct" assertion across a redirect so the stack does not revalidate
> it in software.
>
> When an XDP program redirects a frame to a cpumap (or any other path that
> rebuilds an skb from an xdp_frame via __xdp_build_skb_from_frame()), the
> HW RX checksum status is lost and the stack revalidates the L4 checksum in
> software.
>
> Two kfuncs are added:
>
> - bpf_xdp_metadata_rx_csum(): a device-bound RX-metadata hint, like the
> existing rx_hash / rx_vlan_tag ones. It reports enum xdp_csum_status
> (XDP_CSUM_NONE / XDP_CSUM_VERIFIED) and is implemented for mlx5e, ice
> and veth.
>
> - bpf_xdp_assert_rx_csum(): a generic, non-device-bound kfunc that lets
> the program assert the L4 checksum is correct. It sets a buff flag
> that rides into the xdp_frame, and __xdp_build_skb_from_frame() turns
> it into skb->ip_summed = CHECKSUM_UNNECESSARY. The kernel cannot
> verify the assertion; the program takes responsibility, as it already
> does when rewriting packet contents.
>
> Posted as RFC to get feedback on:
>
> - whether the read hint (bpf_xdp_metadata_rx_csum() and its driver
> support) belongs in this series at all. bpf_xdp_assert_rx_csum() is
> self-contained and already covers the main use case: a program that
> computes or fixes the L4 checksum itself, or trusts the source, and
> wants the rebuilt skb to skip software revalidation. The read hint is
> an optimization for programs that did not touch the payload and only
> want to relay the hardware verdict. These could just as well be two
> independent series (assert-only first);
> - the kfunc naming, bpf_xdp_assert_rx_csum() in particular.
>
> Testing:
>
> - new selftest xdp_cpumap_rx_csum drives a frame through a native-XDP
> veth into a cpumap redirect and checks, via fexit on
> __xdp_build_skb_from_frame(), that the rebuilt skb is
> CHECKSUM_UNNECESSARY iff the program called bpf_xdp_assert_rx_csum();
> - xdp_metadata calls bpf_xdp_metadata_rx_csum() over veth and checks both
> verdicts: XDP_CSUM_NONE for an AF_XDP-injected frame and
> XDP_CSUM_VERIFIED for one sent through the stack.
This was posted somewhat recently from Lorenzo (and had a fair bit of
discussion), but there haven't been a follow up:
https://lore.kernel.org/bpf/20260217-bpf-xdp-meta-rxcksum-v3-0-30024c50ba71@kernel.org/
^ permalink raw reply
* Re: [PATCH 00/13] treewide: replace linux/gpio.h
From: Linus Walleij @ 2026-06-30 21:39 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, Arnd Bergmann, Bartosz Golaszewski, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Greg Ungerer, Thomas Bogendoerfer,
Hauke Mehrtens, Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Dmitry Torokhov, Jakub Kicinski,
Paolo Abeni, Dominik Brodowski, linux-kernel, linux-arm-kernel,
linux-samsung-soc, patches, linux-m68k, linux-mips, linux-sh,
linux-input, linux-media, netdev, linux-sunxi, linux-phy,
linux-rockchip, linux-sound
In-Reply-To: <20260629132633.1300009-1-arnd@kernel.org>
On Mon, Jun 29, 2026 at 3:26 PM Arnd Bergmann <arnd@kernel.org> wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The linux/gpio.h header used to be the global definition for the gpio
> interfaces, with 1100 users back in linux-3.17. In linux-7.2, only about
> 130 of those remain, so this series cleans out the rest.
>
> In each subsystem, we can replace the header either with
> linux/gpio/consumer.h for users of the modern gpio descriptor interface,
> or linux/gpio/legacy.h for the few remaining users of the old number
> based interface.
>
> All patches in this series can get applied independently, so my
> preference would be for each subsystem maintainer to apply these
> directly, with the rest going into the gpio tree at some point.
>
> The final patch here obviously needs to wait for all the others
> to get merged first.
This is helpful.
The series:
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH net 0/4][pull request] Intel Wired LAN Driver Updates 2026-06-30 (ice, idpf, igbvf)
From: Tony Nguyen @ 2026-06-30 21:43 UTC (permalink / raw)
To: davem, kuba, pabeni, edumazet, andrew+netdev, netdev; +Cc: Tony Nguyen
Aaron Ma adds a wait for reset completion before returning from resume
on ice driver.
Dawid completely disables and clears VF interrupts during reset on ice.
David Carlier adds handling for a NULL adev when reporting MTU change
event for idpf.
Matt Vollrath removes incorrect decrement of count which could cause
leaking due to off-by-one issue.
The following are changes since commit 2a00517db8de4be7df3d483b215c5544fb30a191:
bridge: stp: Fix a potential use-after-free when deleting a bridge
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue 100GbE
Aaron Ma (1):
ice: wait for reset completion in ice_resume()
David Carlier (1):
idpf: handle NULL adev in idpf_idc_vdev_mtu_event
Dawid Osuchowski (1):
ice: fix VF interrupts cleanup
Matt Vollrath (1):
igbvf: Fix leak in TX DMA error cleanup
drivers/net/ethernet/intel/ice/ice_main.c | 10 +++++++
drivers/net/ethernet/intel/ice/ice_vf_lib.c | 27 +++++++++++++++++++
.../ethernet/intel/ice/ice_vf_lib_private.h | 1 +
drivers/net/ethernet/intel/ice/virt/queues.c | 21 +++++++++++++++
drivers/net/ethernet/intel/idpf/idpf_idc.c | 11 +++++---
drivers/net/ethernet/intel/igbvf/netdev.c | 2 --
6 files changed, 66 insertions(+), 6 deletions(-)
--
2.47.1
^ permalink raw reply
* [PATCH net 1/4] ice: wait for reset completion in ice_resume()
From: Tony Nguyen @ 2026-06-30 21:43 UTC (permalink / raw)
To: davem, kuba, pabeni, edumazet, andrew+netdev, netdev
Cc: Aaron Ma, anthony.l.nguyen, jbrandeb, stable, Kohei Enju,
Aleksandr Loktionov, Przemek Kitszel, Alexander Nowlin
In-Reply-To: <20260630214404.930923-1-anthony.l.nguyen@intel.com>
From: Aaron Ma <aaron.ma@canonical.com>
ice_resume() schedules an asynchronous PF reset and returns
immediately. The reset runs later in ice_service_task(). If
userspace tries to bring up the net device before the reset
finishes, ice_open() fails with -EBUSY:
ice_resume()
ice_schedule_reset() # sets ICE_PFR_REQ, returns
...
ice_open()
ice_is_reset_in_progress() # ICE_PFR_REQ still set, -EBUSY
...
ice_service_task()
ice_do_reset()
ice_rebuild() # clears ICE_PFR_REQ, too late
Reproduced on E800 series NICs during suspend/resume with irdma
enabled, where the aux device probe widens the race window.
ice 0000:81:00.0: can't open net device while reset is in progress
Add a best-effort wait (10s timeout, matching ice_devlink_info_get())
for the reset to complete before returning from ice_resume(). In
practice the reset completes in ~300ms.
Fixes: 769c500dcc1e ("ice: Add advanced power mgmt for WoL")
Cc: stable@vger.kernel.org
Reviewed-by: Kohei Enju <kohei@enjuk.jp>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Alexander Nowlin <alexander.nowlin@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
drivers/net/ethernet/intel/ice/ice_main.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index e2fd2dab03e3..d88835482d3a 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -5637,6 +5637,16 @@ static int ice_resume(struct device *dev)
/* Restart the service task */
mod_timer(&pf->serv_tmr, round_jiffies(jiffies + pf->serv_tmr_period));
+ /* Best-effort wait for the scheduled reset to finish so that the
+ * device is operational before returning. Without this, userspace
+ * (e.g. NetworkManager) may try to open the net device while the
+ * asynchronous reset is still in progress, hitting -EBUSY.
+ */
+ ret = ice_wait_for_reset(pf, secs_to_jiffies(10));
+ if (ret)
+ dev_err(dev, "Wait for reset timed out (10s) during resume: %d\n",
+ ret);
+
return 0;
}
--
2.47.1
^ permalink raw reply related
* [PATCH net 2/4] ice: fix VF interrupts cleanup
From: Tony Nguyen @ 2026-06-30 21:44 UTC (permalink / raw)
To: davem, kuba, pabeni, edumazet, andrew+netdev, netdev
Cc: Dawid Osuchowski, anthony.l.nguyen, stable, Vladimir Medvedkin,
Aleksandr Loktionov, Simon Horman, Patryk Holda
In-Reply-To: <20260630214404.930923-1-anthony.l.nguyen@intel.com>
From: Dawid Osuchowski <dawid.osuchowski@linux.intel.com>
When a virtual function sends an IRQ map command, the PF will set up
interrupts according to that request. However, because these interrupts are
never reset, the next time Virtual Function initializes, the interrupts are
still enabled for a given VF, which leads to performance degradation in
certain cases due to interrupts being unexpectedly enabled and thus causing
interrupt floods.
Cc: stable@vger.kernel.org
Fixes: 1071a8358a28 ("ice: Implement virtchnl commands for AVF support")
Suggested-by: Vladimir Medvedkin <vladimir.medvedkin@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Signed-off-by: Dawid Osuchowski <dawid.osuchowski@linux.intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Tested-by: Patryk Holda <patryk.holda@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
drivers/net/ethernet/intel/ice/ice_vf_lib.c | 27 +++++++++++++++++++
.../ethernet/intel/ice/ice_vf_lib_private.h | 1 +
drivers/net/ethernet/intel/ice/virt/queues.c | 21 +++++++++++++++
3 files changed, 49 insertions(+)
diff --git a/drivers/net/ethernet/intel/ice/ice_vf_lib.c b/drivers/net/ethernet/intel/ice/ice_vf_lib.c
index 27e4acb1620f..7ce8f66eebbf 100644
--- a/drivers/net/ethernet/intel/ice/ice_vf_lib.c
+++ b/drivers/net/ethernet/intel/ice/ice_vf_lib.c
@@ -847,6 +847,30 @@ static void ice_notify_vf_reset(struct ice_vf *vf)
NULL);
}
+/**
+ * ice_reset_interrupts - clear all queue interrupt configuration for a VSI
+ * @vsi: the VSI whose interrupt registers should be cleared
+ *
+ * Zero the QINT_RQCTL and QINT_TQCTL registers for all allocated queues
+ * in the VSI. This clears the entire register including MSIX_INDX, ITR_INDX,
+ * CAUSE_ENA and NEXTQ fields, unlike ice_vf_dis_rxq_interrupt() which only
+ * clears the CAUSE_ENA bit.
+ */
+void ice_reset_interrupts(struct ice_vsi *vsi)
+{
+ struct ice_pf *pf = vsi->back;
+ struct ice_hw *hw = &pf->hw;
+ int i;
+
+ ice_for_each_alloc_rxq(vsi, i)
+ wr32(hw, QINT_RQCTL(vsi->rxq_map[i]), 0);
+
+ ice_for_each_alloc_txq(vsi, i)
+ wr32(hw, QINT_TQCTL(vsi->txq_map[i]), 0);
+
+ ice_flush(hw);
+}
+
/**
* ice_reset_vf - Reset a particular VF
* @vf: pointer to the VF structure
@@ -918,6 +942,9 @@ int ice_reset_vf(struct ice_vf *vf, u32 flags)
ice_dis_vf_qs(vf);
+ /* cleanup interrupt registers */
+ ice_reset_interrupts(vsi);
+
/* Call Disable LAN Tx queue AQ whether or not queues are
* enabled. This is needed for successful completion of VFR.
*/
diff --git a/drivers/net/ethernet/intel/ice/ice_vf_lib_private.h b/drivers/net/ethernet/intel/ice/ice_vf_lib_private.h
index 5392b0404986..321d29c25b7c 100644
--- a/drivers/net/ethernet/intel/ice/ice_vf_lib_private.h
+++ b/drivers/net/ethernet/intel/ice/ice_vf_lib_private.h
@@ -26,6 +26,7 @@
void ice_initialize_vf_entry(struct ice_vf *vf);
void ice_deinitialize_vf_entry(struct ice_vf *vf);
void ice_dis_vf_qs(struct ice_vf *vf);
+void ice_reset_interrupts(struct ice_vsi *vsi);
int ice_check_vf_init(struct ice_vf *vf);
enum virtchnl_status_code ice_err_to_virt_err(int err);
struct ice_port_info *ice_vf_get_port_info(struct ice_vf *vf);
diff --git a/drivers/net/ethernet/intel/ice/virt/queues.c b/drivers/net/ethernet/intel/ice/virt/queues.c
index 31be2f76181c..431c9c546b04 100644
--- a/drivers/net/ethernet/intel/ice/virt/queues.c
+++ b/drivers/net/ethernet/intel/ice/virt/queues.c
@@ -224,6 +224,24 @@ void ice_vf_ena_rxq_interrupt(struct ice_vsi *vsi, u32 q_idx)
wr32(hw, QINT_RQCTL(pfq), reg | QINT_RQCTL_CAUSE_ENA_M);
}
+/**
+ * ice_vf_dis_rxq_interrupt - disable Rx queue interrupt via QINT_RQCTL
+ * @vsi: VSI of the VF to configure
+ * @q_idx: VF queue index used to determine the queue in the PF's space
+ */
+static void ice_vf_dis_rxq_interrupt(struct ice_vsi *vsi, u32 q_idx)
+{
+ struct ice_hw *hw = &vsi->back->hw;
+ u32 pfq = vsi->rxq_map[q_idx];
+ u32 reg;
+
+ reg = rd32(hw, QINT_RQCTL(pfq));
+ reg &= ~QINT_RQCTL_CAUSE_ENA_M;
+ wr32(hw, QINT_RQCTL(pfq), reg);
+
+ ice_flush(hw);
+}
+
/**
* ice_vc_ena_qs_msg
* @vf: pointer to the VF info
@@ -416,6 +434,8 @@ int ice_vc_dis_qs_msg(struct ice_vf *vf, u8 *msg)
goto error_param;
}
+ for_each_set_bit(vf_q_id, &q_map, ICE_MAX_RSS_QS_PER_VF)
+ ice_vf_dis_rxq_interrupt(vsi, vf_q_id);
bitmap_zero(vf->rxq_ena, ICE_MAX_RSS_QS_PER_VF);
} else if (q_map) {
for_each_set_bit(vf_q_id, &q_map, ICE_MAX_RSS_QS_PER_VF) {
@@ -436,6 +456,7 @@ int ice_vc_dis_qs_msg(struct ice_vf *vf, u8 *msg)
goto error_param;
}
+ ice_vf_dis_rxq_interrupt(vsi, vf_q_id);
/* Clear enabled queues flag */
clear_bit(vf_q_id, vf->rxq_ena);
}
--
2.47.1
^ permalink raw reply related
* [PATCH net 3/4] idpf: handle NULL adev in idpf_idc_vdev_mtu_event
From: Tony Nguyen @ 2026-06-30 21:44 UTC (permalink / raw)
To: davem, kuba, pabeni, edumazet, andrew+netdev, netdev
Cc: David Carlier, anthony.l.nguyen, tatyana.e.nikolova, joshua.a.hay,
horms, stable, Aleksandr Loktionov, Jakub Andrysiak
In-Reply-To: <20260630214404.930923-1-anthony.l.nguyen@intel.com>
From: David Carlier <devnexen@gmail.com>
idpf_idc_vport_dev_ctrl(adapter, false) clears vport->vdev_info->adev
to NULL but keeps vport->vdev_info itself. An MTU change after that
calls idpf_idc_vdev_mtu_event(), which dereferences vdev_info->adev for
device_lock() before reaching the (!adev || ...) check.
Cache vdev_info->adev once with READ_ONCE() and bail out if NULL before
locking. Use the cached pointer on both the lock and unlock paths so
the unlock matches the device actually acquired and cannot re-fetch a
NULL slot.
Fixes: ed6e1c8796a4 ("idpf: implement IDC vport aux driver MTU change handler")
Cc: stable@vger.kernel.org
Signed-off-by: David Carlier <devnexen@gmail.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Tested-by: Jakub Andrysiak <jakub.andrysiak@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
drivers/net/ethernet/intel/idpf/idpf_idc.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/idpf/idpf_idc.c b/drivers/net/ethernet/intel/idpf/idpf_idc.c
index b7d6b08fc89e..9f764135507c 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_idc.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_idc.c
@@ -162,9 +162,12 @@ void idpf_idc_vdev_mtu_event(struct iidc_rdma_vport_dev_info *vdev_info,
set_bit(event_type, event.type);
- device_lock(&vdev_info->adev->dev);
- adev = vdev_info->adev;
- if (!adev || !adev->dev.driver)
+ adev = READ_ONCE(vdev_info->adev);
+ if (!adev)
+ return;
+
+ device_lock(&adev->dev);
+ if (!adev->dev.driver)
goto unlock;
iadrv = container_of(adev->dev.driver,
struct iidc_rdma_vport_auxiliary_drv,
@@ -172,7 +175,7 @@ void idpf_idc_vdev_mtu_event(struct iidc_rdma_vport_dev_info *vdev_info,
if (iadrv->event_handler)
iadrv->event_handler(vdev_info, &event);
unlock:
- device_unlock(&vdev_info->adev->dev);
+ device_unlock(&adev->dev);
}
/**
--
2.47.1
^ permalink raw reply related
* [PATCH net 4/4] igbvf: Fix leak in TX DMA error cleanup
From: Tony Nguyen @ 2026-06-30 21:44 UTC (permalink / raw)
To: davem, kuba, pabeni, edumazet, andrew+netdev, netdev
Cc: Matt Vollrath, anthony.l.nguyen, stable
In-Reply-To: <20260630214404.930923-1-anthony.l.nguyen@intel.com>
From: Matt Vollrath <tactii@gmail.com>
If an error is encountered while mapping TX buffers, the driver should
unmap any buffers already mapped for that skb.
Because count is incremented before each frag mapping, it will always
match the correct number of unmappings needed when dma_error is reached.
Decrementing count before the while loop in dma_error causes an
off-by-one error. If any mapping was successful before an unsuccessful
mapping, exactly one DMA mapping (the head) would leak.
This bug was introduced by a 2010 fix for an endless loop in dma_error.
All other affected drivers have already been fixed.
Fixes: c1fa347f20f1 ("e1000/e1000e/igb/igbvf/ixgb/ixgbe: Fix tests of unsigned in *_tx_map()")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-4-7-opus
Signed-off-by: Matt Vollrath <tactii@gmail.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
drivers/net/ethernet/intel/igbvf/netdev.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c b/drivers/net/ethernet/intel/igbvf/netdev.c
index 0a3d0a1cba43..c686ee120a14 100644
--- a/drivers/net/ethernet/intel/igbvf/netdev.c
+++ b/drivers/net/ethernet/intel/igbvf/netdev.c
@@ -2190,8 +2190,6 @@ static inline int igbvf_tx_map_adv(struct igbvf_adapter *adapter,
buffer_info->time_stamp = 0;
buffer_info->length = 0;
buffer_info->mapped_as_page = false;
- if (count)
- count--;
/* clear timestamp and dma mappings for remaining portion of packet */
while (count--) {
--
2.47.1
^ permalink raw reply related
* Re: [PATCH v6 1/9] block: partitions: of: Skip child nodes without reg property
From: Rob Herring @ 2026-06-30 21:45 UTC (permalink / raw)
To: Loic Poulain
Cc: Ulf Hansson, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Jens Axboe, Johannes Berg, Jeff Johnson,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Balakrishna Godavarthi, Rocky Liao, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Srinivas Kandagatla,
Andrew Lunn, Heiner Kallweit, Russell King, Saravana Kannan,
Christian Marangi, linux-mmc, devicetree, linux-kernel,
linux-arm-msm, linux-block, linux-wireless, ath10k,
linux-bluetooth, netdev, daniel, stable, Bartosz Golaszewski
In-Reply-To: <CAFEp6-163adAq8-H_pCzGnq+Fo4jpyKGs6Jv25j3fSpZg3COjQ@mail.gmail.com>
On Tue, Jun 30, 2026 at 2:59 PM Loic Poulain
<loic.poulain@oss.qualcomm.com> wrote:
>
> Hi Rob,
>
> On Tue, Jun 30, 2026 at 8:02 PM Rob Herring <robh@kernel.org> wrote:
> >
> > On Mon, Jun 29, 2026 at 10:55:20AM +0200, Loic Poulain wrote:
> > > Child nodes of a fixed-partitions node are not necessarily partition
> > > entries, for example an nvmem-layout node has no reg property. The
> > > current code passes a NULL reg pointer and uninitialized len to the
> > > length check, which can result in a kernel panic or silent failure to
> > > register any partitions.
> >
> > That does not sound right to me. A fixed-partitions node should only be
> > defining partitions with address ranges. I would expect a partition node
> > could be nvmem-layout, but not the whole address range. If you wanted
> > the latter, then just do:
> >
> > partitions {
> > ...
> > };
> >
> > nvmem-layout {
> > ...
> > };
>
> In our case, the nvmem-layout needs to be associated with a specific
> eMMC hardware partition, nvmem cells can be a simple sub-range within
> the global eMMC, each hardware partition (boot0, boot1, user...)
> having its own address spaces.
>
> That said, your point about not abusing fixed-partitions is valid. I
> initially dropped the compatible = "fixed-partitions" from the
> partitions-boot1 node when it only carries an nvmem-layout and no
> actual partition entries, making it a plain named container node. But
> it's a bit fragile if we want to support both nvmem-layout and
> fixed-partitions.
>
> Regarding your expectation of a partition node being a nvmem-layout,
> do you mean that the nvmem-layout should live under a fixed-partitions
> node? Something along these lines:
>
> partitions-boot1 {
> compatible = "fixed-partitions";
> #address-cells = <1>;
> #size-cells = <1>;
>
> nvmem@4400 {
partition@4400
> reg = <0x4400 0x1000>;
>
> nvmem-layout {
> compatible = "fixed-layout";
> #address-cells = <1>;
> #size-cells = <1>;
>
> wifi_mac_addr: mac-addr@0 {
> compatible = "mac-base";
> reg = <0x0 0x6>;
> #nvmem-cell-cells = <1>;
> };
> [...]
Either this or replacing "fixed-partitions" with "fixed-layout" if you
want to make the whole boot1 partition nvmem-layout looks like the
right way to me.
> That makes some sense, this would require extra work for the
> emmc/block layer to also associate fwnodes with logical partitions,
> not just the whole disk/hw (hw part), Is that the direction you'd like
> us to go?
Yes.
> Also, Note that regardless of which approach we settle on, this
> specific fix/patch remains necessary to validate the partition node
> and prevent NULL-deref.
Fair enough, though the reasoning for it would be different and
perhaps should give a warning.
Rob
^ permalink raw reply
* Re: [PATCH net] mac802154: wait for RCU readers when removing interfaces
From: Kuniyuki Iwashima @ 2026-06-30 21:46 UTC (permalink / raw)
To: alhouseenyousef
Cc: alex.aring, davem, edumazet, horms, kuba, linux-kernel,
linux-wpan, marcel, miquel.raynal, netdev, pabeni, stable, stefan,
syzbot+36256deb69a588e9290e
In-Reply-To: <20260630211808.50440-1-alhouseenyousef@gmail.com>
From: Yousef Alhouseen <alhouseenyousef@gmail.com>
Date: Tue, 30 Jun 2026 23:18:08 +0200
> Queue wake, stop, and disable paths walk local->interfaces under RCU.
> The bulk hardware teardown path removes entries with list_del() and
The problematic part is list_del(), not unregister_netdevice().
> immediately unregisters their netdevices, so an asynchronous transmit
not immediately, unregister_netdevice() waits inflight RCU readers.
So, synchronize_rcu() should be unnecessary.
(Same remark for ieee802154_if_remove())
> completion can follow a poisoned list node in ieee802154_wake_queue().
>
> Match ieee802154_if_remove(): use list_del_rcu() and wait for existing
> readers before unregistering each interface.
>
> Fixes: 592dfbfc72f5 ("mac820154: move interface unregistration into iface")
> Reported-by: syzbot+36256deb69a588e9290e@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=36256deb69a588e9290e
> Cc: stable@vger.kernel.org
> Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
> ---
> net/mac802154/iface.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/mac802154/iface.c b/net/mac802154/iface.c
> index 000be60d9580..73d82a015184 100644
> --- a/net/mac802154/iface.c
> +++ b/net/mac802154/iface.c
> @@ -703,7 +703,8 @@ void ieee802154_remove_interfaces(struct ieee802154_local *local)
>
> mutex_lock(&local->iflist_mtx);
> list_for_each_entry_safe(sdata, tmp, &local->interfaces, list) {
> - list_del(&sdata->list);
> + list_del_rcu(&sdata->list);
> + synchronize_rcu();
>
> unregister_netdevice(sdata->dev);
> }
> --
^ permalink raw reply
* Re: [PATCH net-next v7 2/4] net: phy: c45: add setup and read master/slave helpers
From: Andrew Lunn @ 2026-06-30 22:03 UTC (permalink / raw)
To: javen
Cc: hkallweit1, linux, davem, edumazet, kuba, pabeni, freddy_gu, nb,
netdev, linux-kernel, daniel, vladimir.oltean, nic_swsd
In-Reply-To: <20260629064718.1349-3-javen_xu@realsil.com.cn>
On Mon, Jun 29, 2026 at 02:47:16PM +0800, javen wrote:
> From: Javen Xu <javen_xu@realsil.com.cn>
>
> This patch adds two static helpers in drivers/net/phy/phy-c45.c to
> configure and read back master-slave roles for non BASE-T1 Clause 45
> PHYs via the 10GBASE-T AN control/status registers.
> These helpers are wired into genphy_c45_config_aneg() and
> genphy_c45_read_status(). This changes the observable ethtool output
> for drivers using the generic c45 read path.
>
> Signed-off-by: Javen Xu <javen_xu@realsil.com.cn>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next v7 3/4] net: phy: realtek: add support for RTL8261C_CG
From: Andrew Lunn @ 2026-06-30 22:05 UTC (permalink / raw)
To: javen
Cc: hkallweit1, linux, davem, edumazet, kuba, pabeni, freddy_gu, nb,
netdev, linux-kernel, daniel, vladimir.oltean, nic_swsd
In-Reply-To: <20260629064718.1349-4-javen_xu@realsil.com.cn>
On Mon, Jun 29, 2026 at 02:47:17PM +0800, javen wrote:
> From: Javen Xu <javen_xu@realsil.com.cn>
>
> This patch adds support for Realtek phy chip RTL8261C_CG. Its PHY ID is
> 0x001cc898.
> This patch introduces a distinct family of handlers (probe, get_features,
> config_aneg, read_status, config_intr, handle_interrupt).
>
> Signed-off-by: Javen Xu <javen_xu@realsil.com.cn>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH 03/13] mips: replace linux/gpio.h inclusions
From: Philippe Mathieu-Daudé @ 2026-06-30 22:08 UTC (permalink / raw)
To: Arnd Bergmann, linux-gpio
Cc: Arnd Bergmann, Bartosz Golaszewski, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Greg Ungerer, Thomas Bogendoerfer,
Hauke Mehrtens, Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Linus Walleij, Dmitry Torokhov,
Jakub Kicinski, Paolo Abeni, Dominik Brodowski, linux-kernel,
linux-arm-kernel, linux-samsung-soc, patches, linux-m68k,
linux-mips, linux-sh, linux-input, linux-media, netdev,
linux-sunxi, linux-phy, linux-rockchip, linux-sound
In-Reply-To: <20260629132633.1300009-4-arnd@kernel.org>
On 29/6/26 15:26, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> linux/gpio.h should no longer be used, convert these instead to
> either linux/gpio/consumer.h or linux/gpio/legacy.h as needed.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/mips/alchemy/board-xxs1500.c | 2 +-
> arch/mips/alchemy/devboards/db1000.c | 2 +-
> arch/mips/alchemy/devboards/db1200.c | 2 +-
> arch/mips/alchemy/devboards/db1550.c | 2 +-
> arch/mips/bcm47xx/workarounds.c | 2 +-
> arch/mips/bcm63xx/boards/board_bcm963xx.c | 1 +
> arch/mips/include/asm/mach-bcm63xx/board_bcm963xx.h | 2 +-
> arch/mips/txx9/rbtx4927/setup.c | 2 +-
> 8 files changed, 8 insertions(+), 7 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 04/13] sh: replace linux/gpio.h inclusions
From: Philippe Mathieu-Daudé @ 2026-06-30 22:08 UTC (permalink / raw)
To: Arnd Bergmann, linux-gpio
Cc: Arnd Bergmann, Bartosz Golaszewski, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Greg Ungerer, Thomas Bogendoerfer,
Hauke Mehrtens, Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Linus Walleij, Dmitry Torokhov,
Jakub Kicinski, Paolo Abeni, Dominik Brodowski, linux-kernel,
linux-arm-kernel, linux-samsung-soc, patches, linux-m68k,
linux-mips, linux-sh, linux-input, linux-media, netdev,
linux-sunxi, linux-phy, linux-rockchip, linux-sound
In-Reply-To: <20260629132633.1300009-5-arnd@kernel.org>
On 29/6/26 15:26, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> linux/gpio.h should no longer be used, convert these instead to
> linux/gpio/legacy.h for the sh boards using the legacy interfaces,
> or remove it where it is not needed at all.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/sh/boards/board-magicpanelr2.c | 2 +-
> arch/sh/boards/board-sh7757lcr.c | 2 +-
> arch/sh/boards/board-urquell.c | 2 +-
> arch/sh/boards/mach-ap325rxa/setup.c | 2 +-
> arch/sh/boards/mach-ecovec24/setup.c | 2 +-
> arch/sh/boards/mach-highlander/pinmux-r7785rp.c | 2 +-
> arch/sh/boards/mach-kfr2r09/lcd_wqvga.c | 2 +-
> arch/sh/boards/mach-kfr2r09/setup.c | 2 +-
> arch/sh/boards/mach-migor/lcd_qvga.c | 2 +-
> arch/sh/boards/mach-migor/setup.c | 2 +-
> arch/sh/boards/mach-rsk/devices-rsk7203.c | 2 +-
> arch/sh/boards/mach-rsk/devices-rsk7269.c | 1 -
> arch/sh/boards/mach-se/7724/setup.c | 2 +-
> arch/sh/include/mach-common/mach/magicpanelr2.h | 2 --
> arch/sh/kernel/cpu/sh4a/setup-shx3.c | 2 +-
> 15 files changed, 13 insertions(+), 16 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH net-next v7 4/4] net: phy: realtek: load firmware for RTL8261C_CG
From: Andrew Lunn @ 2026-06-30 22:09 UTC (permalink / raw)
To: javen
Cc: hkallweit1, linux, davem, edumazet, kuba, pabeni, freddy_gu, nb,
netdev, linux-kernel, daniel, vladimir.oltean, nic_swsd
In-Reply-To: <20260629064718.1349-5-javen_xu@realsil.com.cn>
On Mon, Jun 29, 2026 at 02:47:18PM +0800, javen wrote:
> From: Javen Xu <javen_xu@realsil.com.cn>
>
> This patch adds support for loading firmware. Download some parameters
> for RTL8261C_CG.
>
> Signed-off-by: Javen Xu <javen_xu@realsil.com.cn>
> ---
> Changes in v2:
> - remove __pack, struct rtl8261x_fw_header and rtl8261x_fw_entry will not pad
> - reverse xmas tree for some definition
> - add explanation on rtl_phy_write_mmd_bits()
>
> Changes in v3:
> - add struct rtl8261x_priv
>
> Changes in v4:
> - add struct device *dev
>
> Changes in v5:
> - no changes
>
> Changes in v6:
> - replace rtl_phy_write_mmd_bits with phy_modify_mmd, keep mdio lock
> - check msb and lsb at the beginning of rtl8261x_fw_execute_entry()
> - add comments on rtl8261x_config_init()
>
> Changes in v7:
> - no changes
> ---
> drivers/net/phy/realtek/realtek_main.c | 220 +++++++++++++++++++++++++
> 1 file changed, 220 insertions(+)
>
> diff --git a/drivers/net/phy/realtek/realtek_main.c b/drivers/net/phy/realtek/realtek_main.c
> index ef3700894ebf..bf7bc19fb44c 100644
> --- a/drivers/net/phy/realtek/realtek_main.c
> +++ b/drivers/net/phy/realtek/realtek_main.c
> @@ -8,7 +8,9 @@
> * Copyright (c) 2004 Freescale Semiconductor, Inc.
> */
> #include <linux/bitops.h>
> +#include <linux/crc32.h>
> #include <linux/ethtool_netlink.h>
> +#include <linux/firmware.h>
> #include <linux/of.h>
> #include <linux/phy.h>
> #include <linux/pm_wakeirq.h>
> @@ -281,6 +283,42 @@
> RTL8261X_INT_ALDPS_CHG | \
> RTL8261X_INT_JABBER)
>
> +#define FW_MAIN_MAGIC 0x52544C38
> +#define FW_SUB_MAGIC_8261C 0x32363143
> +#define RTL8261X_POLL_TIMEOUT_MS 100
> +
> +#define RTL8261C_CE_FW_NAME "rtl_nic/rtl8261c.bin"
> +MODULE_FIRMWARE(RTL8261C_CE_FW_NAME);
> +
> +enum rtl8261x_fw_op {
> + OP_WRITE = 0x00, /* Write */
> + OP_POLL = 0x02, /* Polling */
> +};
> +
> +struct rtl8261x_fw_header {
> + __le32 main_magic; /* Main magic number 0x52544C38 ("RTL8") */
> + __le32 sub_magic; /* Sub magic number */
> + __le16 version_major; /* Major version */
> + __le16 version_minor; /* Minor version */
> + __le16 num_entries; /* Number of entries */
> + __le16 reserved; /* Reserved */
> + __le32 crc32; /* CRC32 checksum */
> +};
> +
> +struct rtl8261x_fw_entry {
> + __u8 type; /* Operation type (OP_*) */
> + __u8 dev; /* MMD device */
> + __le16 addr; /* Register address */
> + __u8 msb; /* MSB bit position */
> + __u8 lsb; /* LSB bit position */
> + __le16 value; /* Value to write/compare */
> + __le16 timeout_ms; /* Poll timeout in milliseconds */
> + __u8 poll_set; /* Poll for set (1) or clear (0) */
> + __u8 reserved; /* Reserved */
> +};
Are there other devices which need firmware download? Do they use the
same header? I'm just wondering if this will be reused by other
devices?
Andrew
^ permalink raw reply
* Re: [PATCH 13/13] gpiolib: remove linux/gpio.h
From: Philippe Mathieu-Daudé @ 2026-06-30 22:09 UTC (permalink / raw)
To: Arnd Bergmann, linux-gpio
Cc: Arnd Bergmann, Bartosz Golaszewski, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Greg Ungerer, Thomas Bogendoerfer,
Hauke Mehrtens, Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Linus Walleij, Dmitry Torokhov,
Jakub Kicinski, Paolo Abeni, Dominik Brodowski, linux-kernel,
linux-arm-kernel, linux-samsung-soc, patches, linux-m68k,
linux-mips, linux-sh, linux-input, linux-media, netdev,
linux-sunxi, linux-phy, linux-rockchip, linux-sound
In-Reply-To: <20260629132633.1300009-14-arnd@kernel.org>
On 29/6/26 15:26, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> After all other drivers have converted to linux/gpio/consumer.h
> or linux/gpio/legacy.h, remove the final leftover bits here.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> MAINTAINERS | 1 -
> drivers/gpio/TODO | 4 +---
> drivers/gpio/gpiolib-cdev.c | 2 +-
> drivers/gpio/gpiolib-legacy.c | 3 +--
> drivers/gpio/gpiolib.c | 2 +-
> include/linux/gpio.h | 22 ----------------------
> 6 files changed, 4 insertions(+), 30 deletions(-)
> delete mode 100644 include/linux/gpio.h
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox