* Re: [PATCH net] net: lapbether: handle NETDEV_PRE_TYPE_CHANGE
From: Eric Dumazet @ 2026-04-02 1:11 UTC (permalink / raw)
To: David S . Miller, Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, Andrew Lunn, netdev, eric.dumazet,
syzbot+d8c285748fa7292580a9
In-Reply-To: <20260401135304.3629615-1-edumazet@google.com>
On Wed, Apr 1, 2026 at 6:53 AM Eric Dumazet <edumazet@google.com> wrote:
>
> lapbeth_data_transmit() expects the underlying device type
> to be ARPHRD_ETHER.
>
> Returning NOTIFY_BAD from lapbeth_device_event() makes sure
> bonding driver can not break this expectation.
>
> Fixes: 872254dd6b1f ("net/bonding: Enable bonding to enslave non ARPHRD_ETHER")
> Reported-by: syzbot+d8c285748fa7292580a9@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/netdev/69cd22a1.050a0220.70c3a.0002.GAE@google.com/T/#u
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> drivers/net/wan/lapbether.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/wan/lapbether.c b/drivers/net/wan/lapbether.c
> index f357a7ac70ac4756967730fa61c07258b4b3ac00..5c91160dd68cc1dfa4308d38fb111032206fae75 100644
> --- a/drivers/net/wan/lapbether.c
> +++ b/drivers/net/wan/lapbether.c
> @@ -473,6 +473,9 @@ static int lapbeth_device_event(struct notifier_block *this,
> if (lapbeth)
> lapbeth_free_device(lapbeth);
> break;
> + case NETDEV_PRE_TYPE_CHANGE:
> + /* Our underlying device type must not change. */
> + return NOTIFY_BAD;
I will send a v2, we need to guard this with lapbeth_get_x25_dev(dev)
pw-bot: changes-requested
^ permalink raw reply
* Re: [PATCH net-next] net: phy: bcm84881: add LED framework support for BCM84891/BCM84892
From: Andrew Lunn @ 2026-04-02 1:23 UTC (permalink / raw)
To: Daniel Wagner
Cc: netdev, Florian Fainelli, bcm-kernel-feedback-list,
Heiner Kallweit, Russell King, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
In-Reply-To: <20260401114931.3091818-1-wagner.daniel.t@gmail.com>
On Wed, Apr 01, 2026 at 12:49:31PM +0100, Daniel Wagner wrote:
> Expose LED1 and LED2 pins via the PHY LED framework. Each pin has a
> source mask (MASK_LOW + MASK_EXT registers) selecting which hardware
> events light it, plus a CTL field in the shared 0xA83B register
> (RMW; LED4 is firmware-controlled per the datasheet).
>
> Hardware can offload per-speed link triggers (1000/2500/5000/10000),
> RX/TX activity, and force-on. LINK_100 is accepted only alongside
> LINK_1000: source bit 4 lights at both speeds and 100-alone isn't
> representable, so the unrepresentable case falls to software.
>
> The chip has five LED pins; only LED1/LED2 are exposed here as those
> are the only ones characterized on tested hardware. LED4 is firmware-
> controlled regardless of strap configuration.
>
> Tested on TRENDnet TEG-S750 (LED1/LED2 wired to an antiparallel
> bicolor LED): brightness_set via sysfs; netdev trigger offloaded=1
> with amber lit at 100M/1G/2.5G and green lit at 10G via respective
> link_* modes; LED off immediately on cable unplug with no software
> involvement.
>
> Signed-off-by: Daniel Wagner <wagner.daniel.t@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next 1/4] tools: ynl: ethtool: use doit instead of dumpit for per-device GET
From: Hangbin Liu @ 2026-04-02 1:26 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Donald Hunter, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Andrew Lunn, netdev, linux-kernel
In-Reply-To: <20260401175117.1e4a5e6c@kernel.org>
On Wed, Apr 01, 2026 at 05:51:17PM -0700, Jakub Kicinski wrote:
> On Wed, 1 Apr 2026 07:21:54 +0000 Hangbin Liu wrote:
> > On Tue, Mar 31, 2026 at 06:50:28PM -0700, Jakub Kicinski wrote:
> > > On Tue, 31 Mar 2026 11:56:11 +0800 Hangbin Liu wrote:
> > > > +++ b/tools/net/ynl/pyynl/ethtool.py
> > >
> > > We have converted all the samples to selftests so this script is
> > > the last piece of random "PoC" code we still have laying around.
> > > Should we also move it to tests/ ?
> > >
> > > If there's a reason to keep it as is -- could you please add that reason
> > > at the top of the file for my future self? I'm pretty sure I already
> > > questioned this script in the past ;)
> >
> > I have no objection to this. Will you keep it as it is when moving it to
> > tests/ ? Should I wait for your moving first?
>
> Would you mind moving it as part of your series?
OK, I will do it.
Thanks
Hangbin
^ permalink raw reply
* Re: [PATCH net-next 3/4] ethtool: strset: check nla_len overflow before nla_nest_end
From: Hangbin Liu @ 2026-04-02 1:30 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Donald Hunter, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Andrew Lunn, netdev, linux-kernel
In-Reply-To: <20260401174956.1e526940@kernel.org>
On Wed, Apr 01, 2026 at 05:49:56PM -0700, Jakub Kicinski wrote:
> On Wed, 1 Apr 2026 07:27:40 +0000 Hangbin Liu wrote:
> > On Tue, Mar 31, 2026 at 06:46:37PM -0700, Jakub Kicinski wrote:
> > > On Tue, 31 Mar 2026 11:56:13 +0800 Hangbin Liu wrote:
> > > > + if (skb_tail_pointer(skb) - (unsigned char *)strings_attr > U16_MAX)
> > > > + goto nla_put_failure;
> > >
> > > bit ugly, let's add a variant of nla_nest_end() which can return
> > > an error on overflow (without the warning from patch 4) ?
> >
> > I was tried to not touch nla_nest_end() as it is used everywhere. But it makes
> > sense to me to add a new function to check this. I'm not very good at naming,
> > maybe `nla_nest_end_validate()` ? Or any other name if you have?
>
> I was thinking nla_nest_end_check() to match the __must_check
> attribute. But I also like nla_nest_end_safe()
> _validate() is a little long but anything <=5 chars is fine.
OK, I will use nla_nest_end_safe() until we have a better name.
^ permalink raw reply
* Re: [PATCH bpf v3 5/5] bpf, sockmap: Adapt for af_unix-specific lock
From: Martin KaFai Lau @ 2026-04-02 1:34 UTC (permalink / raw)
To: Michal Luczaj
Cc: Jiayuan Chen, John Fastabend, Jakub Sitnicki, Eric Dumazet,
Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn, David S. Miller,
Jakub Kicinski, Simon Horman, Yonghong Song, Andrii Nakryiko,
Alexei Starovoitov, Daniel Borkmann, Eduard Zingerman, Song Liu,
Yonghong Song, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Shuah Khan, Cong Wang, netdev, bpf, linux-kernel, linux-kselftest
In-Reply-To: <08c824b0-cfbb-40ca-b976-9fbd41e5e855@rbox.co>
On Wed, 01 Apr 2026 00:43:58 +0200, Michal Luczaj wrote:
> On 3/31/26 02:20, Martin KaFai Lau wrote:
> > On 3/30/26 4:03 PM, Michal Luczaj wrote:
> >> On 3/26/26 07:26, Martin KaFai Lau wrote:
> >>> On 3/15/26 4:58 PM, Michal Luczaj wrote:
> >>>>> Beside, from looking at the may_update_sockmap(), I don't know if it is
> >>>>> even doable (or useful) to bpf_map_update_elem(unix_sk) in
> >>>>> tc/flow_dissector/xdp. One possible path is the SOCK_FILTER when looking
> >>>>> at unix_dgram_sendmsg() => sk_filter(). It was not the original use case
> >>>>> when the bpf_map_update_elem(sockmap) support was added iirc.
> >>>>
> >>>> What about a situation when unix_sk is stored in a sockmap, then tc prog
> >>>> looks it up and invokes bpf_map_update_elem(unix_sk)? I'm not sure it's
> >>>> useful, but seems doable.
> >>>
> >>> [ Sorry for the late reply ]
> >>>
> >>> It is a bummer that the bpf_map_update_elem(unix_sk) path is possible
> >>> from tc :(
> >>>
> >>> Then unix_state_lock() in its current form cannot be safely acquired in
> >>> sock_map_update_elem(). It is currently a spin_lock() instead of
> >>> spin_lock_bh().
> >>
> >> Is there a specific deadlock you have in your mind?
> >
> > e.g. unix_stream_connect() is taking unix_state_lock(). Can a tc's
> > ingress bpf prog call unix_state_lock()?
>
> Ah, right, that's the problem, thanks for explaining.
>
> But, as I've asked in the parallel thread, do we really need to take the
> unix_state_lock() in sock_map_update_elem()? Taking it in
> sock_map_update_elem_sys() fixes the null-ptr-deref and does not lead to a
> deadlock. Taking unix_state_lock() in sock_map_update_elem() seems
> unnecessary. Well, at least under the assumption progs can only access
> unix_sk via the sockmap lookup.
right, sock_map_update_elem_sys() should be safe to take
unix_state_lock().
If it is fixed by testing unix_peer(), is the TCPF_ESTABLISHED test
in sock_map_sk_state_allowed() still useful and needed? Also,
please explain in detail in the commit message why testing for NULL
without unix_state_lock() is enough. For example, for the BPF iterator on
sock_map, my understanding is that unix_release_sock() can still happen
while the BPF iterator is iterating over a unix_sock. I guess a future
unix_state_lock() in the iterator's seq_show() should be useful.
It will also be useful to mention what was discovered about TC + lookup
+ update_elem(&sock_map, ...) and why it is not safe to take
unix_state_lock() in that path. Thanks.
>
> >> ...
> >> And sock_{map,hash}_seq_show() (being a part of bpf iter machinery) needs
> >> to take lock_sock() just as well? Would that require a special-casing
> >> (unix_state_lock()) for af_unix?
> >
> > I would think so for lock_sock() considering the current bh_lock_sock
> > without !sock_owned_by_user() usage is incorrect in
> > sock_map_update_elem(). [ this probably should be a separate issue for
> > another patch ]
>
> All right, leaving that for later.
>
> > Some more side-tracking... from looking at the code, the bpf_iter of
> > sock_{map,hash} can do bpf_map_lookup_elem(&sock_map, ...). This
> > bpr_iter program probably will be failed to load because the
> > bpf_sk_release() is not available.
>
> I think ability to bpf_map_lookup_elem(sockmap) was added way before bpf
> iter in
> https://lore.kernel.org/bpf/20200429181154.479310-2-jakub@cloudflare.com/
> and iter "allows" it somewhat accidentally. Would you rather have it
> explicitly dropped?
It is fine to leave it as is. It would be a bit nicer to reject map_lookup
on sockmap instead of giving the confusing error that bpf_sk_release
is not available. That is for another day. I was just wondering what else
could go wrong with map_lookup.
^ permalink raw reply
* Re: [PATCH v2] ibmvnic: fix OOB array access in ibmvnic_xmit on queue count reduction
From: Jakub Kicinski @ 2026-04-02 1:43 UTC (permalink / raw)
To: Tyllis Xu
Cc: haren, ricklind, nnac123, sukadev, davem, pabeni, edumazet,
andrew+netdev, netdev, linux-kernel, stable, ychen, Yuhao Jiang
In-Reply-To: <20260401050845.1388145-1-LivelyCarpet87@gmail.com>
On Wed, 1 Apr 2026 00:08:45 -0500 Tyllis Xu wrote:
> When the number of TX queues is reduced (e.g., via ethtool -L), the
> Qdisc layer retains previously enqueued skbs with queue mappings from
> before the reduction. After the reset completes and tx_queues_active is
> set to true, netif_tx_start_all_queues() drains these stale skbs through
> ibmvnic_xmit(). The queue index from skb_get_queue_mapping() may exceed
> the newly allocated array bounds, causing out-of-bounds reads on
> tx_scrq[] and tx_pool[]/tso_pool[].
This should not happen if the interface configures itself correctly, see
https://lore.kernel.org/all/20260106182244.7188a8f6@kernel.org/
Please share are a repro if you have one.
^ permalink raw reply
* Re: [PATCH v3 0/4] gcov: use -fprofile-update=atomic globally to fix concurrent access crashes on GCOV-enabled kernels
From: Jakub Kicinski @ 2026-04-02 1:46 UTC (permalink / raw)
To: Konstantin Khorenko
Cc: Peter Oberparleiter, Mikhail Zaslonko, Thomas Weißschuh,
Steffen Klassert, Herbert Xu, Masahiro Yamada, Josh Poimboeuf,
Vasileios Almpanis, Pavel Tikhomirov, linux-kernel, netdev,
David S . Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
Arnd Bergmann
In-Reply-To: <20260401142020.1434243-1-khorenko@virtuozzo.com>
On Wed, 1 Apr 2026 17:20:16 +0300 Konstantin Khorenko wrote:
> 1. Build fix for CONFIG_GCOV_PROFILE_ALL=y - skb_ext_total_length()
> BUILD_BUG_ON failure:
> https://lore.kernel.org/lkml/20260331165125.959833-1-khorenko@virtuozzo.com/T/#t
>
> 2. Runtime crash fix for zlib inflate_fast() - GCOV counter merging
> with loop induction variables caused out-of-bounds writes on SMP:
> https://lore.kernel.org/lkml/20260330143256.306326-1-khorenko@virtuozzo.com/T/#t
Why are you merging these? The should go via different subsystems.
How do you expect this series to be applied?
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next v3 0/2] net: phy: microchip: add downshift support for LAN88xx
From: Jakub Kicinski @ 2026-04-02 1:48 UTC (permalink / raw)
To: Nicolai Buchwitz; +Cc: netdev, Phil Elwell, Russell King, Andrew Lunn
In-Reply-To: <20260401123848.696766-1-nb@tipi-net.de>
On Wed, 1 Apr 2026 14:38:43 +0200 Nicolai Buchwitz wrote:
> Add standard ETHTOOL_PHY_DOWNSHIFT tunable support for the Microchip
> LAN88xx PHY, following the same pattern used by Marvell and other PHY
> drivers.
Please do not post patches in reply to a previous posting.
Add a lore link to the previous posting in the changelog.
You're submitting quite a lot of patches, it'd be great if
you could give our docs a read before sending more :/
https://www.kernel.org/doc/html/next/process/maintainer-netdev.html
^ permalink raw reply
* Re: [PATCH] stmmac: cleanup dead dependencies on STMMAC_PLATFORM and STMMAC_ETH in Kconfig
From: Jakub Kicinski @ 2026-04-02 1:58 UTC (permalink / raw)
To: Julian Braha
Cc: manabian, davem, peppe.cavallaro, alexandre.torgue,
mcoquelin.stm32, netdev, linux-arm-kernel, linux-kernel
In-Reply-To: <20260331125817.117091-1-julianbraha@gmail.com>
On Tue, 31 Mar 2026 13:58:17 +0100 Julian Braha wrote:
> @@ -53,7 +51,6 @@ config DWMAC_DWC_QOS_ETH
>
> config DWMAC_GENERIC
> tristate "Generic driver for DWMAC"
> - default STMMAC_PLATFORM
> help
This is a default not depends.
As much as I'd love to make stmmac default to y this will probably
break boot for some people..
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net] rds: ib: reject FRMR registration before IB connection is established
From: patchwork-bot+netdevbpf @ 2026-04-02 2:00 UTC (permalink / raw)
To: Weiming Shi
Cc: allison.henderson, davem, edumazet, kuba, pabeni, horms, netdev,
linux-rdma, xmei5
In-Reply-To: <20260330163237.2752440-2-bestswngs@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 31 Mar 2026 00:32:38 +0800 you wrote:
> rds_ib_get_mr() extracts the rds_ib_connection from conn->c_transport_data
> and passes it to rds_ib_reg_frmr() for FRWR memory registration. On a
> fresh outgoing connection, ic is allocated in rds_ib_conn_alloc() with
> i_cm_id = NULL because the connection worker has not yet called
> rds_ib_conn_path_connect() to create the rdma_cm_id. When sendmsg() with
> RDS_CMSG_RDMA_MAP is called on such a connection, the sendmsg path parses
> the control message before any connection establishment, allowing
> rds_ib_post_reg_frmr() to dereference ic->i_cm_id->qp and crash the
> kernel.
>
> [...]
Here is the summary with links:
- [net] rds: ib: reject FRMR registration before IB connection is established
https://git.kernel.org/netdev/net/c/a54ecccfae62
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] net/mlx5: Move command entry freeing outside of spinlock
From: patchwork-bot+netdevbpf @ 2026-04-02 2:00 UTC (permalink / raw)
To: lirongqing
Cc: saeedm, leon, tariqt, mbloch, andrew+netdev, davem, edumazet,
kuba, pabeni, netdev, linux-rdma, linux-kernel
In-Reply-To: <20260331122604.1933-1-lirongqing@baidu.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 31 Mar 2026 08:26:04 -0400 you wrote:
> From: Li RongQing <lirongqing@baidu.com>
>
> Move the kfree() call outside the critical section to reduce lock
> holding time. This aligns with the general principle of minimizing
> work under locks.
>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
>
> [...]
Here is the summary with links:
- [net-next] net/mlx5: Move command entry freeing outside of spinlock
https://git.kernel.org/netdev/net-next/c/2897c697b326
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 v2 net-next] ipv6: move ip6_dst_hoplimit() to net/ipv6/ip6_output.c
From: patchwork-bot+netdevbpf @ 2026-04-02 2:00 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, kuba, pabeni, horms, dsahern, netdev, eric.dumazet,
fmancera, kuniyu
In-Reply-To: <20260331174722.4128061-1-edumazet@google.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 31 Mar 2026 17:47:22 +0000 you wrote:
> Move ip6_dst_hoplimit() to net/ipv6/ip6_output.c so that compiler
> can (auto)inline it from ip6_xmit().
>
> $ scripts/bloat-o-meter -t vmlinux.0 vmlinux.1
> add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-11 (-11)
> Function old new delta
> ip6_xmit 1684 1673 -11
> Total: Before=29655407, After=29655396, chg -0.00%
>
> [...]
Here is the summary with links:
- [v2,net-next] ipv6: move ip6_dst_hoplimit() to net/ipv6/ip6_output.c
https://git.kernel.org/netdev/net-next/c/63081dec9e37
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] ppp: dead code cleanup in Kconfig
From: patchwork-bot+netdevbpf @ 2026-04-02 2:00 UTC (permalink / raw)
To: Julian Braha; +Cc: andrew+netdev, pabeni, davem, kuba, netdev, linux-kernel
In-Reply-To: <20260330213258.13982-1-julianbraha@gmail.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 30 Mar 2026 22:32:58 +0100 you wrote:
> There is already an 'if PPP' condition wrapping several config options
> e.g. PPP_MPPE and PPPOE, making the 'depends on PPP' statement for each of
> these a duplicate dependency (dead code).
>
> I propose leaving the outer 'if PPP...endif' and removing the individual
> 'depends on PPP' statement from each option.
>
> [...]
Here is the summary with links:
- ppp: dead code cleanup in Kconfig
https://git.kernel.org/netdev/net-next/c/4cbcf82e26b6
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 6/6] selftests: drv-net: gro: add a test for bad IPv4 csum
From: Jakub Kicinski @ 2026-04-02 2:10 UTC (permalink / raw)
To: Willem de Bruijn
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, shuah,
willemb, petrm, anubhavsinggh, richardbgobert, linux-kselftest
In-Reply-To: <willemdebruijn.kernel.14f444719030c@gmail.com>
On Wed, 01 Apr 2026 20:28:46 -0400 Willem de Bruijn wrote:
> > /* ip sub-tests - IPv4 only */
> > + } else if (strcmp(testname, "ip_csum") == 0) {
> > + correct_payload[0] = PAYLOAD_LEN;
> > + correct_payload[1] = PAYLOAD_LEN;
> > + printf("bad ip checksum doesn't coalesce: ");
> > + check_recv_pkts(rxfd, correct_payload, 2);
>
> This verifies that a packet with bad csum does not coalesce to a valid
> packet. Perhaps too paranoid but, do you also want to test the reverse
> case?
Will do, easy enough. Tho TBH I can't think of a case where this would
matter. Bad csum pkt must bypass all GRO processing completely right?
Because we don't want a corrupted packet to flush a valid session?
Or you think some implementation may actually feed these packets into
GRO to avoid waiting for a session timeout?
^ permalink raw reply
* Re: [net-next v36] mctp pcc: Implement MCTP over PCC Transport
From: Jeremy Kerr @ 2026-04-02 2:16 UTC (permalink / raw)
To: Adam Young, Matt Johnston, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: netdev, linux-kernel, Sudeep Holla, Jonathan Cameron, Huisong Li
In-Reply-To: <20260330175455.1189845-1-admiyo@os.amperecomputing.com>
Hi Adam,
> Implementation of network driver for
> Management Component Transport Protocol(MCTP)
> over Platform Communication Channel(PCC)
>
> DMTF DSP:0292
> Link: https://www.dmtf.org/sites/default/files/standards/documents/DSP0292_1.0.0WIP50.pdf
>
> The transport mechanism is called Platform Communication Channels (PCC)
> is part of the ACPI spec:
>
> Link: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/14_Platform_Communications_Channel/Platform_Comm_Channel.html
>
> The PCC mechanism is managed via a mailbox implemented at
> drivers/mailbox/pcc.c
>
> MCTP devices are specified via ACPI by entries in DSDT/SSDT and
> reference channels specified in the PCCT. Messages are sent on a type
> 3 and received on a type 4 channel. Communication with other devices
> use the PCC based doorbell mechanism; a shared memory segment with a
> corresponding interrupt and a memory register used to trigger remote
> interrupts.
>
> The shared buffer must be at least 68 bytes long as that is the minimum
> MTU as defined by the MCTP specification.
>
> Unlike the existing PCC Type 2 based drivers, the mssg parameter to
> mbox_send_msg is actively used. The data section of the struct sk_buff
> that contains the outgoing packet is sent to the mailbox, already
> properly formatted as a PCC exctended message.
>
> If the mailbox ring buffer is full, the driver stops the incoming
> packet queues until a message has been sent, freeing space in the
> ring buffer.
>
> When the Type 3 channel outbox receives a txdone response interrupt,
> it consumes the outgoing sk_buff, allowing it to be freed.
>
> Bringing up an interface creates the channel between the network driver
> and the mailbox driver. This enables communication with the remote
> endpoint, to include the receipt of new messages. Bringing down an
> interface removes the channel, and no new messages can be delivered.
> Stopping the interface will leave any packets that are cached in the
> mailbox ringbuffer. They cannot safely be freed until the PCC mailbox
> attempts to deliver them and has removed them from the ring buffer.
>
> PCC is based on a shared buffer and a set of I/O mapped memory locations
> that the Spec calls registers. This mechanism exists regardless of the
> existence of the driver. If the user has the ability to map these
> physical location to virtual locations, they have the ability to drive the
> hardware. Thus, there is a security aspect to this mechanism that extends
> beyond the responsibilities of the operating system.
>
> If the hardware does not expose the PCC in the ACPI table, this device
> will never be enabled. Thus it is only an issue on hardware that does
> support PCC. In that case, it is up to the remote controller to sanitize
> communication; MCTP will be exposed as a socket interface, and userland
> can send any crafted packet it wants. It would also be incumbent on
> the hardware manufacturer to allow the end user to disable MCTP over PCC
> communication if they did not want to expose it.
>
> Signed-off-by: Adam Young <admiyo@os.amperecomputing.com>
No changelogs anymore? This makes things more difficult to review. Just
to be clear, when I mentioned changing to a single-patch series, that
did not mean to throw out the changelog - it's still a key part of
review.
So, for v36, it looks like you have
* added the CONFIG_PCC dependency
* altered the RX min length check to include at least the command and
a MCTP header
* added a RX max-length check
* added a minimum MTU check
* altered the commit message to reflect PCC mailbox free behaviour.
On the latter, could you expand on what happens on close? Does the PCC
channel end up calling tx_done() on each pending TX during the channel
free? I'm not familiar with the PCC paths, but it doesn't look like it
(or the mailbox core) has a case to deal with this on free.
Maybe I am missing something, but could this leak skbs?
[...]
> +static int initialize_MTU(struct net_device *ndev)
> +{
> + struct mctp_pcc_ndev *mctp_pcc_ndev;
> + struct mctp_pcc_mailbox *outbox;
> + struct pcc_mbox_chan *pchan;
> + int mctp_pcc_mtu;
> +
> + mctp_pcc_mtu = MCTP_MIN_MTU;
> + mctp_pcc_ndev = netdev_priv(ndev);
> + outbox = &mctp_pcc_ndev->outbox;
> + pchan = pcc_mbox_request_channel(&outbox->client, outbox->index);
> + if (IS_ERR(pchan))
> + return -1;
> + if (pchan->shmem_size < MCTP_MIN_MTU)
> + return -1;
Looks like this would leak the channel? You may want to shift this check
to after the free_channel().
(but also, should this check also include the size of the pcc header?)
Cheers,
Jeremy
^ permalink raw reply
* Re: [PATCH v2] selftests/bpf: Reject malformed IPv4/IPv6 skb test input
From: Martin KaFai Lau @ 2026-04-02 2:17 UTC (permalink / raw)
To: Sun Jian
Cc: ast, daniel, andrii, eddyz87, song, yonghong.song, john.fastabend,
kpsingh, sdf, haoluo, jolsa, davem, edumazet, kuba, pabeni, horms,
bpf, netdev, linux-kernel, syzbot+619b9ef527f510a57cfc
In-Reply-To: <20260329161751.1914272-1-sun.jian.kdev@gmail.com>
On Mon, Mar 30, 2026 at 12:17:51AM +0800, Sun Jian wrote:
> bpf_prog_test_run_skb() derives skb->protocol from the Ethernet header
> through eth_type_trans(), but it does not verify that the provided
> linear input is long enough to contain the corresponding L3 base header.
>
> This can result in an inconsistent skb being passed to test_run helpers
> such as bpf_skb_adjust_room(), where inferred protocol offsets can lead
> to operating on uninitialized memory, triggering KMSAN errors.
>
> To reject such malformed test input, we check that the linear head is
> sufficiently large to contain the corresponding L3 base header (IPv4
> or IPv6) before running the program.
>
> Reported-by: syzbot+619b9ef527f510a57cfc@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=619b9ef527f510a57cfc
> Signed-off-by: Sun Jian <sun.jian.kdev@gmail.com>
> ---
> v2:
> - Ensured that the linear head is large enough to accommodate the corresponding L3 base header (IPv4 or IPv6), before running the program.
>
> Link: <https://lore.kernel.org/bpf/129d235b04aca276c0a57c7c3646ce48644458cdc85d9b92b25f405e2d58a9ae@mail.kernel.org/>
>
> net/bpf/test_run.c | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/net/bpf/test_run.c b/net/bpf/test_run.c
> index 178c4738e63b..4790bee535b9 100644
> --- a/net/bpf/test_run.c
> +++ b/net/bpf/test_run.c
> @@ -1118,6 +1118,25 @@ int bpf_prog_test_run_skb(struct bpf_prog *prog, const union bpf_attr *kattr,
> skb->protocol = eth_type_trans(skb, dev);
> skb_reset_network_header(skb);
>
> + switch (skb->protocol) {
The implementation is poor.
> + case htons(ETH_P_IP):
> + if (skb_headlen(skb) < sizeof(struct iphdr)) {
> + ret = -EINVAL;
> + goto out;
> + }
> + break;
> +#if IS_ENABLED(CONFIG_IPV6)
> + case htons(ETH_P_IPV6):
> + if (skb_headlen(skb) < sizeof(struct ipv6hdr)) {
> + ret = -EINVAL;
> + goto out;
> + }
> + break;
> +#endif
> + default:
> + break;
> + }
> +
> switch (skb->protocol) {
There is an exact same switch and it has the same check
on skb_headlen(skb).
A selftest is needed. Check if the tests in empty_skb.c need to be
changed also. imo, This can be bpf-next.
pw-bot: cr
> case htons(ETH_P_IP):
> sk->sk_family = AF_INET;
>
> base-commit: cbfffcca2bf0622b601b7eaf477aa29035169184
> --
> 2.43.0
>
^ permalink raw reply
* Re: [GIT PULL] bluetooth 2026-04-01
From: patchwork-bot+netdevbpf @ 2026-04-02 2:20 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: davem, kuba, linux-bluetooth, netdev
In-Reply-To: <20260401205834.2189162-1-luiz.dentz@gmail.com>
Hello:
This pull request was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 1 Apr 2026 16:58:34 -0400 you wrote:
> The following changes since commit 48b3cd69265f346f64b93064723492da46206e9b:
>
> net: stmmac: skip VLAN restore when VLAN hash ops are missing (2026-03-31 19:45:26 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-04-01
>
> [...]
Here is the summary with links:
- [GIT,PULL] bluetooth 2026-04-01
https://git.kernel.org/netdev/net/c/6d6be7070e90
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: pull-request: bpf-next 2026-04-01
From: patchwork-bot+netdevbpf @ 2026-04-02 2:20 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: davem, kuba, edumazet, pabeni, ast, andrii, daniel, martin.lau,
netdev, bpf
In-Reply-To: <20260401233956.4133413-1-martin.lau@linux.dev>
Hello:
This pull request was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 1 Apr 2026 16:39:56 -0700 you wrote:
> Hi David, hi Jakub, hi Paolo, hi Eric,
>
> The following pull-request contains BPF updates for your *net-next* tree.
>
> We've added 2 non-merge commits during the last 2 day(s) which contain
> a total of 3 files changed, 139 insertions(+), 23 deletions(-).
>
> [...]
Here is the summary with links:
- pull-request: bpf-next 2026-04-01
https://git.kernel.org/netdev/net-next/c/6c3dec3e3d20
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 v4 15/15] rxrpc: fix reference count leak in rxrpc_server_keyring()
From: Jakub Kicinski @ 2026-04-02 2:22 UTC (permalink / raw)
To: David Howells
Cc: Anderson Nascimento, netdev, Marc Dionne, David S. Miller,
Eric Dumazet, Paolo Abeni, linux-afs, linux-kernel, Luxiao Xu,
Yifan Wu, Juefei Pu, Yuan Tan, Xin Liu, Ren Wei, Ren Wei,
Simon Horman, stable
In-Reply-To: <1938758.1775071956@warthog.procyon.org.uk>
On Wed, 01 Apr 2026 20:32:36 +0100 David Howells wrote:
> Anderson Nascimento <anderson@allelesecurity.com> wrote:
>
> > Isn't this the same issue addressed by my patch "[PATCH net v4 08/15] rxrpc:
> > Fix keyring reference count leak in rxrpc_setsockopt()"? Just asking to make
> > sure this is intended.
>
> Actually, yes. This is a different way to fix the same bug, so I'm happy to
> drop it from the series in preference to yours.
Would you like me to drop the last patch when applying?
And in return maybe you can scan the AI output and tell me
if any of it is legit? ;)
https://sashiko.dev/#/patchset/20260401105614.1696001-10-dhowells@redhat.com
^ permalink raw reply
* Re: [PATCH net-next v7] selftests: net: add tests for PPP
From: Qingfang Deng @ 2026-04-02 2:26 UTC (permalink / raw)
To: Jakub Kicinski, Dianne Skoll
Cc: Shuah Khan, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Felix Maurer, Sebastian Andrzej Siewior,
Matthieu Baerts (NGI0), linux-kernel, linux-kselftest, linux-ppp,
netdev, Paul Mackerras
In-Reply-To: <20260401175621.549c492e@kernel.org>
Hi,
On Thu, Apr 2, 2026 at 8:56 AM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Wed, 1 Apr 2026 23:45:38 +0800 Qingfang Deng wrote:
> > > # iperf3: error - unable to connect to server - server may have stopped running or use a different port, firewall issue, etc.: Network is unreachable
> > > # TEST: PPPoE [FAIL]
> > > not ok 1 selftests: net/ppp: pppoe.sh # exit=1
> >
> > It looks like pppoe-server fails to start. You may check the syslog to
> > see what's going on.
>
> Hm, we don't capture syslog automatically :S We capture stdout and
> stderr
>
> I'm not even sure there's something listening on syslog in virtme-ng
> Is it possible to make the daemon log to stdout or a file and dump
> that file to stdout on failure? Even if we fix the current issue
> it will be quite inconvenient if we have to go into syslog every time
> the test is failing. The test output should provide enough info to
> debug failures.
Add Cc: Dianne
I checked the man page of pppoe-server and did not find such option.
We can instead start our own listener and redirect the syslog to a
file or stdout:
socat -u UNIX-RECV:/dev/log,ignoreeof STDOUT &
Regards,
Qingfang
^ permalink raw reply
* Re: [PATCH net 01/10] netfilter: flowtable: strictly check for maximum number of actions
From: patchwork-bot+netdevbpf @ 2026-04-02 2:30 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netfilter-devel, davem, netdev, kuba, pabeni, edumazet, fw, horms
In-Reply-To: <20260401103646.1015423-2-pablo@netfilter.org>
Hello:
This series was applied to netdev/net.git (main)
by Pablo Neira Ayuso <pablo@netfilter.org>:
On Wed, 1 Apr 2026 12:36:37 +0200 you wrote:
> The maximum number of flowtable hardware offload actions in IPv6 is:
>
> * ethernet mangling (4 payload actions, 2 for each ethernet address)
> * SNAT (4 payload actions)
> * DNAT (4 payload actions)
> * Double VLAN (4 vlan actions, 2 for popping vlan, and 2 for pushing)
> for QinQ.
> * Redirect (1 action)
>
> [...]
Here is the summary with links:
- [net,01/10] netfilter: flowtable: strictly check for maximum number of actions
https://git.kernel.org/netdev/net/c/76522fcdbc3a
- [net,02/10] netfilter: nfnetlink_log: account for netlink header size
https://git.kernel.org/netdev/net/c/6d52a4a0520a
- [net,03/10] netfilter: x_tables: ensure names are nul-terminated
https://git.kernel.org/netdev/net/c/a958a4f90ddd
- [net,04/10] netfilter: ipset: use nla_strcmp for IPSET_ATTR_NAME attr
https://git.kernel.org/netdev/net/c/b7e8590987aa
- [net,05/10] netfilter: nf_conntrack_helper: pass helper to expect cleanup
https://git.kernel.org/netdev/net/c/a242a9ae58aa
- [net,06/10] netfilter: ctnetlink: zero expect NAT fields when CTA_EXPECT_NAT absent
https://git.kernel.org/netdev/net/c/35177c687713
- [net,07/10] netfilter: ctnetlink: ignore explicit helper on new expectations
https://git.kernel.org/netdev/net/c/917b61fa2042
- [net,08/10] netfilter: ipset: drop logically empty buckets in mtype_del
https://git.kernel.org/netdev/net/c/9862ef9ab0a1
- [net,09/10] netfilter: x_tables: restrict xt_check_match/xt_check_target extensions for NFPROTO_ARP
https://git.kernel.org/netdev/net/c/3d5d488f1177
- [net,10/10] netfilter: nf_tables: reject immediate NF_QUEUE verdict
https://git.kernel.org/netdev/net/c/da107398cbd4
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 1/6] dt-bindings: can: mcp251xfd: add microchip,xstbyen property
From: patchwork-bot+netdevbpf @ 2026-04-02 2:30 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: netdev, davem, kuba, linux-can, kernel, viken.dadhaniya,
conor.dooley
In-Reply-To: <20260401073338.5592-2-mkl@pengutronix.de>
Hello:
This series was applied to netdev/net-next.git (main)
by Marc Kleine-Budde <mkl@pengutronix.de>:
On Wed, 1 Apr 2026 09:30:09 +0200 you wrote:
> From: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
>
> Add the boolean property 'microchip,xstbyen' to enable the dedicated
> transceiver standby control function on the INT0/GPIO0/XSTBY pin of
> the MCP251xFD family.
>
> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Link: https://patch.msgid.link/20260321135031.3107408-2-viken.dadhaniya@oss.qualcomm.com
> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
>
> [...]
Here is the summary with links:
- [net-next,1/6] dt-bindings: can: mcp251xfd: add microchip,xstbyen property
https://git.kernel.org/netdev/net-next/c/2f41d7867800
- [net-next,2/6] net: can: ctucanfd: remove useless copy of PCI_DEVICE_DATA macro
https://git.kernel.org/netdev/net-next/c/1e41cbbe68e6
- [net-next,3/6] can: kvaser_usb: leaf: refactor endpoint lookup
https://git.kernel.org/netdev/net-next/c/495fac90b8ec
- [net-next,4/6] can: mcp251xfd: add support for XSTBYEN transceiver standby control
https://git.kernel.org/netdev/net-next/c/ae20301b6119
- [net-next,5/6] can: rcar_can: Convert to FIELD_MODIFY()
https://git.kernel.org/netdev/net-next/c/11d94d3516c0
- [net-next,6/6] can: ucan: refactor endpoint lookup
https://git.kernel.org/netdev/net-next/c/581281cb5a1b
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 6/6] selftests: drv-net: gro: add a test for bad IPv4 csum
From: Willem de Bruijn @ 2026-04-02 2:39 UTC (permalink / raw)
To: Jakub Kicinski, Willem de Bruijn
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, shuah,
willemb, petrm, anubhavsinggh, richardbgobert, linux-kselftest
In-Reply-To: <20260401191030.23104696@kernel.org>
Jakub Kicinski wrote:
> On Wed, 01 Apr 2026 20:28:46 -0400 Willem de Bruijn wrote:
> > > /* ip sub-tests - IPv4 only */
> > > + } else if (strcmp(testname, "ip_csum") == 0) {
> > > + correct_payload[0] = PAYLOAD_LEN;
> > > + correct_payload[1] = PAYLOAD_LEN;
> > > + printf("bad ip checksum doesn't coalesce: ");
> > > + check_recv_pkts(rxfd, correct_payload, 2);
> >
> > This verifies that a packet with bad csum does not coalesce to a valid
> > packet. Perhaps too paranoid but, do you also want to test the reverse
> > case?
>
> Will do, easy enough. Tho TBH I can't think of a case where this would
> matter. Bad csum pkt must bypass all GRO processing completely right?
> Because we don't want a corrupted packet to flush a valid session?
> Or you think some implementation may actually feed these packets into
> GRO to avoid waiting for a session timeout?
Interesting, I thought the opposite: this would flush an RSC context.
That's also how the OCP text is written: "An SO context closes if a
packet matches the flow, but not the other conditions."
There's a slight subtlety when sending three packets p1, p2 and p3, of
which p2 has a corrupted checksum. If three consecutive payloads, then
if p2 bypasses GRO, the other two are not consecutive so will not
coalesce either. This is the likely case for a real bit flip in
transit. Only if p2 and p3 have the same seqno would p1 and p3
coalesce if p2 bypasses GRO. That would be a weird, possibly malicious
packet, which is not much different from other TCP injection attacks.
Which have more serious consequences than coalescing efficiency.
^ permalink raw reply
* [PATCH] ice: wait for reset completion in ice_resume()
From: Aaron Ma @ 2026-04-02 2:42 UTC (permalink / raw)
To: anthony.l.nguyen, przemyslaw.kitszel, andrew+netdev, davem,
edumazet, kuba, pabeni, intel-wired-lan, netdev, linux-kernel
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.
Wait for the reset to complete before returning from ice_resume().
Fixes: 769c500dcc1e ("ice: Add advanced power mgmt for WoL")
Cc: stable@vger.kernel.org
Signed-off-by: Aaron Ma <aaron.ma@canonical.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 3c36e3641b9e9..a029c247510fd 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -5702,6 +5702,16 @@ static int ice_resume(struct device *dev)
/* Restart the service task */
mod_timer(&pf->serv_tmr, round_jiffies(jiffies + pf->serv_tmr_period));
+ /* Wait for the scheduled reset to finish so that the device is fully
+ * operational before returning. Without this, userspace (e.g.
+ * NetworkManager) may try to open the net device while the
+ * asynchronous reset and rebuild is still in progress, resulting in
+ * "can't open net device while reset is in progress" errors.
+ */
+ ret = ice_wait_for_reset(pf, 10 * HZ);
+ if (ret)
+ dev_err(dev, "Wait for reset failed during resume: %d\n", ret);
+
return 0;
}
--
2.43.0
^ permalink raw reply related
* Re: [net-next PATCH 06/10] net: dsa: realtek: rtl8365mb: add VLAN support
From: Luiz Angelo Daros de Luca @ 2026-04-02 2:45 UTC (permalink / raw)
To: Yury Norov
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Linus Walleij,
Alvin Šipraga, Yury Norov, Rasmus Villemoes, Russell King,
netdev, linux-kernel
In-Reply-To: <acyCmHh1IAykwycy@yury>
> > + vlan4k->vid = vid;
> > + vlan4k->member =
> > + FIELD_GET(RTL8365MB_CVLAN_ENTRY_D0_MBR_MASK, data[0]) |
> > + (FIELD_GET(RTL8365MB_CVLAN_ENTRY_D2_MBR_EXT_MASK, data[2])
> > + << FIELD_WIDTH(RTL8365MB_CVLAN_ENTRY_D0_MBR_MASK));
>
> This FIELD_GET() << FIELD_WIDTH() resembles FIELD_PREP(), except that
> you skip some checks. Is that intentional?
While it resembles FIELD_PREP(), the usage of FIELD_GET() <<
FIELD_WIDTH() is intentional and semantically distinct from
FIELD_PREP(). While FIELD_PREP() prepares a raw value to be written up
into a register mask, we are performing a read/unpack operation here:
extracting bits from hardware registers to populate the driver's
internal logical structure.
Using FIELD_PREP() for this would require defining a 'fake' software
mask (e.g., GENMASK(10, 8)) that does not correspond to any physical
register, which would be more confusing to future maintainers than the
current explicit reassembly.
The 11-bit member field is split across two non-contiguous 16-bit
words in the CVLAN entry:
- data[0] (D0): Contains the primary bits [7:0] via
RTL8365MB_CVLAN_ENTRY_D0_MBR_MASK.
- data[2] (D2): Contains the extension bits [10:8] via
RTL8365MB_CVLAN_ENTRY_D2_MBR_EXT_MASK.
This split layout suggests the hardware was originally designed for 8
ports and later expanded to 11, placing the extra bits in the
previously unused space in data[2].
Even if we concatenate them into a single 48-bit value, a single
bitfield macro would not handle the non-contiguous mask.
Regards,
Luiz
^ 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