* [PATCH net-next v7 7/9] net: wangxun: schedule hardware stats update in watchdog
From: Jiawen Wu @ 2026-04-07 2:56 UTC (permalink / raw)
To: netdev
Cc: Mengyuan Lou, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Russell King, Simon Horman,
Michal Swiatkowski, Jacob Keller, Kees Cook, Joe Damato,
Larysa Zaremba, Abdun Nihaal, Breno Leitao, Jiawen Wu
In-Reply-To: <20260407025616.33652-1-jiawenwu@trustnetic.com>
Hardware statistics should be updated periodically in the watchdog to
prevent 32-bit registers from overflowing. This is also required for the
upcoming pause frame accounting logic, which relies on regular statistics
sampling.
Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com>
---
drivers/net/ethernet/wangxun/libwx/wx_hw.c | 9 +++++
drivers/net/ethernet/wangxun/libwx/wx_type.h | 1 +
drivers/net/ethernet/wangxun/ngbe/ngbe_main.c | 36 ++++++++++++++++++-
.../net/ethernet/wangxun/txgbe/txgbe_main.c | 1 +
4 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/wangxun/libwx/wx_hw.c b/drivers/net/ethernet/wangxun/libwx/wx_hw.c
index 05731a50d85f..31259f69c0e2 100644
--- a/drivers/net/ethernet/wangxun/libwx/wx_hw.c
+++ b/drivers/net/ethernet/wangxun/libwx/wx_hw.c
@@ -2513,6 +2513,7 @@ int wx_sw_init(struct wx *wx)
return -ENOMEM;
}
+ spin_lock_init(&wx->hw_stats_lock);
mutex_init(&wx->reset_lock);
bitmap_zero(wx->state, WX_STATE_NBITS);
bitmap_zero(wx->flags, WX_PF_FLAGS_NBITS);
@@ -2845,6 +2846,12 @@ void wx_update_stats(struct wx *wx)
u64 restart_queue = 0, tx_busy = 0;
u32 i;
+ if (!netif_running(wx->netdev) ||
+ test_bit(WX_STATE_RESETTING, wx->state))
+ return;
+
+ spin_lock(&wx->hw_stats_lock);
+
/* gather some stats to the wx struct that are per queue */
for (i = 0; i < wx->num_rx_queues; i++) {
struct wx_ring *rx_ring = wx->rx_ring[i];
@@ -2913,6 +2920,8 @@ void wx_update_stats(struct wx *wx)
for (i = wx->num_vfs * wx->num_rx_queues_per_pool;
i < wx->mac.max_rx_queues; i++)
hwstats->qmprc += rd32(wx, WX_PX_MPRC(i));
+
+ spin_unlock(&wx->hw_stats_lock);
}
EXPORT_SYMBOL(wx_update_stats);
diff --git a/drivers/net/ethernet/wangxun/libwx/wx_type.h b/drivers/net/ethernet/wangxun/libwx/wx_type.h
index 0fbdda63b141..7831c5035be8 100644
--- a/drivers/net/ethernet/wangxun/libwx/wx_type.h
+++ b/drivers/net/ethernet/wangxun/libwx/wx_type.h
@@ -1354,6 +1354,7 @@ struct wx {
bool default_up;
struct wx_hw_stats stats;
+ spinlock_t hw_stats_lock; /* spinlock for accessing to hw stats */
u64 tx_busy;
u64 non_eop_descs;
u64 restart_queue;
diff --git a/drivers/net/ethernet/wangxun/ngbe/ngbe_main.c b/drivers/net/ethernet/wangxun/ngbe/ngbe_main.c
index 8c9d505721b1..d8e3827a8b1f 100644
--- a/drivers/net/ethernet/wangxun/ngbe/ngbe_main.c
+++ b/drivers/net/ethernet/wangxun/ngbe/ngbe_main.c
@@ -138,6 +138,26 @@ static int ngbe_sw_init(struct wx *wx)
return 0;
}
+/**
+ * ngbe_service_task - manages and runs subtasks
+ * @work: pointer to work_struct containing our data
+ **/
+static void ngbe_service_task(struct work_struct *work)
+{
+ struct wx *wx = container_of(work, struct wx, service_task);
+
+ wx_update_stats(wx);
+
+ wx_service_event_complete(wx);
+}
+
+static void ngbe_init_service(struct wx *wx)
+{
+ timer_setup(&wx->service_timer, wx_service_timer, 0);
+ INIT_WORK(&wx->service_task, ngbe_service_task);
+ clear_bit(WX_STATE_SERVICE_SCHED, wx->state);
+}
+
/**
* ngbe_irq_enable - Enable default interrupt generation settings
* @wx: board private structure
@@ -368,6 +388,10 @@ static void ngbe_disable_device(struct wx *wx)
wx_napi_disable_all(wx);
netif_tx_stop_all_queues(netdev);
netif_tx_disable(netdev);
+
+ timer_delete_sync(&wx->service_timer);
+ cancel_work_sync(&wx->service_task);
+
if (wx->gpio_ctrl)
ngbe_sfp_modules_txrx_powerctl(wx, false);
wx_irq_disable(wx);
@@ -407,6 +431,7 @@ void ngbe_up(struct wx *wx)
wx_napi_enable_all(wx);
/* enable transmits */
netif_tx_start_all_queues(wx->netdev);
+ mod_timer(&wx->service_timer, jiffies);
/* clear any pending interrupts, may auto mask */
rd32(wx, WX_PX_IC(0));
@@ -770,9 +795,11 @@ static int ngbe_probe(struct pci_dev *pdev,
eth_hw_addr_set(netdev, wx->mac.perm_addr);
wx_mac_set_default_filter(wx, wx->mac.perm_addr);
+ ngbe_init_service(wx);
+
err = wx_init_interrupt_scheme(wx);
if (err)
- goto err_free_mac_table;
+ goto err_cancel_service;
/* phy Interface Configuration */
err = ngbe_mdio_init(wx);
@@ -792,6 +819,9 @@ static int ngbe_probe(struct pci_dev *pdev,
wx_control_hw(wx, false);
err_clear_interrupt_scheme:
wx_clear_interrupt_scheme(wx);
+err_cancel_service:
+ timer_delete_sync(&wx->service_timer);
+ cancel_work_sync(&wx->service_task);
err_free_mac_table:
kfree(wx->rss_key);
kfree(wx->mac_table);
@@ -820,6 +850,10 @@ static void ngbe_remove(struct pci_dev *pdev)
netdev = wx->netdev;
wx_disable_sriov(wx);
unregister_netdev(netdev);
+
+ timer_shutdown_sync(&wx->service_timer);
+ cancel_work_sync(&wx->service_task);
+
phylink_destroy(wx->phylink);
pci_release_selected_regions(pdev,
pci_select_bars(pdev, IORESOURCE_MEM));
diff --git a/drivers/net/ethernet/wangxun/txgbe/txgbe_main.c b/drivers/net/ethernet/wangxun/txgbe/txgbe_main.c
index 0dd128aa18da..ec32a5f422f2 100644
--- a/drivers/net/ethernet/wangxun/txgbe/txgbe_main.c
+++ b/drivers/net/ethernet/wangxun/txgbe/txgbe_main.c
@@ -130,6 +130,7 @@ static void txgbe_service_task(struct work_struct *work)
txgbe_module_detection_subtask(wx);
txgbe_link_config_subtask(wx);
+ wx_update_stats(wx);
wx_service_event_complete(wx);
}
--
2.48.1
^ permalink raw reply related
* Re: [PATCH net-next] pppoe: drop PFC frames
From: qingfang.deng @ 2026-04-07 3:19 UTC (permalink / raw)
To: Simon Horman
Cc: linux-ppp, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, linux-kernel, Paul Mackerras,
Jaco Kroon, James Carlson, Wojciech Drewek, Guillaume Nault
In-Reply-To: <20260406144828.GH395680@kernel.org>
Hi,
April 6, 2026 at 10:48 PM, Simon Horman wrote:
>
> Hi,
>
> I think it would be best to add/use a #define rather than
> open coding the magic value 0x01. And perhaps expanding
> the comment to note that skb->data[0] is the first byte
> of the PPP protocol would be nice too.
The field does not have a canonical name. As per RFC1661, the LSB of the
first octet is used to test if the protocol field is compressed, and the
same code snippet is used in ppp_generic.c.
I could instead add a helper function:
static inline bool ppp_skb_is_compressed_proto(const struct sk_buff *skb)
{
return skb->data[0] & 0x01;
}
What do you think?
Regards,
Qingfang
^ permalink raw reply
* Re: [PATCH net-next v2 3/4] bpf-timestamp: keep track of the skb when wait_for_space occurs
From: Jason Xing @ 2026-04-07 3:33 UTC (permalink / raw)
To: Willem de Bruijn
Cc: davem, edumazet, kuba, pabeni, horms, willemb, martin.lau, netdev,
bpf, Jason Xing, Yushan Zhou
In-Reply-To: <willemdebruijn.kernel.27ec47b22b23c@gmail.com>
On Mon, Apr 6, 2026 at 10:37 PM Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>
> Jason Xing wrote:
> > On Mon, Apr 6, 2026 at 10:28 AM Willem de Bruijn
> > <willemdebruijn.kernel@gmail.com> wrote:
> > >
> > > Jason Xing wrote:
> > > > From: Jason Xing <kernelxing@tencent.com>
> > > >
> > > > The patch is the 1/2 part of push-level granularity feature.
> > > >
> > > > Tag the skb in tcp_sendmsg_locked() when wait_for_space occurs even
> > > > though it might not carry the last byte of the sendmsg.
> > > >
> > > > Prior to the patch, BPF timestamping cannot cover this case:
> > > > The following steps reproduce this:
> > > > 1) skb A is the current last skb before entering wait_for_space process
> > > > 2) tcp_push() pushes A without any tag
> > > > 3) A is transmitted from TCP to driver without putting any skb carrying
> > > > timestamps in the error queue, like SCHED, DRV/HARDWARE.
> > > > 4) sk_stream_wait_memory() sleeps for a while and then returns with an
> > > > error code. Note that the socket lock is released.
> > > > 5) skb A finally gets acked and removed from the rtx queue.
> > > > 6) continue with the rest of tcp_sendmsg_locked(): it will jump to(goto)
> > > > 'do_error' label and then 'out' label.
> > > > 7) at this moment, skb A turns out to be the last one in this send
> > > > syscall, and miss the following tcp_bpf_tx_timestamp() opportunity
> > > > before the final tcp_push()
> > > > 8) BPF script fails to see any timestamps this time
> > > >
> > > > Signed-off-by: Yushan Zhou <katrinzhou@tencent.com>
> > > > Signed-off-by: Jason Xing <kernelxing@tencent.com>
> > > > ---
> > > > net/ipv4/tcp.c | 4 +++-
> > > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> > > > index c603b90057f6..7d030a11d004 100644
> > > > --- a/net/ipv4/tcp.c
> > > > +++ b/net/ipv4/tcp.c
> > > > @@ -1400,9 +1400,11 @@ int tcp_sendmsg_locked(struct sock *sk, struct msghdr *msg, size_t size)
> > > > wait_for_space:
> > > > set_bit(SOCK_NOSPACE, &sk->sk_socket->flags);
> > > > tcp_remove_empty_skb(sk);
> > > > - if (copied)
> > > > + if (copied) {
> > > > + tcp_bpf_tx_timestamp(sk);
> > > > tcp_push(sk, flags & ~MSG_MORE, mss_now,
> > > > TCP_NAGLE_PUSH, size_goal);
> > >
> > > Now the number of skbs that will be tracked will be unpredictable,
> > > varying based on memory pressure.
> >
> > Right, I put some effort into writing a selftests to check how many
> > push functions get called at one time and failed to do so.
> >
> > >
> > > That sounds hard to use to me. Especially if these extra pushes
> > > cannot be identified as such.
> > >
> > > Perhaps if all skbs from the same sendmsg call can be identified,
> > > that would help explain pattern in data resulting from these
> > > uncommon extra data points.
> >
> > You meant move tcp_bpf_tx_timestamp before tcp_skb_entail()? That is
> > close to packet basis without considering fragmentation of skb :)
>
> No, I meant somehow in the notification having a way to identify all
> the skbs belonging to the same sendmsg call, to allow filtering on
> that. But I also don't immediately see how to do that (without adding
> yet another counter say).
If we don't build the relationship between skb and sendmsg (just like
the SENDMSG sock option), we will have no clue on how to calculate. If
we only take care of the skb from the view of the syscall layer, it's
fine by moving tcp_bpf_tx_timestamp() before tcp_skb_entail(). But in
terms of per skb even generated beneath TCP due to gso/tso, there is
only one way to correlate: adding an additional member in the skb
structure to store its sendmsg time. This discussion is only suitable
for use cases like net_timestamping.
Well, my key point is that, I have to admit, the above (including
existing bpf script net_timestamping) is a less effective way which
definitely harms the performance because of the extremely frequent
look-up process. It's not suitable for 7x24 observability in
production. What we've done internally is make the kernel layer as
lightweight/easy as possible and let the timestamping feature throw
each record into a ring buffer that the application can read, sort and
calculate. This arch survives the performance. But that's simply what
the design of the kernel module is, given the fast deployment in
production. I suppose in the future we could build a userspace tool
like blktrace to monitor efficiently instead of the selftest sample.
Honestly I don't like look-up action.
Since we're modifying the kernel, how about adding a new member to
record sendmsg time which bpf script is able to read. The whole
scenario looks like this:
1) in tcp_sendmsg_locked(), record the sendmsg time for each skb
2) in either tso_fragment() or tcp_gso_tstamp(), each new skb will get
a copy of its original skb
3) in each stage, bpf script reads the skb's sendmsg time and the
current time, and then effortlessly do the math.
At this point, what I had in mind is we have two options:
1) only handle the skb from the view of the send syscall layer, which
is, for sure, very simple but not thorough.
2) stick to a pure authentic packet basis, then adding a new member
seems inevitable. so the question would be where to add? The space of
the skb structure is very precious :(
>
> Right now, push-based seems rather arbitrary to me, informed more by
> technical limitations than a clear design. Perhaps per-packet makes
> more sense, esp. since BPF calls are cheap (compared to the other
> errqueue mechanism).
Agreed.
Thanks,
Jason
^ permalink raw reply
* Re: [PATCH v4] mm/vmpressure: skip socket pressure for costly order reclaim
From: Barry Song @ 2026-04-07 3:42 UTC (permalink / raw)
To: JP Kobryn (Meta)
Cc: linux-mm, willy, hannes, akpm, david, ljs, Liam.Howlett, vbabka,
rppt, surenb, mhocko, kasong, qi.zheng, shakeel.butt,
axelrasmussen, yuanchu, weixugc, riel, kuba, edumazet, netdev,
linux-kernel, kernel-team, wanglian, chentao
In-Reply-To: <20260406195014.112521-1-jp.kobryn@linux.dev>
On Tue, Apr 7, 2026 at 3:50 AM JP Kobryn (Meta) <jp.kobryn@linux.dev> wrote:
>
> When reclaim is triggered by high order allocations on a fragmented system,
> vmpressure() can report poor reclaim efficiency even though the system has
> plenty of free memory. This is because many pages are scanned, but few are
> found to actually reclaim - the pages are actively in use and don't need to
> be freed. The resulting scan:reclaim ratio causes vmpressure() to assert
> socket pressure, throttling TCP throughput unnecessarily.
>
> Costly order allocations (above PAGE_ALLOC_COSTLY_ORDER) rely heavily on
> compaction to succeed, so poor reclaim efficiency at these orders does not
> necessarily indicate memory pressure. The kernel already treats this order
> as the boundary where reclaim is no longer expected to succeed and
> compaction may take over.
>
> Make vmpressure() order-aware through an additional parameter sourced from
> scan_control at existing call sites. Socket pressure is now only asserted
> when order <= PAGE_ALLOC_COSTLY_ORDER.
>
> Memcg reclaim is unaffected since try_to_free_mem_cgroup_pages() always
> uses order 0, which passes the filter unconditionally. Similarly,
> vmpressure_prio() now passes order 0 internally when calling vmpressure(),
> ensuring critical pressure from low reclaim priority is not suppressed by
> the order filter.
>
> The patch was motivated by a case of impacted net throughput in production.
> On one affected host, the memory state at the time showed ~15GB available,
> zero cgroup pressure, and the following buddyinfo state:
>
> Order FreePages
> 0: 133,970
> 1: 29,230
> 2: 17,351
> 3: 18,984
> 7+: 0
>
> Using bpf, it was found that 94% of vmpressure calls on this host were from
> order-7 kswapd reclaim.
>
> TCP minimum recv window is rcv_ssthresh:19712.
>
> Before patch:
> 723 out of 3,843 (19%) TCP connections stuck at minimum recv window
>
> After live-patching and ~30min elapsed:
> 0 out of 3,470 TCP connections stuck at minimum recv window
>
> Signed-off-by: JP Kobryn (Meta) <jp.kobryn@linux.dev>
> Reviewed-by: Rik van Riel <riel@surriel.com>
> Acked-by: Johannes Weiner <hannes@cmpxchg.org>
> Acked-by: Shakeel Butt <shakeel.butt@linux.dev>
> Acked-by: Jakub Kicinski <kuba@kernel.org>
This patch looks sensible to me
Reviewed-by: Barry Song <baohua@kernel.org>
This is a one-sided costly order and should be treated as costly for
reclamation. On the other hand, nominally non-costly orders (e.g.,
order-3) can also become costly. I previously raised this issue here:
https://lore.kernel.org/linux-mm/20251013101636.69220-1-21cnbao@gmail.com/
Burst network traffic can make phones heat up.
More recently, with help from Wang Lian and Kunwu Chan (Cc'ed),
we developed a simple model that reliably reproduces this
behavior, where we observe significant CPU utilization by
kswapd due to 3-order burst allocation from the network.
I may revisit this discussion soon.
Best Regards
Barry
^ permalink raw reply
* Re: [PATCH net 1/1] af_unix: read UNIX_DIAG_VFS data under unix_state_lock
From: Kuniyuki Iwashima @ 2026-04-07 4:17 UTC (permalink / raw)
To: Ren Wei
Cc: netdev, davem, edumazet, kuba, pabeni, horms, xemul, yifanwucs,
tomapufckgml, yuantan098, bird, enjou1224z, wangjiexun2025
In-Reply-To: <e597de49d761fdc6961f49d638ce26bd3f74e988.1775207252.git.wangjiexun2025@gmail.com>
On Mon, Apr 6, 2026 at 6:53 AM Ren Wei <n05ec@lzu.edu.cn> wrote:
>
> From: Jiexun Wang <wangjiexun2025@gmail.com>
>
> Exact UNIX diag lookups hold a reference to the socket, but not to
> u->path. Meanwhile, unix_release_sock() clears u->path under
> unix_state_lock() and drops the path reference after unlocking.
>
> Read the inode and device numbers for UNIX_DIAG_VFS while holding
> unix_state_lock(), then emit the netlink attribute after dropping the
> lock.
>
> This keeps the VFS data stable while the reply is being built.
>
> Fixes: 5f7b0569460b ("unix_diag: Unix inode info NLA")
> Reported-by: Yifan Wu <yifanwucs@gmail.com>
> Reported-by: Juefei Pu <tomapufckgml@gmail.com>
> Co-developed-by: Yuan Tan <yuantan098@gmail.com>
> Signed-off-by: Yuan Tan <yuantan098@gmail.com>
> Suggested-by: Xin Liu <bird@lzu.edu.cn>
> Tested-by: Ren Wei <enjou1224z@gmail.com>
> Signed-off-by: Jiexun Wang <wangjiexun2025@gmail.com>
> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
> ---
> net/unix/diag.c | 21 +++++++++++++--------
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/net/unix/diag.c b/net/unix/diag.c
> index ca3473026151..76b2c48137dd 100644
> --- a/net/unix/diag.c
> +++ b/net/unix/diag.c
> @@ -28,18 +28,23 @@ static int sk_diag_dump_name(struct sock *sk, struct sk_buff *nlskb)
>
> static int sk_diag_dump_vfs(struct sock *sk, struct sk_buff *nlskb)
> {
> - struct dentry *dentry = unix_sk(sk)->path.dentry;
> + struct dentry *dentry;
> + struct unix_diag_vfs uv;
> + bool have_vfs = false;
nit: Please keep the reverse xmas order.
https://www.kernel.org/doc/html/v6.6/process/maintainer-netdev.html#local-variable-ordering-reverse-xmas-tree-rcs
>
> + unix_state_lock(sk);
> + dentry = unix_sk(sk)->path.dentry;
> if (dentry) {
> - struct unix_diag_vfs uv = {
> - .udiag_vfs_ino = d_backing_inode(dentry)->i_ino,
> - .udiag_vfs_dev = dentry->d_sb->s_dev,
> - };
> -
> - return nla_put(nlskb, UNIX_DIAG_VFS, sizeof(uv), &uv);
> + uv.udiag_vfs_ino = d_backing_inode(dentry)->i_ino;
> + uv.udiag_vfs_dev = dentry->d_sb->s_dev;
> + have_vfs = true;
> }
> + unix_state_unlock(sk);
>
> - return 0;
> + if (!have_vfs)
> + return 0;
> +
> + return nla_put(nlskb, UNIX_DIAG_VFS, sizeof(uv), &uv);
> }
>
> static int sk_diag_dump_peer(struct sock *sk, struct sk_buff *nlskb)
> --
> 2.34.1
>
^ permalink raw reply
* I need your help
From: Jisun Lee @ 2026-04-07 4:53 UTC (permalink / raw)
To: netdev
Dear Beloved
My ex Husband Song Lee refuse to pay our divorce settlement
funds. I need your help to recover Assets from the bank for
healthcare and child support
purposes, diagnosed with (bladder cancer).
I need your advise and support
Thank You
Jisun Lee
^ permalink raw reply
* Re: [PATCH v3 00/15] firmware: qcom: Add OP-TEE PAS service support
From: Sumit Garg @ 2026-04-07 4:54 UTC (permalink / raw)
To: Bjorn Andersson
Cc: linux-arm-msm, devicetree, dri-devel, freedreno, linux-media,
netdev, linux-wireless, ath12k, linux-remoteproc, konradybcio,
robh, krzk+dt, conor+dt, robin.clark, sean, akhilpo, lumag,
abhinav.kumar, jesszhan0024, marijn.suijten, airlied, simona,
vikash.garodia, dikshita.agarwal, bod, mchehab, elder,
andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
mathieu.poirier, trilokkumar.soni, mukesh.ojha, pavan.kondeti,
jorge.ramirez, tonyh, vignesh.viswanathan, srinivas.kandagatla,
amirreza.zarrabi, jens.wiklander, op-tee, apurupa, skare,
harshal.dev, linux-kernel, Sumit Garg
In-Reply-To: <adPLx3nCBb8IHz2b@baldur>
Hi Bjorn,
On Mon, Apr 06, 2026 at 10:09:27AM -0500, Bjorn Andersson wrote:
> On Fri, Mar 27, 2026 at 06:40:28PM +0530, Sumit Garg wrote:
> > From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> >
> > Qcom platforms has the legacy of using non-standard SCM calls
> > splintered over the various kernel drivers. These SCM calls aren't
> > compliant with the standard SMC calling conventions which is a
> > prerequisite to enable migration to the FF-A specifications from Arm.
> >
>
> Please get our colleagues involved in this discussion, because this
> non-SCM interface does not match the direction we are taking.
I thought I have already involved folks from QTEE perspective (Apurupa
and Sree) actively working on FF-A implementation aligned to this
interface. It would have been better if you could let me know where is
the direction mismatch here. In case there is a better alternative
design proposal for PAS service with FF-A, I would be happy to hear
that.
Anyhow for the legacy SoCs like KLMT, we really don't have any
alternative but have to stick to existing QTEE PAS design with OP-TEE
providing as an alternative backend. Surely we want to support loading
of existing signed firmware present in linux-firmware repo for KLMT with
OP-TEE being the TZ.
-Sumit
^ permalink raw reply
* [PATCH net] flow_dissector: do not dissect PPPoE PFC frames
From: Qingfang Deng @ 2026-04-07 4:57 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Qingfang Deng, Tony Nguyen, Guillaume Nault,
Wojciech Drewek, linux-kernel, netdev
Cc: Jaco Kroon
RFC 2516 Section 7 states that Protocol Field Compression (PFC) is NOT
RECOMMENDED for PPPoE. In practice, pppd does not support negotiating
PFC for PPPoE sessions, and the flow dissector driver has assumed an
uncompressed frame until the blamed commit.
During the review process of that commit [1], support for PFC is
suggested. However, having a compressed (1-byte) protocol field means
the subsequent PPP payload is shifted by one byte, causing 4-byte
misalignment for the network header and an unaligned access exception
on some architectures.
The exception can be reproduced by sending a PPPoE PFC frame to an
ethernet interface of a MIPS board, with RPS enabled, even if no PPPoE
session is active on that interface:
$ 0 : 00000000 80c40000 00000000 85144817
$ 4 : 00000008 00000100 80a75758 81dc9bb8
$ 8 : 00000010 8087ae2c 0000003d 00000000
$12 : 000000e0 00000039 00000000 00000000
$16 : 85043240 80a75758 81dc9bb8 00006488
$20 : 0000002f 00000007 85144810 80a70000
$24 : 81d1bda0 00000000
$28 : 81dc8000 81dc9aa8 00000000 805ead08
Hi : 00009d51
Lo : 2163358a
epc : 805e91f0 __skb_flow_dissect+0x1b0/0x1b50
ra : 805ead08 __skb_get_hash_net+0x74/0x12c
Status: 11000403 KERNEL EXL IE
Cause : 40800010 (ExcCode 04)
BadVA : 85144817
PrId : 0001992f (MIPS 1004Kc)
Call Trace:
[<805e91f0>] __skb_flow_dissect+0x1b0/0x1b50
[<805ead08>] __skb_get_hash_net+0x74/0x12c
[<805ef330>] get_rps_cpu+0x1b8/0x3fc
[<805fca70>] netif_receive_skb_list_internal+0x324/0x364
[<805fd120>] napi_complete_done+0x68/0x2a4
[<8058de5c>] mtk_napi_rx+0x228/0xfec
[<805fd398>] __napi_poll+0x3c/0x1c4
[<805fd754>] napi_threaded_poll_loop+0x234/0x29c
[<805fd848>] napi_threaded_poll+0x8c/0xb0
[<80053544>] kthread+0x104/0x12c
[<80002bd8>] ret_from_kernel_thread+0x14/0x1c
Code: 02d51821 1060045b 00000000 <8c640000> 3084000f 2c820005 144001a2 00042080 8e220000
To reduce the attack surface and maintain performance, do not process
PPPoE PFC frames. While at it, avoid byte-swapping at runtime, restoring
the original behavior.
[1] https://patch.msgid.link/20220630231016.GA392@debian.home
Fixes: 46126db9c861 ("flow_dissector: Add PPPoE dissectors")
Signed-off-by: Qingfang Deng <qingfang.deng@linux.dev>
---
include/linux/ppp_defs.h | 4 ++--
net/core/flow_dissector.c | 24 ++++++++----------------
2 files changed, 10 insertions(+), 18 deletions(-)
diff --git a/include/linux/ppp_defs.h b/include/linux/ppp_defs.h
index b7e57fdbd413..b74209e5a11e 100644
--- a/include/linux/ppp_defs.h
+++ b/include/linux/ppp_defs.h
@@ -20,9 +20,9 @@
* Protocol is valid if the value is odd and the least significant bit of the
* most significant octet is 0 (see RFC 1661, section 2).
*/
-static inline bool ppp_proto_is_valid(u16 proto)
+static inline bool ppp_proto_is_valid(__be16 proto)
{
- return !!((proto & 0x0101) == 0x0001);
+ return (proto & htons(0x0101)) == htons(0x0001);
}
#endif /* _PPP_DEFS_H_ */
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index 1b61bb25ba0e..50a316d752b2 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -1361,7 +1361,7 @@ bool __skb_flow_dissect(const struct net *net,
struct pppoe_hdr hdr;
__be16 proto;
} *hdr, _hdr;
- u16 ppp_proto;
+ __be16 ppp_proto;
hdr = __skb_header_pointer(skb, nhoff, sizeof(_hdr), data, hlen, &_hdr);
if (!hdr) {
@@ -1374,27 +1374,19 @@ bool __skb_flow_dissect(const struct net *net,
break;
}
- /* least significant bit of the most significant octet
- * indicates if protocol field was compressed
- */
- ppp_proto = ntohs(hdr->proto);
- if (ppp_proto & 0x0100) {
- ppp_proto = ppp_proto >> 8;
- nhoff += PPPOE_SES_HLEN - 1;
- } else {
- nhoff += PPPOE_SES_HLEN;
- }
+ ppp_proto = hdr->proto;
+ nhoff += PPPOE_SES_HLEN;
- if (ppp_proto == PPP_IP) {
+ if (ppp_proto == htons(PPP_IP)) {
proto = htons(ETH_P_IP);
fdret = FLOW_DISSECT_RET_PROTO_AGAIN;
- } else if (ppp_proto == PPP_IPV6) {
+ } else if (ppp_proto == htons(PPP_IPV6)) {
proto = htons(ETH_P_IPV6);
fdret = FLOW_DISSECT_RET_PROTO_AGAIN;
- } else if (ppp_proto == PPP_MPLS_UC) {
+ } else if (ppp_proto == htons(PPP_MPLS_UC)) {
proto = htons(ETH_P_MPLS_UC);
fdret = FLOW_DISSECT_RET_PROTO_AGAIN;
- } else if (ppp_proto == PPP_MPLS_MC) {
+ } else if (ppp_proto == htons(PPP_MPLS_MC)) {
proto = htons(ETH_P_MPLS_MC);
fdret = FLOW_DISSECT_RET_PROTO_AGAIN;
} else if (ppp_proto_is_valid(ppp_proto)) {
@@ -1412,7 +1404,7 @@ bool __skb_flow_dissect(const struct net *net,
FLOW_DISSECTOR_KEY_PPPOE,
target_container);
key_pppoe->session_id = hdr->hdr.sid;
- key_pppoe->ppp_proto = htons(ppp_proto);
+ key_pppoe->ppp_proto = ppp_proto;
key_pppoe->type = htons(ETH_P_PPP_SES);
}
break;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net-next v5 00/10] Decouple receive and transmit enablement in team driver
From: Marc Harvey @ 2026-04-07 5:04 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Jiri Pirko, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni, Shuah Khan, Simon Horman, netdev, linux-kernel,
linux-kselftest
In-Reply-To: <20260406074437.3ebb904a@kernel.org>
On Mon, Apr 6, 2026 at 7:44 AM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Mon, 06 Apr 2026 03:03:36 +0000 Marc Harvey wrote:
> > Allow independent control over receive and transmit enablement states
> > for aggregated ports in the team driver.
> >
> > The motivation is that IEE 802.3ad LACP "independent control" can't
> > be implemented for the team driver currently. This was added to the
> > bonding driver in commit 240fd405528b ("bonding: Add independent
> > control state machine").
> >
> > This series also has a few patches that add tests to show that the old
> > coupled enablement still works and that the new decoupled enablement
> > works as intended (4, 5, and 10).
> >
> > There are three patches with small fixes as well, with the goal of
> > making the final decoupling patch clearer (1, 2, and 3).
>
> activebackup:
>
> TAP version 13
> 1..1
> # overriding timeout to 2400
> # selftests: drivers/net/team: teamd_activebackup.sh
> # Setting up two-link aggregation for runner activebackup
> # Teamd version is: teamd 1.32
> # Conf files are /tmp/tmp.ydjNK9Um7H and /tmp/tmp.xZuc3cWbN0
> # This program is not intended to be run as root.
> # This program is not intended to be run as root.
> # Created team devices
> # Teamd PIDs are 21457 and 21461
> # exec of "ip link set eth0 up" failed: No such file or directory
> # exec of "ip link set eth0 up" failed: No such file or directory
> # exec of "ip link set eth1 up" failed: No such file or directory
> # exec of "ip link set eth1 up" failed: No such file or directory
> # PING fd00::2 (fd00::2) 56 data bytes
> # 64 bytes from fd00::2: icmp_seq=1 ttl=64 time=0.753 ms
> #
> # --- fd00::2 ping statistics ---
> # 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> # rtt min/avg/max/mdev = 0.753/0.753/0.753/0.000 msPacket count for test_team2 was 0
> # Waiting for eth0 in ns2-lZ0gqd to stop receiving
> # Packet count for eth0 was 0Packet count for eth0 was 0
> # Packet count for eth1 was 0
> # Waiting for eth1 in ns2-lZ0gqd to stop receiving
> # Packet count for eth1 was 0Packet count for eth0 was 0
> # Packet count for eth1 was 0
> # TEST: teamd active backup runner test [FAIL]
> # Traffic did not reach team interface in NS2.
> # Tearing down two-link aggregation
> # Failed to kill daemon: Timer expired
> # Failed to kill daemon: Timer expired
> # Sending sigkill to teamd for test_team1
> # rm: cannot remove '/var/run/teamd/test_team1.pid': No such file or directory
> # rm: cannot remove '/var/run/teamd/test_team1.sock': No such file or directory
> # Sending sigkill to teamd for test_team2
> # rm: cannot remove '/var/run/teamd/test_team2.pid': No such file or directory
> # rm: cannot remove '/var/run/teamd/test_team2.sock': No such file or directory
> not ok 1 selftests: drivers/net/team: teamd_activebackup.sh # exit=1
>
>
> transmit_failover:
>
> TAP version 13
> 1..1
> # overriding timeout to 2400
> # selftests: drivers/net/team: transmit_failover.sh
> # Error: ipv6: address not found.
> # Setting team in ns2-yxjiUo to mode roundrobin
> # Error: ipv6: address not found.
> # Setting team in ns1-Jht6kA to mode broadcast
> # Packet count for eth0 was 0
> # Packet count for eth1 was 0
> # Packet count for eth0 was 0
> # Packet count for eth1 was 0
> # Packet count for eth0 was 0
> # Packet count for eth1 was 0
> # TEST: Failover of 'broadcast' test [FAIL]
> # eth0 not transmitting when both links enabled
> # Setting team in ns1-Jht6kA to mode roundrobin
> # Packet count for eth0 was 0
> # Packet count for eth1 was 0
> # Packet count for eth0 was 0
> # Packet count for eth1 was 0
> # Packet count for eth0 was 0
> # Packet count for eth1 was 0
> # TEST: Failover of 'roundrobin' test [FAIL]
> # eth0 not transmitting when both links enabled
> # Setting team in ns1-Jht6kA to mode random
> # Packet count for eth0 was 0
> # Packet count for eth1 was 0
> # Packet count for eth0 was 0
> # Packet count for eth1 was 0
> # Packet count for eth0 was 0
> # Packet count for eth1 was 0
> # TEST: Failover of 'random' test [FAIL]
> # eth0 not transmitting when both links enabled
> not ok 1 selftests: drivers/net/team: transmit_failover.sh # exit=1
> --
> pw-bot: cr
Apologies for all of the test failures. Before sending this revision,
I ran each test thousands of times and observed no failures, so I
thought the flakiness would be resolved.
No matter what I try, I can't recreate either issue on my end. I've
tried building with the exact config from one of the test runs
(https://netdev-ctrl.bots.linux.dev/logs/vmksft/bonding/results/590921/).
I've tried stressing the VM according to
https://github.com/linux-netdev/nipa/wiki/How-to-run-netdev-selftests-CI-style#reproducing-unstable-tests
(this makes the tests time out, but I can still see traffic). I've
tried using the netdev-testing/net-next-2026-04-06--09-00 kernel
source. I've tried in nested and unnested virtual machines. I've also
tried running multiple test instances in parallel, but nothing
recreates the issues. The issues seem related to tcpdump, but without
reproducing them, I can only guess. Any suggestions for running the
tests exactly as the CI does would be greatly appreciated.
- Marc
^ permalink raw reply
* Re: [PATCH net 3/3] iavf: drop netdev lock while waiting for MAC change completion
From: Jose Ignacio Tornos Martinez @ 2026-04-07 5:21 UTC (permalink / raw)
To: kohei
Cc: anthony.l.nguyen, davem, edumazet, intel-wired-lan,
jesse.brandeburg, jtornosm, kuba, netdev, pabeni, stable
In-Reply-To: <adOjGCms-5PBuNte@x1>
Hi Kohei,
Thank you for your help and reference.
I will try to do it synchronously with the netdev lock held as you say.
Best regards
Jose Ignacio
^ permalink raw reply
* Re: [PATCH bpf v6 1/2] bpf: tcp: Reject non-TCP skb in bpf_sk_assign_tcp_reqsk()
From: Jiayuan Chen @ 2026-04-07 5:22 UTC (permalink / raw)
To: Martin KaFai Lau, Eric Dumazet, Kuniyuki Iwashima
Cc: bpf, Kuniyuki Iwashima, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, John Fastabend,
Stanislav Fomichev, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Shuah Khan, netdev, linux-kernel,
linux-kselftest
In-Reply-To: <20264619471.he8Q.martin.lau@linux.dev>
On 4/7/26 3:53 AM, Martin KaFai Lau wrote:
> On Fri, Apr 03, 2026 at 09:58:27AM +0800, Jiayuan Chen wrote:
>> bpf_sk_assign_tcp_reqsk() only validates skb->protocol (L3) but does not
>> check the L4 protocol in the IP header. A BPF program can call this kfunc
>> on a UDP skb with a valid TCP listener socket, which will succeed and
>> attach a TCP reqsk to the UDP skb.
>>
>> When the UDP skb enters the UDP receive path, skb_steal_sock() returns
>> the TCP listener from the reqsk. The UDP code then passes this TCP socket
>> to udp_unicast_rcv_skb() -> __udp_enqueue_schedule_skb(), which casts
>> it to udp_sock and accesses UDP-specific fields at invalid offsets,
>> causing a null pointer dereference and kernel panic:
>>
>> BUG: KASAN: null-ptr-deref in __udp_enqueue_schedule_skb+0x19d/0x1df0
>> Read of size 4 at addr 0000000000000008 by task test_progs/537
>>
>> CPU: 1 UID: 0 PID: 537 Comm: test_progs Not tainted 7.0.0-rc4+ #46 PREEMPT
>> Call Trace:
>> <IRQ>
>> dump_stack_lvl (lib/dump_stack.c:123)
>> print_report (mm/kasan/report.c:487)
>> kasan_report (mm/kasan/report.c:597)
>> __kasan_check_read (mm/kasan/shadow.c:32)
>> __udp_enqueue_schedule_skb (net/ipv4/udp.c:1719)
>> udp_queue_rcv_one_skb (net/ipv4/udp.c:2370 net/ipv4/udp.c:2500)
>> udp_queue_rcv_skb (net/ipv4/udp.c:2532)
>> udp_unicast_rcv_skb (net/ipv4/udp.c:2684)
>> __udp4_lib_rcv (net/ipv4/udp.c:2742)
>> udp_rcv (net/ipv4/udp.c:2937)
>> ip_protocol_deliver_rcu (net/ipv4/ip_input.c:209)
>> ip_local_deliver_finish (./include/linux/rcupdate.h:879 net/ipv4/ip_input.c:242)
>> ip_local_deliver (net/ipv4/ip_input.c:265)
>> __netif_receive_skb_one_core (net/core/dev.c:6164 (discriminator 4))
>> __netif_receive_skb (net/core/dev.c:6280)
>>
>> Fix this by checking the IP header's protocol field in
>> bpf_sk_assign_tcp_reqsk() and rejecting non-TCP skbs with -EINVAL.
>>
>> Note that for IPv6, the nexthdr check does not walk extension headers.
>> This is uncommon for TCP SYN packets in practice, and keeping it simple
>> was agreed upon by Kuniyuki Iwashima.
> sashiko has flagged a similar issue with larger scope.
> Please take a look. Thanks.
>
> https://sashiko.dev/#/patchset/20260403015851.148209-1-jiayuan.chen%40linux.dev
Thanks a lot Martin, sashiko actually dug into a deeper issue here.
Eric and Kuniyuki,
I think the AI review has a point. Since BPF can modify skb fields, the
following sequence still bypasses the protocol check in
bpf_sk_assign_tcp_reqsk():
// for a UDP skb
iph->protocol = TCP
bpf_sk_assign_tcp_reqsk()
iph->protocol = UDP
On top of that, bpf_sk_assign() already has the same problem — it doesn't
validate L4 protocol at all.
So I think we should add a check matching skb against sk in
skb_steal_sock() instead of adding check in bpf helper.
(Also, we probably need some MIB counters for this.)
Below is my diff:
//The core reason for passing protocol as a parameter rather than
reading it from
//the skb is that IPv6 extension headers make it non-trivial to get the
actual nexthdr.
//It's much simpler to just let the caller tell us what protocol it expects.
diff --git a/include/net/inet6_hashtables.h b/include/net/inet6_hashtables.h
index c16de5b7963fd..c1032bb9ea864 100644
--- a/include/net/inet6_hashtables.h
+++ b/include/net/inet6_hashtables.h
@@ -104,12 +104,13 @@ static inline
struct sock *inet6_steal_sock(struct net *net, struct sk_buff *skb,
int doff,
const struct in6_addr *saddr, const
__be16 sport,
const struct in6_addr *daddr, const
__be16 dport,
- bool *refcounted, inet6_ehashfn_t *ehashfn)
+ bool *refcounted, inet6_ehashfn_t *ehashfn,
+ int protocol)
{
struct sock *sk, *reuse_sk;
bool prefetched;
- sk = skb_steal_sock(skb, refcounted, &prefetched);
+ sk = skb_steal_sock(skb, refcounted, &prefetched, protocol);
if (!sk)
return NULL;
@@ -151,7 +152,7 @@ static inline struct sock *__inet6_lookup_skb(struct
sk_buff *skb, int doff,
struct sock *sk;
sk = inet6_steal_sock(net, skb, doff, &ip6h->saddr, sport,
&ip6h->daddr, dport,
- refcounted, inet6_ehashfn);
+ refcounted, inet6_ehashfn, IPPROTO_TCP);
if (IS_ERR(sk))
return NULL;
if (sk)
diff --git a/include/net/inet_hashtables.h b/include/net/inet_hashtables.h
index 5a979dcab5383..0ad73135ece7d 100644
--- a/include/net/inet_hashtables.h
+++ b/include/net/inet_hashtables.h
@@ -433,12 +433,13 @@ static inline
struct sock *inet_steal_sock(struct net *net, struct sk_buff *skb, int
doff,
const __be32 saddr, const __be16 sport,
const __be32 daddr, const __be16 dport,
- bool *refcounted, inet_ehashfn_t *ehashfn)
+ bool *refcounted, inet_ehashfn_t *ehashfn,
+ int protocol)
{
struct sock *sk, *reuse_sk;
bool prefetched;
- sk = skb_steal_sock(skb, refcounted, &prefetched);
+ sk = skb_steal_sock(skb, refcounted, &prefetched, protocol);
if (!sk)
return NULL;
@@ -469,7 +470,7 @@ struct sock *inet_steal_sock(struct net *net, struct
sk_buff *skb, int doff,
return reuse_sk;
}
-static inline struct sock *__inet_lookup_skb(struct sk_buff *skb,
+static inline struct sock *__tcp_lookup_skb(struct sk_buff *skb,
int doff,
const __be16 sport,
const __be16 dport,
@@ -481,7 +482,7 @@ static inline struct sock *__inet_lookup_skb(struct
sk_buff *skb,
struct sock *sk;
sk = inet_steal_sock(net, skb, doff, iph->saddr, sport,
iph->daddr, dport,
- refcounted, inet_ehashfn);
+ refcounted, inet_ehashfn, IPPROTO_TCP);
if (IS_ERR(sk))
return NULL;
if (sk)
diff --git a/include/net/request_sock.h b/include/net/request_sock.h
index 5a9c826a7092d..80bd209b2323b 100644
--- a/include/net/request_sock.h
+++ b/include/net/request_sock.h
@@ -91,7 +91,8 @@ static inline struct sock *req_to_sk(struct
request_sock *req)
* @prefetched: is set to true if the socket was assigned from bpf
*/
static inline struct sock *skb_steal_sock(struct sk_buff *skb,
- bool *refcounted, bool
*prefetched)
+ bool *refcounted, bool
*prefetched,
+ int protocol)
{
struct sock *sk = skb->sk;
@@ -103,6 +104,24 @@ static inline struct sock *skb_steal_sock(struct
sk_buff *skb,
*prefetched = skb_sk_is_prefetched(skb);
if (*prefetched) {
+ /* Validate that the stolen socket matches the expected L4
+ * protocol. BPF (bpf_sk_assign) can mistakenly or
maliciously
+ * assign a socket of the wrong type. If the protocols
don't
+ * match, clean up the assignment and return NULL so the
caller
+ * falls through to the normal hash table lookup.
+ *
+ * For full sockets, check sk_protocol directly.
+ * For request sockets (only created by
bpf_sk_assign_tcp_reqsk),
+ * sk_protocol is not in sock_common and cannot be accessed.
+ * Request sockets are always TCP, so assume IPPROTO_TCP.
+ */
+ if ((sk_fullsock(sk) ? sk->sk_protocol : IPPROTO_TCP) !=
protocol) {
+ skb_orphan(skb);
+ *prefetched = false;
+ *refcounted = false;
+ return NULL;
+ }
+
#if IS_ENABLED(CONFIG_SYN_COOKIES)
if (sk->sk_state == TCP_NEW_SYN_RECV &&
inet_reqsk(sk)->syncookie) {
struct request_sock *req = inet_reqsk(sk);
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index c7b2463c2e254..442a9379aefe6 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -2188,7 +2188,7 @@ int tcp_v4_rcv(struct sk_buff *skb)
th = (const struct tcphdr *)skb->data;
iph = ip_hdr(skb);
lookup:
- sk = __inet_lookup_skb(skb, __tcp_hdrlen(th), th->source,
+ sk = __tcp_lookup_skb(skb, __tcp_hdrlen(th), th->source,
th->dest, sdif, &refcounted);
if (!sk)
goto no_tcp_socket;
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index b60fad393e182..61f7fbf5ffd9c 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -2728,7 +2728,7 @@ int __udp4_lib_rcv(struct sk_buff *skb, struct
udp_table *udptable,
goto csum_error;
sk = inet_steal_sock(net, skb, sizeof(struct udphdr), saddr,
uh->source, daddr, uh->dest,
- &refcounted, udp_ehashfn);
+ &refcounted, udp_ehashfn, IPPROTO_UDP);
if (IS_ERR(sk))
goto no_sk;
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 010b909275dd0..9c3c25c938ec8 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -1115,7 +1115,7 @@ int __udp6_lib_rcv(struct sk_buff *skb, struct
udp_table *udptable,
/* Check if the socket is already available, e.g. due to early
demux */
sk = inet6_steal_sock(net, skb, sizeof(struct udphdr), saddr,
uh->source, daddr, uh->dest,
- &refcounted, udp6_ehashfn);
+ &refcounted, udp6_ehashfn, IPPROTO_UDP);
if (IS_ERR(sk))
goto no_sk;
---
This fix touches the net core path (skb_steal_sock / inet_steal_sock),
so it probably makes more sense to review it on the net side rather than
the bpf side.
^ permalink raw reply related
* Re: [PATCH net] xfrm_user: fix info leak in build_mapping()
From: Greg Kroah-Hartman @ 2026-04-07 5:51 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, linux-kernel, Steffen Klassert, Herbert Xu,
David S. Miller, Eric Dumazet, Paolo Abeni, Simon Horman
In-Reply-To: <20260406103851.59a200fc@kernel.org>
On Mon, Apr 06, 2026 at 10:38:51AM -0700, Jakub Kicinski wrote:
> On Mon, 6 Apr 2026 18:08:27 +0200 Greg Kroah-Hartman wrote:
> > On Mon, Apr 06, 2026 at 08:58:59AM -0700, Jakub Kicinski wrote:
> > > On Mon, 6 Apr 2026 08:54:49 -0700 Jakub Kicinski wrote:
> > > > You're right, skb owner is responsible for clearing after put.
> > > > Tho, Netlink is not as perf critical as real networking, I wish
> > > > we at least had a helper which reserves the space and clears it :/
> > > > This is not the first or the second time we hit this sort of a bug.
> > >
> > > We could make nlmsg_append() do that. Mostly because I don't have
> > > a better idea for a name and nlmsg_append is only used once ;)
> >
> > As shown in my other patch:
> > https://lore.kernel.org/r/2026040621-poison-gristle-aaa3@gregkh
> > we need this in at least 2 places, don't know if it's worth doing it for
> > all messages?
>
> I was thinking -- add the helper so that we can use it in places we're
> touching anyway. No need to mess with correct existing code.
>
> > I guess nlmsg_append() would work? It tries to do some zeroing out for
> > alignment for some reason...
> >
> > Want me to do that? I don't have a way to test any of this, I just
> > found it using some static code analysis tools that looked at holes in
> > structures.
>
> Do you have any more Netlink leaks in the queue? If you do let's do it,
> if you don't we can wait until the next victi^w patch to arrive.
I do not have any more, sorry. So is it worth it for just these 2?
Your call :)
^ permalink raw reply
* [RFC bpf] Ingress RX queue provenance across cpumap redirect
From: Adith-Joshua @ 2026-04-07 6:02 UTC (permalink / raw)
To: bpf; +Cc: netdev, ast, daniel, andrii, kuba, hawk, john.fastabend
Hi,
While working with XDP programs using cpumap redirection, I observed that
ctx->rx_queue_index becomes 0 after xdp_buff -> xdp_frame conversion and
execution on the remote CPU.
This is expected since xdp_frame does not carry xdp_rxq_info and cpumap
re-invokes XDP in a new execution context.
---
## Motivation
Some XDP deployments use cpumap as part of a multi-stage packet processing
pipeline, where XDP is effectively used as a distributed processing model
across CPUs rather than a single RX invocation.
In such setups, ingress RX queue identity (rx_queue_index) is sometimes
used beyond the initial hook not only for debugging, but for maintaining
consistent observability and pipeline semantics across stages. This includes:
- maintaining consistent per-RX-queue accounting across cpumap and later
XDP stages
- preserving RSS-based classification identity for traffic analysis and
validation of NIC steering behavior across a distributed pipeline
- enabling end-to-end telemetry correlation from hardware queue origin
through CPU-side processing
- supporting reproducibility of packet processing paths in asynchronous
cpumap-driven execution where scheduling and CPU assignment may vary
In these cases, rx_queue_index acts as a stable ingress classification anchor.
Losing this information at the cpumap boundary breaks the assumption that
XDP programs operate on a logically continuous packet context across stages.
---
## Design observation
Current behavior appears intentional:
- xdp_frame does not carry xdp_rxq_info
- cpumap executes XDP in a new RX context
- RX metadata is not considered part of redirected packet state
This suggests that RX provenance is currently scoped strictly to the NIC RX
invocation context, and is not carried across execution boundaries such as
cpumap or devmap.
---
## Question
Is RX queue provenance expected to be part of the XDP execution model across
redirect boundaries, or is it explicitly considered out of scope once a packet
is passed through cpumap/devmap?
---
## Alternative direction (for clarification only)
One possible model could be to treat ingress RX metadata as optional,
non-authoritative context and expose it via a helper-based mechanism
(e.g. ingress queue accessor), rather than embedding it in xdp_frame or
xdp_rxq_info.
However, I am not assuming this is aligned with existing design principles,
and would appreciate clarification on whether such a model is desirable at all.
To be explicit, I am not proposing that rx_queue_index itself be preserved
in xdp_frame or across cpumap, nor any change to existing struct layouts.
The question is whether ingress RX queue identity is intended to be
representable beyond the initial NIC RX invocation, particularly in
redirect-based XDP pipelines.
This question is motivated by cases where cpumap is used as part of a
multi-stage XDP processing pipeline, where loss of ingress queue identity
removes a stable classification signal that can otherwise be useful for:
- correlating packets across distributed XDP execution stages
- validating RSS / hardware steering behavior in software datapaths
- maintaining consistent per-queue observability across cpumap boundaries
- reconstructing ingress-to-processing paths in asynchronous CPU offload
The intent is to understand whether these requirements are intentionally
out of scope in the current XDP execution model, or whether a helper-based
or metadata-based abstraction is expected for such use cases.
---
## Follow-up
If this aligns with intended design, I would be happy to explore a concrete
proposal or implementation.
Thanks,
Adith
^ permalink raw reply
* Re: [net-next,v17,08/14] net: homa: create homa_rpc.h and homa_rpc.c
From: Paolo Abeni @ 2026-04-07 6:07 UTC (permalink / raw)
To: John Ousterhout; +Cc: horms, netdev, kuba, edumazet
In-Reply-To: <CAGXJAmx6YsBYQCagvHs1DPTd-b-yHYVTN67-JCApQdG+x6-cjg@mail.gmail.com>
On 4/4/26 1:04 AM, John Ousterhout wrote:
> On Tue, Mar 24, 2026 at 1:55 AM Paolo Abeni <pabeni@redhat.com> wrote:
>>
>>>> [ ... ]
>>>> Paolo also suggested using deferred SKB freeing (skb_attempt_defer_free) to
>>>> reduce the cost. While you mentioned that GRO is implemented in the full
>>>> Homa but was left out of the initial patch series, would it be beneficial to
>>>> include at least some of these optimizations in this initial submission?
>>>>
>>>> Reference: https://lore.kernel.org/netdev/9209dfbb-ca3a-4fb7-a2fb-0567394f8cda@redhat.com/
>>>
>>> When I asked ChatGPT about homa_attempt_defer_free it said that it
>>> only works if the skb has no dst, no destructor, and no skb_nfct. I'm
>>> a bit unsure how to proceed. Is homa_attempt_defer_free only intended
>>> for incoming packets? If so, then presumably there is no dst? But what
>>> about the other fields? Do I need to do something to clean them up
>>> before calling homa_attempt_defer_free?
>> skb_attempt_defer_free() usage is intended for the RX path only.
>>
>> Incoming packets get state (dst, extensions, ct...) attached in the rx
>> path before reaching the socket. You should free/release the state, if
>> possible, before inserting the skb into the receive queue, so that you
>> could defer free them after read.
>
> I have modified Homa to use skb_attempt_defer_free, and this made a
> significant difference in the throughput of the critical path copying
> data from skbs to user space. Thanks for the suggestion.
>
> However, skb_attempt_defer_free is not currently exported, so the
> patch series will now include an EXPORT_SYMBOL line for that in
> skbuff.c; hopefully that will be OK...
Yes, it is as long as such export is bundled with the module user - i.e.
this series.
Cheers,
Paolo
^ permalink raw reply
* RE: [PATCH net] net: txgbe: fix RTNL assertion warning when remove module
From: Jiawen Wu @ 2026-04-07 6:27 UTC (permalink / raw)
To: 'Russell King (Oracle)'
Cc: netdev, 'Mengyuan Lou', 'Andrew Lunn',
'David S. Miller', 'Eric Dumazet',
'Jakub Kicinski', 'Paolo Abeni',
'Simon Horman', 'Jacob Keller',
'Abdun Nihaal', stable
In-Reply-To: <acy5evlrUesbcB46@shell.armlinux.org.uk>
On Wed, Apr 1, 2026 2:22 PM, Russell King (Oracle) wrote:
> On Wed, Apr 01, 2026 at 10:16:34AM +0800, Jiawen Wu wrote:
> > On Tue, Mar 31, 2026 9:08 PM, Russell King (Oracle) wrote:
> > > On Tue, Mar 31, 2026 at 03:11:07PM +0800, Jiawen Wu wrote:
> > > > For the copper NIC with external PHY, the driver called
> > > > phylink_connect_phy() during probe and phylink_disconnect_phy() during
> > > > remove. It caused an RTNL assertion warning in phylink_disconnect_phy()
> > > > upon module remove.
> > > >
> > > > To fix this, move the phylink connect/disconnect PHY to ndo_open/close.
> > >
> > > Wouldn't it be simpler to just wrap the phylink_disconnect_phy() in the
> > > remove function with rtnl_lock()..rtnl_unlock() ?
> >
> > This is also a solution. But I think it would be nice to unify with other drivers
> > that call the functions in ndo_open/close.
>
> Both approaches are equally valid. Some network drivers attach the PHY
> at probe time (and thus can return -EPROBE_DEFER if the PHY is specified
> but not present). Others attach in .ndo_open which can only fail in this
> circumstance with no retry without userspace manually implementing that.
>
> There are other advantages and disadvantages to each approach.
Hi,
So is it still recommended that add rtnl_lock()...rtnl_unlock() instead of moving it?
^ permalink raw reply
* Re: [PATCH net-next v2 0/4] net: rnpgbe: Add TX/RX and link status support
From: Yibo Dong @ 2026-04-07 6:37 UTC (permalink / raw)
To: Jakub Kicinski
Cc: andrew+netdev, davem, edumazet, pabeni, danishanwar,
vadim.fedorenko, horms, linux-kernel, netdev
In-Reply-To: <20260403081249.50e25acd@kernel.org>
On Fri, Apr 03, 2026 at 08:12:49AM -0700, Jakub Kicinski wrote:
> On Fri, 3 Apr 2026 10:57:09 +0800 Dong Yibo wrote:
> > This patch series adds the packet transmission, reception, and link status
> > management features to the RNPGBE driver, building upon the previously
> > introduced mailbox communication and basic driver infrastructure.
>
> drivers/net/ethernet/mucse/rnpgbe/rnpgbe.h:183:19-23: WARNING use flexible-array member instead (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays)
>
> nit: checkpatch complains about a few lines over 80 chars too
> --
> pw-bot: cr
>
Be fixed in next version.
Thanks for you feedback.
^ permalink raw reply
* 回复：[PATCH v10 net-next 02/11] net/nebula-matrix: add our driver architecture
From: Illusion Wang @ 2026-04-07 6:40 UTC (permalink / raw)
To: Mohsin Bashir, Dimon, Alvin, Sam, netdev
Cc: andrew+netdev, corbet, kuba, linux-doc, lorenzo, pabeni, horms,
vadim.fedorenko, lukas.bulwahn, edumazet, enelsonmoore, skhan,
hkallweit1, jani.nikula, open list
In-Reply-To: <bf9f7c6f-8759-4f4f-8e35-2bd7c446d102@gmail.com>
>> +
>> + chan_mgt = devm_kzalloc(dev, sizeof(*chan_mgt), GFP_KERNEL);
>> + if (!chan_mgt)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + chan_mgt->common = common;
>> + chan_mgt->hw_ops_tbl = hw_ops_tbl;
>> +
>> + mailbox = devm_kzalloc(dev, sizeof(*mailbox), GFP_KERNEL);
>> + if (!mailbox)
>> + return ERR_PTR(-ENOMEM);
>Here, if mailbox allocation fails, we return without freeing chan_mgt
>resulting in a leak.
>> + mailbox->chan_type = NBL_CHAN_TYPE_MAILBOX;
>> + chan_mgt->chan_info[NBL_CHAN_TYPE_MAILBOX] = mailbox;
>> +
>> + return chan_mgt;
>> +}
Thanks for your feedback.
I've carefully considered your comment about the potential
memory leak in the provided code snippet,
but I use devm_kzalloc(), the area is guaranteed to be
freed whether initialization fails half-way or the device
gets detached.
ps:Documentation\driver-api\driver-model\devres.tst
my_init_one()
{
struct mydev *d;
d = devm_kzalloc(dev, sizeof(*d), GFP_KERNEL);
if (!d)
return -ENOMEM;
d->ring = dmam_alloc_coherent(...);
if (!d->ring)
return -ENOMEM;
if (check something)
return -EINVAL;
...
}
--illusion.wang
^ permalink raw reply
* [PATCH net v3] net: airoha: Add dma_rmb() and READ_ONCE() in airoha_qdma_rx_process()
From: Lorenzo Bianconi @ 2026-04-07 6:48 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Bianconi
Cc: Xuegang Lu, Simon Horman, linux-arm-kernel, linux-mediatek,
netdev
Add missing dma_rmb() in airoha_qdma_rx_process routine to make sure the
DMA read operations are completed when the NIC reports the processing on
the current descriptor is done. Moreover, add missing READ_ONCE() in
airoha_qdma_rx_process() for DMA descriptor control fields in order to
avoid any compiler reordering.
Fixes: 23020f0493270 ("net: airoha: Introduce ethernet support for EN7581 SoC")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
Changes in v3:
- Move page pointer initialization before checking error condition on
payload length in order avoid using page pointer uninitialized in the
airoha_qdma_rx_process() error path.
- Link to v2: https://lore.kernel.org/r/20260403-airoha_qdma_rx_process-fix-reordering-v2-1-181e6e23d27b@kernel.org
Changes in v2:
- Use msg1 in airoha_qdma_get_gdm_port() signature to avoid missing
READ_ONCE().
- Link to v1: https://lore.kernel.org/r/20260402-airoha_qdma_rx_process-fix-reordering-v1-1-53278474f062@kernel.org
---
drivers/net/ethernet/airoha/airoha_eth.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 91cb63a32d99..9285a68f435f 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -584,7 +584,7 @@ static int airoha_qdma_fill_rx_queue(struct airoha_queue *q)
static int airoha_qdma_get_gdm_port(struct airoha_eth *eth,
struct airoha_qdma_desc *desc)
{
- u32 port, sport, msg1 = le32_to_cpu(desc->msg1);
+ u32 port, sport, msg1 = le32_to_cpu(READ_ONCE(desc->msg1));
sport = FIELD_GET(QDMA_ETH_RXMSG_SPORT_MASK, msg1);
switch (sport) {
@@ -612,21 +612,24 @@ static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
while (done < budget) {
struct airoha_queue_entry *e = &q->entry[q->tail];
struct airoha_qdma_desc *desc = &q->desc[q->tail];
- u32 hash, reason, msg1 = le32_to_cpu(desc->msg1);
- struct page *page = virt_to_head_page(e->buf);
- u32 desc_ctrl = le32_to_cpu(desc->ctrl);
+ u32 hash, reason, msg1, desc_ctrl;
struct airoha_gdm_port *port;
int data_len, len, p;
+ struct page *page;
+ desc_ctrl = le32_to_cpu(READ_ONCE(desc->ctrl));
if (!(desc_ctrl & QDMA_DESC_DONE_MASK))
break;
+ dma_rmb();
+
q->tail = (q->tail + 1) % q->ndesc;
q->queued--;
dma_sync_single_for_cpu(eth->dev, e->dma_addr,
SKB_WITH_OVERHEAD(q->buf_size), dir);
+ page = virt_to_head_page(e->buf);
len = FIELD_GET(QDMA_DESC_LEN_MASK, desc_ctrl);
data_len = q->skb ? q->buf_size
: SKB_WITH_OVERHEAD(q->buf_size);
@@ -670,8 +673,8 @@ static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
* DMA descriptor. Report DSA tag to the DSA stack
* via skb dst info.
*/
- u32 sptag = FIELD_GET(QDMA_ETH_RXMSG_SPTAG,
- le32_to_cpu(desc->msg0));
+ u32 msg0 = le32_to_cpu(READ_ONCE(desc->msg0));
+ u32 sptag = FIELD_GET(QDMA_ETH_RXMSG_SPTAG, msg0);
if (sptag < ARRAY_SIZE(port->dsa_meta) &&
port->dsa_meta[sptag])
@@ -679,6 +682,7 @@ static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
&port->dsa_meta[sptag]->dst);
}
+ msg1 = le32_to_cpu(READ_ONCE(desc->msg1));
hash = FIELD_GET(AIROHA_RXD4_FOE_ENTRY, msg1);
if (hash != AIROHA_RXD4_FOE_ENTRY)
skb_set_hash(q->skb, jhash_1word(hash, 0),
---
base-commit: a9d4f4f6e65e0bf9bbddedecc84d67249991979c
change-id: 20260402-airoha_qdma_rx_process-fix-reordering-722308255b65
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* Re: [PATCH net-next v3 5/5] selftests: net: bridge: add tests for MRC and QQIC validation
From: Ujjal Roy @ 2026-04-07 6:53 UTC (permalink / raw)
To: Jakub Kicinski
Cc: David S . Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
Nikolay Aleksandrov, Ido Schimmel, David Ahern, Shuah Khan,
Andy Roulin, Yong Wang, Petr Machata, Ujjal Roy, bridge, netdev,
linux-kernel, linux-kselftest
In-Reply-To: <20260406182504.52a03794@kernel.org>
On Tue, Apr 7, 2026 at 6:55 AM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Fri, 3 Apr 2026 15:00:50 +0000 Ujjal Roy wrote:
> > --- a/tools/testing/selftests/net/forwarding/.gitignore
> > +++ b/tools/testing/selftests/net/forwarding/.gitignore
> > @@ -1,3 +1,5 @@
> > # SPDX-License-Identifier: GPL-2.0-only
> > forwarding.config
> > ipmr
> > +mc_encode
> > +mc_decode
>
> please keep this file sorted
I will keep all the codes under a single file and keep them sorted.
>
> > diff --git a/tools/testing/selftests/net/forwarding/Makefile b/tools/testing/selftests/net/forwarding/Makefile
> > index bbaf4d937dd8..a26da846632d 100644
> > --- a/tools/testing/selftests/net/forwarding/Makefile
> > +++ b/tools/testing/selftests/net/forwarding/Makefile
> > @@ -1,5 +1,15 @@
> > # SPDX-License-Identifier: GPL-2.0+ OR MIT
> >
> > +top_srcdir = ../../../../..
> > +
> > +CFLAGS += -Wall -Wl,--no-as-needed -O2 -g -I$(top_srcdir)/usr/include $(KHDR_INCLUDES)
> > +CFLAGS += -I$(top_srcdir)/tools/include
>
> Could you please keep the format more aligned with the ksft
> net/Makefile? Also is the -I$(top_srcdir)/tools/include
> still necessary? KHDR_INCLUDES don't include $src/usr/include ??
>
> > +TEST_GEN_FILES := \
> > + mc_encode \
> > + mc_decode \
> > +# end of TEST_GEN_FILES
>
> Also needs to be sorted
> --
> pw-bot: cr
I need bitops.h for fls() API, so I can see KHDR_INCLUDES is not
needed but tools/include is needed. I don't see lib.mk is including
the tools/include.
@Nikolay Aleksandrov Please review the updated test cases in this patch.
^ permalink raw reply
* Re: [PATCH net-next 01/15] igc: Call netif_queue_set_napi() with rtnl locked
From: Mika Westerberg @ 2026-04-07 6:53 UTC (permalink / raw)
To: Paolo Abeni
Cc: Bjorn Helgaas, Tony Nguyen, davem, kuba, edumazet, andrew+netdev,
netdev, andriy.shevchenko, ilpo.jarvinen, dima.ruinskiy, mbloch,
leon, linux-pci, saeedm, tariqt, lukas, bhelgaas, richardcochran,
Vinicius Costa Gomes, Jacob Keller, Avigail Dahan
In-Reply-To: <9f169800-12f2-4f98-ab99-e4433b2b49a9@redhat.com>
Hi,
On Thu, Apr 02, 2026 at 12:29:06PM +0200, Paolo Abeni wrote:
> On 3/31/26 7:37 PM, Bjorn Helgaas wrote:
> > On Mon, Mar 30, 2026 at 04:02:30PM -0700, Tony Nguyen wrote:
> >> From: Mika Westerberg <mika.westerberg@linux.intel.com>
> >>
> >> When runtime resuming igc we get:
> >>
> >> [ 516.161666] RTNL: assertion failed at ./include/net/netdev_lock.h (72)
> >>
> >> Happens because commit 310ae9eb2617 ("net: designate queue -> napi
> >> linking as "ops protected"") added check for this. For this reason drop
> >> the special case for runtime PM from __igc_resume(). This makes it take
> >> rtnl lock unconditionally.
> >
> > Taking the rtnl lock unconditionally certainly makes the code nicer,
> > but the commit log only mentions the "avoid the warning" benefit, not
> > the actual reason this is safe to do.
>
> Sashiko says it's not safe:
>
> ---
> Can this regression cause a self-deadlock when a runtime resume is
> triggered from paths that already hold the rtnl lock?
> If the network interface is logically up but the link is disconnected,
> igc_runtime_idle() allows the device to enter runtime suspend. When a
> user queries the device using ethtool, the networking core acquires
> rtnl_lock() and then calls pm_runtime_get_sync() to ensure the hardware
> is awake.
> This synchronously executes the driver's runtime resume callback, which
> calls __igc_resume(). Because netif_running(netdev) is true, the
> modified __igc_resume() unconditionally attempts to acquire rtnl_lock().
> Since the executing thread already holds this non-recursive mutex, it
> appears the system would self-deadlock, hanging the network stack.
> ---
It's a good analysis. I just tried this flow:
1. Boot the system up, nothing connected to igc NIC.
2. Plug in cable to igc.
3. Configure the interface.
4. Enable runtime PM for igc.
5. Unplug the cable.
6. Verify igc is runtime suspended.
7. Run ethtool <interface>
This leads to deadlock as below.
igc maintainers, please drop this patch. I apologize I did not realize this
flow when I did it.
[ 1231.655924] INFO: task ethtool:3139 blocked for more than 122 seconds.
[ 1231.662515] Tainted: G U 7.0.0-rc6+ #1748
[ 1231.668551] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1231.676410] task:ethtool state:D stack:0 pid:3139 tgid:3139 ppid:292 task_flags:0x480000 flags:0x00080800
[ 1231.687508] Call Trace:
[ 1231.689997] <TASK>
[ 1231.692132] __schedule+0x58a/0x1820
[ 1231.695747] ? sysvec_apic_timer_interrupt+0x4c/0xa0
[ 1231.700742] ? asm_sysvec_apic_timer_interrupt+0x1b/0x20
[ 1231.706090] schedule+0x64/0xe0
[ 1231.709262] schedule_preempt_disabled+0x15/0x30
[ 1231.713907] __mutex_lock+0x377/0xa60
[ 1231.717606] __mutex_lock_slowpath+0x13/0x20
[ 1231.721905] mutex_lock+0x2c/0x40
[ 1231.725259] rtnl_lock+0x15/0x20
[ 1231.728541] __igc_resume+0x19a/0x2b0 [igc]
[ 1231.732798] igc_runtime_resume+0xe/0x20 [igc]
[ 1231.737288] pci_pm_runtime_resume+0xce/0x100
[ 1231.741678] ? __pfx_pci_pm_runtime_resume+0x10/0x10
[ 1231.746681] __rpm_callback+0xab/0x310
[ 1231.750458] ? ktime_get_mono_fast_ns+0x3a/0x100
[ 1231.755107] ? __pfx_pci_pm_runtime_resume+0x10/0x10
[ 1231.760096] rpm_resume+0x4bb/0x670
[ 1231.763618] __pm_runtime_resume+0x5c/0x80
[ 1231.767749] dev_ethtool+0x19d/0xc90
[ 1231.771352] dev_ioctl+0x23c/0x550
[ 1231.774791] sock_do_ioctl+0x11f/0x1b0
[ 1231.778569] sock_ioctl+0x27f/0x390
[ 1231.782091] ? handle_mm_fault+0x11a5/0x1250
[ 1231.786388] __se_sys_ioctl+0x75/0xd0
[ 1231.790077] __x64_sys_ioctl+0x1d/0x30
[ 1231.793851] x64_sys_call+0x14ed/0x2d30
[ 1231.797719] do_syscall_64+0xfb/0x680
[ 1231.801404] ? arch_exit_to_user_mode_prepare+0xd/0xb0
[ 1231.806559] ? irqentry_exit+0x3b/0x510
[ 1231.810413] entry_SYSCALL_64_after_hwframe+0x76/0x7e
^ permalink raw reply
* Re: [PATCH net v2] bridge: cfm: reject invalid CCM interval at configuration time
From: Ido Schimmel @ 2026-04-07 7:07 UTC (permalink / raw)
To: Xiang Mei
Cc: netdev, horms, bridge, razor, davem, edumazet, pabeni, bestswngs
In-Reply-To: <20260405000324.548623-1-xmei5@asu.edu>
On Sat, Apr 04, 2026 at 05:03:24PM -0700, Xiang Mei wrote:
> ccm_tx_work_expired() re-arms itself via queue_delayed_work() using
> the configured exp_interval converted by interval_to_us(). When
> exp_interval is BR_CFM_CCM_INTERVAL_NONE or out of range,
> interval_to_us() returns 0, causing the worker to fire immediately in
> a tight loop that allocates skbs until OOM.
>
> Fix this by validating exp_interval at configuration time:
>
> - Constrain IFLA_BRIDGE_CFM_CC_CONFIG_EXP_INTERVAL to [1, 7] in the
> netlink policy so userspace cannot set an invalid value.
>
> - Reject starting CCM TX in br_cfm_cc_ccm_tx() when exp_interval has
> not yet been configured (defaults to 0 from kzalloc).
>
> Fixes: a806ad8ee2aa ("bridge: cfm: Kernel space implementation of CFM. CCM frame TX added.")
Nit: Doesn't matter in practice, but let's blame commit 2be665c3940d
("bridge: cfm: Netlink SET configuration Interface.") instead as I don't
think this bug could be triggered before exposing the netlink API.
> Reported-by: Weiming Shi <bestswngs@gmail.com>
> Signed-off-by: Xiang Mei <xmei5@asu.edu>
> ---
> v2: Move validation out of the datapath and into configuration
>
> net/bridge/br_cfm.c | 6 ++++++
> net/bridge/br_cfm_netlink.c | 2 +-
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/net/bridge/br_cfm.c b/net/bridge/br_cfm.c
> index 118c7ea48c35..dea56fffa1c1 100644
> --- a/net/bridge/br_cfm.c
> +++ b/net/bridge/br_cfm.c
> @@ -805,6 +805,12 @@ int br_cfm_cc_ccm_tx(struct net_bridge *br, const u32 instance,
> goto save;
> }
>
> + if (!interval_to_us(mep->cc_config.exp_interval)) {
> + NL_SET_ERR_MSG_MOD(extack,
> + "Invalid CCM interval");
> + return -EINVAL;
> + }
> +
> /* Start delayed work to transmit CCM frames. It is done with zero delay
> * to send first frame immediately
> */
> diff --git a/net/bridge/br_cfm_netlink.c b/net/bridge/br_cfm_netlink.c
> index 2faab44652e7..1bb33c8f587b 100644
> --- a/net/bridge/br_cfm_netlink.c
> +++ b/net/bridge/br_cfm_netlink.c
> @@ -34,7 +34,7 @@ br_cfm_cc_config_policy[IFLA_BRIDGE_CFM_CC_CONFIG_MAX + 1] = {
> [IFLA_BRIDGE_CFM_CC_CONFIG_UNSPEC] = { .type = NLA_REJECT },
> [IFLA_BRIDGE_CFM_CC_CONFIG_INSTANCE] = { .type = NLA_U32 },
> [IFLA_BRIDGE_CFM_CC_CONFIG_ENABLE] = { .type = NLA_U32 },
> - [IFLA_BRIDGE_CFM_CC_CONFIG_EXP_INTERVAL] = { .type = NLA_U32 },
> + [IFLA_BRIDGE_CFM_CC_CONFIG_EXP_INTERVAL] = NLA_POLICY_RANGE(NLA_U32, 1, 7),
Use BR_CFM_CCM_INTERVAL_3_3_MS and BR_CFM_CCM_INTERVAL_10_MIN instead of
the magic numbers?
The Sashiko review points out that blocking BR_CFM_CCM_INTERVAL_NONE
might break user space, but it seems weird to allow passing a value that
is interpreted the same as an invalid one. Worst case, if someone
complains, we can revert and go back to v1.
> [IFLA_BRIDGE_CFM_CC_CONFIG_EXP_MAID] = {
> .type = NLA_BINARY, .len = CFM_MAID_LENGTH },
> };
> --
> 2.43.0
>
^ permalink raw reply
* 回复：[PATCH v10 net-next 04/11] net/nebula-matrix: channel msg value and msg struct
From: Illusion Wang @ 2026-04-07 7:22 UTC (permalink / raw)
To: Mohsin Bashir, Dimon, Alvin, Sam, netdev
Cc: andrew+netdev, corbet, kuba, linux-doc, lorenzo, pabeni, horms,
vadim.fedorenko, lukas.bulwahn, edumazet, enelsonmoore, skhan,
hkallweit1, jani.nikula, open list
In-Reply-To: <0b0eb2e1-7aec-4913-8062-b3eff786a1ae@gmail.com>
> struct nbl_channel_mgt;
> struct nbl_adapter;
>> +enum nbl_chan_msg_type {
>> + NBL_CHAN_MSG_ACK,
>> + NBL_CHAN_MSG_ADD_MACVLAN,
>> + NBL_CHAN_MSG_DEL_MACVLAN,
>> + NBL_CHAN_MSG_ADD_MULTI_RULE,
>> + NBL_CHAN_MSG_DEL_MULTI_RULE,
>> + NBL_CHAN_MSG_SETUP_MULTI_GROUP,
>> + NBL_CHAN_MSG_REMOVE_MULTI_GROUP,
>> + NBL_CHAN_MSG_REGISTER_NET,
>> + NBL_CHAN_MSG_UNREGISTER_NET,
>> + NBL_CHAN_MSG_ALLOC_TXRX_QUEUES,
>> + NBL_CHAN_MSG_FREE_TXRX_QUEUES,
>> + NBL_CHAN_MSG_SETUP_QUEUE,
>> + NBL_CHAN_MSG_REMOVE_ALL_QUEUES,
>> + NBL_CHAN_MSG_CFG_DSCH,
>> + NBL_CHAN_MSG_SETUP_CQS,
>> + NBL_CHAN_MSG_REMOVE_CQS,
>> + NBL_CHAN_MSG_CFG_QDISC_MQPRIO,
>> + NBL_CHAN_MSG_CONFIGURE_MSIX_MAP,
>> + NBL_CHAN_MSG_DESTROY_MSIX_MAP,
>> + NBL_CHAN_MSG_MAILBOX_ENABLE_IRQ,
>> + NBL_CHAN_MSG_GET_GLOBAL_VECTOR,
>> + NBL_CHAN_MSG_GET_VSI_ID,
>> + NBL_CHAN_MSG_SET_PROSISC_MODE,
>> + NBL_CHAN_MSG_GET_FIRMWARE_VERSION,
>> + NBL_CHAN_MSG_GET_QUEUE_ERR_STATS,
>> + NBL_CHAN_MSG_GET_COALESCE,
>> + NBL_CHAN_MSG_SET_COALESCE,
>> + NBL_CHAN_MSG_SET_SPOOF_CHECK_ADDR,
>> + NBL_CHAN_MSG_SET_VF_SPOOF_CHECK,
>> + NBL_CHAN_MSG_GET_RXFH_INDIR_SIZE,
>> + NBL_CHAN_MSG_GET_RXFH_INDIR,
>> + NBL_CHAN_MSG_GET_RXFH_RSS_KEY,
>> + NBL_CHAN_MSG_GET_RXFH_RSS_ALG_SEL,
>> + NBL_CHAN_MSG_GET_HW_CAPS,
>> + NBL_CHAN_MSG_GET_HW_STATE,
>> + NBL_CHAN_MSG_REGISTER_RDMA,
>> + NBL_CHAN_MSG_UNREGISTER_RDMA,
>> + NBL_CHAN_MSG_GET_REAL_HW_ADDR,
>> + NBL_CHAN_MSG_GET_REAL_BDF,
>> + NBL_CHAN_MSG_GRC_PROCESS,
>> + NBL_CHAN_MSG_SET_SFP_STATE,
>> + NBL_CHAN_MSG_SET_ETH_LOOPBACK,
>> + NBL_CHAN_MSG_CHECK_ACTIVE_VF,
>> + NBL_CHAN_MSG_GET_PRODUCT_FLEX_CAP,
>> + NBL_CHAN_MSG_ALLOC_KTLS_TX_INDEX,
>> + NBL_CHAN_MSG_FREE_KTLS_TX_INDEX,
>> + NBL_CHAN_MSG_CFG_KTLS_TX_KEYMAT,
>> + NBL_CHAN_MSG_ALLOC_KTLS_RX_INDEX,
>> + NBL_CHAN_MSG_FREE_KTLS_RX_INDEX,
>> + NBL_CHAN_MSG_CFG_KTLS_RX_KEYMAT,
>> + NBL_CHAN_MSG_CFG_KTLS_RX_RECORD,
>> + NBL_CHAN_MSG_ADD_KTLS_RX_FLOW,
>> + NBL_CHAN_MSG_DEL_KTLS_RX_FLOW,
>> + NBL_CHAN_MSG_ALLOC_IPSEC_TX_INDEX,
>> + NBL_CHAN_MSG_FREE_IPSEC_TX_INDEX,
>> + NBL_CHAN_MSG_ALLOC_IPSEC_RX_INDEX,
>> + NBL_CHAN_MSG_FREE_IPSEC_RX_INDEX,
>> + NBL_CHAN_MSG_CFG_IPSEC_TX_SAD,
>> + NBL_CHAN_MSG_CFG_IPSEC_RX_SAD,
>> + NBL_CHAN_MSG_ADD_IPSEC_TX_FLOW,
>> + NBL_CHAN_MSG_DEL_IPSEC_TX_FLOW,
>> + NBL_CHAN_MSG_ADD_IPSEC_RX_FLOW,
>> + NBL_CHAN_MSG_DEL_IPSEC_RX_FLOW,
>> + NBL_CHAN_MSG_NOTIFY_IPSEC_HARD_EXPIRE,
>> + NBL_CHAN_MSG_GET_MBX_IRQ_NUM,
>> + NBL_CHAN_MSG_CLEAR_FLOW,
>> + NBL_CHAN_MSG_CLEAR_QUEUE,
>> + NBL_CHAN_MSG_GET_ETH_ID,
>> + NBL_CHAN_MSG_SET_OFFLOAD_STATUS,
>> + NBL_CHAN_MSG_INIT_OFLD,
>> + NBL_CHAN_MSG_INIT_CMDQ,
>> + NBL_CHAN_MSG_DESTROY_CMDQ,
>> + NBL_CHAN_MSG_RESET_CMDQ,
>> + NBL_CHAN_MSG_INIT_FLOW,
>> + NBL_CHAN_MSG_DEINIT_FLOW,
>> + NBL_CHAN_MSG_OFFLOAD_FLOW_RULE,
>> + NBL_CHAN_MSG_GET_ACL_SWITCH,
>> + NBL_CHAN_MSG_GET_VSI_GLOBAL_QUEUE_ID,
>> + NBL_CHAN_MSG_INIT_REP,
>> + NBL_CHAN_MSG_GET_LINE_RATE_INFO,
>> + NBL_CHAN_MSG_REGISTER_NET_REP,
>> + NBL_CHAN_MSG_UNREGISTER_NET_REP,
>> + NBL_CHAN_MSG_REGISTER_ETH_REP,
>> + NBL_CHAN_MSG_UNREGISTER_ETH_REP,
>> + NBL_CHAN_MSG_REGISTER_UPCALL_PORT,
>> + NBL_CHAN_MSG_UNREGISTER_UPCALL_PORT,
>> + NBL_CHAN_MSG_GET_PORT_STATE,
>> + NBL_CHAN_MSG_SET_PORT_ADVERTISING,
>> + NBL_CHAN_MSG_GET_MODULE_INFO,
>> + NBL_CHAN_MSG_GET_MODULE_EEPROM,
>> + NBL_CHAN_MSG_GET_LINK_STATE,
>> + NBL_CHAN_MSG_NOTIFY_LINK_STATE,
>> + NBL_CHAN_MSG_GET_QUEUE_CXT,
>> + NBL_CHAN_MSG_CFG_LOG,
>> + NBL_CHAN_MSG_INIT_VDPAQ,
>> + NBL_CHAN_MSG_DESTROY_VDPAQ,
>> + NBL_CHAN_MSG_GET_UPCALL_PORT,
>> + NBL_CHAN_MSG_NOTIFY_ETH_REP_LINK_STATE,
>> + NBL_CHAN_MSG_SET_ETH_MAC_ADDR,
>> + NBL_CHAN_MSG_GET_FUNCTION_ID,
>> + NBL_CHAN_MSG_GET_CHIP_TEMPERATURE,
>> + NBL_CHAN_MSG_DISABLE_HW_FLOW,
>> + NBL_CHAN_MSG_ENABLE_HW_FLOW,
>> + NBL_CHAN_MSG_SET_UPCALL_RULE,
>> + NBL_CHAN_MSG_UNSET_UPCALL_RULE,
>> + NBL_CHAN_MSG_GET_REG_DUMP,
>> + NBL_CHAN_MSG_GET_REG_DUMP_LEN,
>> + NBL_CHAN_MSG_CFG_LAG_HASH_ALGORITHM,
>> + NBL_CHAN_MSG_CFG_LAG_MEMBER_FWD,
>> + NBL_CHAN_MSG_CFG_LAG_MEMBER_LIST,
>> + NBL_CHAN_MSG_CFG_LAG_MEMBER_UP_ATTR,
>> + NBL_CHAN_MSG_ADD_LAG_FLOW,
>> + NBL_CHAN_MSG_DEL_LAG_FLOW,
>> + NBL_CHAN_MSG_SWITCHDEV_INIT_CMDQ,
>> + NBL_CHAN_MSG_SWITCHDEV_DEINIT_CMDQ,
>> + NBL_CHAN_MSG_SET_TC_FLOW_INFO,
>> + NBL_CHAN_MSG_UNSET_TC_FLOW_INFO,
>> + NBL_CHAN_MSG_INIT_ACL,
>> + NBL_CHAN_MSG_UNINIT_ACL,
>> + NBL_CHAN_MSG_CFG_LAG_MCC,
>> + NBL_CHAN_MSG_REGISTER_VSI2Q,
>> + NBL_CHAN_MSG_SETUP_Q2VSI,
>> + NBL_CHAN_MSG_REMOVE_Q2VSI,
>> + NBL_CHAN_MSG_SETUP_RSS,
>> + NBL_CHAN_MSG_REMOVE_RSS,
>> + NBL_CHAN_MSG_GET_REP_QUEUE_INFO,
>> + NBL_CHAN_MSG_CTRL_PORT_LED,
>> + NBL_CHAN_MSG_NWAY_RESET,
>> + NBL_CHAN_MSG_SET_INTL_SUPPRESS_LEVEL,
>> + NBL_CHAN_MSG_GET_ETH_STATS,
>> + NBL_CHAN_MSG_GET_MODULE_TEMPERATURE,
>> + NBL_CHAN_MSG_GET_BOARD_INFO,
>> + NBL_CHAN_MSG_GET_P4_USED,
>> + NBL_CHAN_MSG_GET_VF_BASE_VSI_ID,
>> + NBL_CHAN_MSG_ADD_LLDP_FLOW,
>> + NBL_CHAN_MSG_DEL_LLDP_FLOW,
>> + NBL_CHAN_MSG_CFG_ETH_BOND_INFO,
>> + NBL_CHAN_MSG_CFG_DUPPKT_MCC,
>> + NBL_CHAN_MSG_ADD_ND_UPCALL_FLOW,
>> + NBL_CHAN_MSG_DEL_ND_UPCALL_FLOW,
>> + NBL_CHAN_MSG_GET_BOARD_ID,
>> + NBL_CHAN_MSG_SET_SHAPING_DPORT_VLD,
>> + NBL_CHAN_MSG_SET_DPORT_FC_TH_VLD,
>> + NBL_CHAN_MSG_REGISTER_RDMA_BOND,
>> + NBL_CHAN_MSG_UNREGISTER_RDMA_BOND,
>> + NBL_CHAN_MSG_RESTORE_NETDEV_QUEUE,
>> + NBL_CHAN_MSG_RESTART_NETDEV_QUEUE,
>> + NBL_CHAN_MSG_RESTORE_HW_QUEUE,
>> + NBL_CHAN_MSG_KEEP_ALIVE,
>> + NBL_CHAN_MSG_GET_BASE_MAC_ADDR,
>> + NBL_CHAN_MSG_CFG_BOND_SHAPING,
>> + NBL_CHAN_MSG_CFG_BGID_BACK_PRESSURE,
>> + NBL_CHAN_MSG_ALLOC_KT_BLOCK,
>> + NBL_CHAN_MSG_FREE_KT_BLOCK,
>> + NBL_CHAN_MSG_GET_USER_QUEUE_INFO,
>> + NBL_CHAN_MSG_GET_ETH_BOND_INFO,
>> + NBL_CHAN_MSG_CLEAR_ACCEL_FLOW,
>> + NBL_CHAN_MSG_SET_BRIDGE_MODE,
>> + NBL_CHAN_MSG_GET_VF_FUNCTION_ID,
>> + NBL_CHAN_MSG_NOTIFY_LINK_FORCED,
>> + NBL_CHAN_MSG_SET_PMD_DEBUG,
>> + NBL_CHAN_MSG_REGISTER_FUNC_MAC,
>> + NBL_CHAN_MSG_SET_TX_RATE,
>> + NBL_CHAN_MSG_REGISTER_FUNC_LINK_FORCED,
>> + NBL_CHAN_MSG_GET_LINK_FORCED,
>> + NBL_CHAN_MSG_REGISTER_FUNC_VLAN,
>> + NBL_CHAN_MSG_GET_FD_FLOW,
>> + NBL_CHAN_MSG_GET_FD_FLOW_CNT,
>> + NBL_CHAN_MSG_GET_FD_FLOW_ALL,
>> + NBL_CHAN_MSG_GET_FD_FLOW_MAX,
>> + NBL_CHAN_MSG_REPLACE_FD_FLOW,
>> + NBL_CHAN_MSG_REMOVE_FD_FLOW,
>> + NBL_CHAN_MSG_CFG_FD_FLOW_STATE,
>> + NBL_CHAN_MSG_REGISTER_FUNC_RATE,
>> + NBL_CHAN_MSG_NOTIFY_VLAN,
>> + NBL_CHAN_MSG_GET_XDP_QUEUE_INFO,
>> + NBL_CHAN_MSG_STOP_ABNORMAL_SW_QUEUE,
>> + NBL_CHAN_MSG_STOP_ABNORMAL_HW_QUEUE,
>> + NBL_CHAN_MSG_NOTIFY_RESET_EVENT,
>> + NBL_CHAN_MSG_ACK_RESET_EVENT,
>> + NBL_CHAN_MSG_GET_VF_VSI_ID,
>> + NBL_CHAN_MSG_CONFIGURE_QOS,
>> + NBL_CHAN_MSG_GET_PFC_BUFFER_SIZE,
>> + NBL_CHAN_MSG_SET_PFC_BUFFER_SIZE,
>> + NBL_CHAN_MSG_GET_VF_STATS,
>> + NBL_CHAN_MSG_REGISTER_FUNC_TRUST,
>> + NBL_CHAN_MSG_NOTIFY_TRUST,
>> + NBL_CHAN_MSG_CHECK_VF_IS_ACTIVE,
>> + NBL_CHAN_MSG_GET_ETH_ABNORMAL_STATS,
>> + NBL_CHAN_MSG_GET_ETH_CTRL_STATS,
>> + NBL_CHAN_MSG_GET_PAUSE_STATS,
>> + NBL_CHAN_MSG_GET_ETH_MAC_STATS,
>> + NBL_CHAN_MSG_GET_FEC_STATS,
>> + NBL_CHAN_MSG_CFG_MULTI_MCAST_RULE,
>> + NBL_CHAN_MSG_GET_LINK_DOWN_COUNT,
>> + NBL_CHAN_MSG_GET_LINK_STATUS_OPCODE,
>> + NBL_CHAN_MSG_GET_RMON_STATS,
>> + NBL_CHAN_MSG_REGISTER_PF_NAME,
>> + NBL_CHAN_MSG_GET_PF_NAME,
>> + NBL_CHAN_MSG_CONFIGURE_RDMA_BW,
>> + NBL_CHAN_MSG_SET_RATE_LIMIT,
>> + NBL_CHAN_MSG_SET_TC_WGT,
>> + NBL_CHAN_MSG_REMOVE_QUEUE,
>> + NBL_CHAN_MSG_GET_MIRROR_TABLE_ID,
>> + NBL_CHAN_MSG_CONFIGURE_MIRROR,
>> + NBL_CHAN_MSG_CONFIGURE_MIRROR_TABLE,
>> + NBL_CHAN_MSG_CLEAR_MIRROR_CFG,
>> + NBL_CHAN_MSG_MIRROR_OUTPUTPORT_NOTIFY,
>> + NBL_CHAN_MSG_CHECK_FLOWTABLE_SPEC,
>> + NBL_CHAN_MSG_CHECK_VF_IS_VDPA,
>> + NBL_CHAN_MSG_GET_VDPA_VF_STATS,
>> + NBL_CHAN_MSG_SET_RX_RATE,
>> + NBL_CHAN_MSG_GET_UVN_PKT_DROP_STATS,
>> + NBL_CHAN_MSG_GET_USTORE_PKT_DROP_STATS,
>> + NBL_CHAN_MSG_GET_USTORE_TOTAL_PKT_DROP_STATS,
>> + NBL_CHAN_MSG_SET_WOL,
>> + NBL_CHAN_MSG_INIT_VF_MSIX_MAP,
>> + NBL_CHAN_MSG_GET_ST_NAME,
>> + NBL_CHAN_MSG_MTU_SET = 501,
>> + NBL_CHAN_MSG_SET_RXFH_INDIR = 506,
>> + NBL_CHAN_MSG_SET_RXFH_RSS_ALG_SEL = 508,
>> + /* mailbox msg end */
>> + NBL_CHAN_MSG_MAILBOX_MAX,
>> +};
>> +
>This is a big enum. Is there a possibility to group them by functionality?
Thank you for your feedback.
As mentioned in the commit message, for compatibility,
the msg ID values are fixed and cannot be reordered or renumbered.
This constraintensures backward compatibility with existing
implementations that rely on these numeric values.
---illusion.wang
^ permalink raw reply
* Re: [PATCH net-next v9 0/4] net: stmmac: Add PCI driver support for BCM8958x
From: Russell King (Oracle) @ 2026-04-07 7:24 UTC (permalink / raw)
To: Jitendra Vegiraju
Cc: netdev, alexandre.torgue, davem, edumazet, kuba, pabeni,
mcoquelin.stm32, bcm-kernel-feedback-list, richardcochran, ast,
daniel, hawk, john.fastabend, rohan.g.thomas, linux-kernel,
linux-stm32, linux-arm-kernel, bpf, andrew+netdev, horms, sdf, me,
siyanteng, prabhakar.mahadev-lad.rj, weishangjuan, wens,
vladimir.oltean, lizhi2, boon.khai.ng, maxime.chevallier,
chenchuangyu, yangtiezhu, ovidiu.panait.rb, chenhuacai,
florian.fainelli, quic_abchauha
In-Reply-To: <20260402213629.1996133-1-jitendra.vegiraju@broadcom.com>
On Thu, Apr 02, 2026 at 02:36:25PM -0700, Jitendra Vegiraju wrote:
> From: Jitendra Vegiraju <jitendra.vegiraju@broadcom.com>
>
> This patchset adds basic PCI ethernet device driver support for Broadcom
> BCM8958x Automotive Ethernet switch SoC devices.
>
> This SoC device has PCIe ethernet MAC attached to an integrated ethernet
> switch using XGMII interface. The PCIe ethernet controller is presented to
> the Linux host as PCI network device.
> Management of integrated ethernet switch on this SoC is not handled via
> the PCIe interface.
>
> The following block diagram gives an overview of the application.
> +=================================+
> | Host CPU/Linux |
> +=================================+
> || PCIe
> ||
> +==========================================+
> | +--------------+ |
> | | PCIE Endpoint| |
> | | Ethernet | |
> | | Controller | |
> | | DMA | |
> | +--------------+ |
> | | MAC | BCM8958X |
> | +--------------+ SoC |
> | || XGMII |
> | || |
> | +--------------+ |
> | | Ethernet | |
> | | switch | |
> | +--------------+ |
> | || || || || |
> +==========================================+
> || || || || More external interfaces
>
> The MAC block on BCM8958x is based on Synopsis XGMAC 4.00a core. This
> MAC IP introduces new DMA architecture called Hyper-DMA for virtualization
> scalability.
>
> Driver functionality specific to new MAC (DW25GMAC) is implemented in
> new file dw25gmac.c.
Sorry for suggesting this rather late, but I recently came across
another stmmac driver in the kernel - drivers/net/ethernet/synopsys.
This is for XLGMAC, but I wonder whether it may be a better bet for
this core. Have you looked at it?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH v5 8/9] driver core: Replace dev->of_node_reused with dev_of_node_reused()
From: Manivannan Sadhasivam @ 2026-04-07 7:27 UTC (permalink / raw)
To: Douglas Anderson
Cc: Greg Kroah-Hartman, Rafael J . Wysocki, Danilo Krummrich,
Alan Stern, Alexey Kardashevskiy, Johan Hovold, Eric Dumazet,
Leon Romanovsky, Christoph Hellwig, Robin Murphy, maz,
Alexander Lobakin, Saravana Kannan, Mark Brown, alexander.stein,
andrew, andrew, andriy.shevchenko, astewart, bhelgaas, brgl,
davem, devicetree, driver-core, hkallweit1, jirislaby, joel, kees,
kuba, lgirdwood, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-pci, linux-serial, linux-usb, linux, netdev, pabeni, robh
In-Reply-To: <20260406162231.v5.8.I806b8636cd3724f6cd1f5e199318ab8694472d90@changeid>
On Mon, Apr 06, 2026 at 04:23:01PM -0700, Douglas Anderson wrote:
> In C, bitfields are not necessarily safe to modify from multiple
> threads without locking. Switch "of_node_reused" over to the "flags"
> field so modifications are safe.
>
> Cc: Johan Hovold <johan@kernel.org>
> Acked-by: Mark Brown <broonie@kernel.org>
> Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
> Reviewed-by: Danilo Krummrich <dakr@kernel.org>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Manivannan Sadhasivam <mani@kernel.org> # PCI_PWRCTRL
- Mani
> ---
> Not fixing any known bugs; problem is theoretical and found by code
> inspection. Change is done somewhat manually and only lightly tested
> (mostly compile-time tested).
>
> (no changes since v4)
>
> Changes in v4:
> - Use accessor functions for flags
>
> Changes in v3:
> - New
>
> drivers/base/core.c | 2 +-
> drivers/base/pinctrl.c | 2 +-
> drivers/base/platform.c | 2 +-
> drivers/net/pcs/pcs-xpcs-plat.c | 2 +-
> drivers/of/device.c | 6 +++---
> drivers/pci/of.c | 2 +-
> drivers/pci/pwrctrl/core.c | 2 +-
> drivers/regulator/bq257xx-regulator.c | 2 +-
> drivers/regulator/rk808-regulator.c | 2 +-
> drivers/tty/serial/serial_base_bus.c | 2 +-
> drivers/usb/gadget/udc/aspeed-vhub/dev.c | 2 +-
> include/linux/device.h | 7 ++++---
> 12 files changed, 17 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 8a83d7c93361..30825bf83234 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -5283,7 +5283,7 @@ void device_set_of_node_from_dev(struct device *dev, const struct device *dev2)
> {
> of_node_put(dev->of_node);
> dev->of_node = of_node_get(dev2->of_node);
> - dev->of_node_reused = true;
> + dev_set_of_node_reused(dev);
> }
> EXPORT_SYMBOL_GPL(device_set_of_node_from_dev);
>
> diff --git a/drivers/base/pinctrl.c b/drivers/base/pinctrl.c
> index 6e250272c843..0bbc83231234 100644
> --- a/drivers/base/pinctrl.c
> +++ b/drivers/base/pinctrl.c
> @@ -24,7 +24,7 @@ int pinctrl_bind_pins(struct device *dev)
> {
> int ret;
>
> - if (dev->of_node_reused)
> + if (dev_of_node_reused(dev))
> return 0;
>
> dev->pins = devm_kzalloc(dev, sizeof(*(dev->pins)), GFP_KERNEL);
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index d44591d52e36..199e6fb25770 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -856,7 +856,7 @@ struct platform_device *platform_device_register_full(
> pdev->dev.parent = pdevinfo->parent;
> pdev->dev.fwnode = pdevinfo->fwnode;
> pdev->dev.of_node = of_node_get(to_of_node(pdev->dev.fwnode));
> - pdev->dev.of_node_reused = pdevinfo->of_node_reused;
> + dev_assign_of_node_reused(&pdev->dev, pdevinfo->of_node_reused);
>
> if (pdevinfo->dma_mask) {
> pdev->platform_dma_mask = pdevinfo->dma_mask;
> diff --git a/drivers/net/pcs/pcs-xpcs-plat.c b/drivers/net/pcs/pcs-xpcs-plat.c
> index b8c48f9effbf..f4b1b8246ce9 100644
> --- a/drivers/net/pcs/pcs-xpcs-plat.c
> +++ b/drivers/net/pcs/pcs-xpcs-plat.c
> @@ -349,7 +349,7 @@ static int xpcs_plat_init_dev(struct dw_xpcs_plat *pxpcs)
> * up later. Make sure DD-core is aware of the OF-node being re-used.
> */
> device_set_node(&mdiodev->dev, fwnode_handle_get(dev_fwnode(dev)));
> - mdiodev->dev.of_node_reused = true;
> + dev_set_of_node_reused(&mdiodev->dev);
>
> /* Pass the data further so the DW XPCS driver core could use it */
> mdiodev->dev.platform_data = (void *)device_get_match_data(dev);
> diff --git a/drivers/of/device.c b/drivers/of/device.c
> index f7e75e527667..be4e1584e0af 100644
> --- a/drivers/of/device.c
> +++ b/drivers/of/device.c
> @@ -26,7 +26,7 @@
> const struct of_device_id *of_match_device(const struct of_device_id *matches,
> const struct device *dev)
> {
> - if (!matches || !dev->of_node || dev->of_node_reused)
> + if (!matches || !dev->of_node || dev_of_node_reused(dev))
> return NULL;
> return of_match_node(matches, dev->of_node);
> }
> @@ -192,7 +192,7 @@ ssize_t of_device_modalias(struct device *dev, char *str, ssize_t len)
> {
> ssize_t sl;
>
> - if (!dev || !dev->of_node || dev->of_node_reused)
> + if (!dev || !dev->of_node || dev_of_node_reused(dev))
> return -ENODEV;
>
> sl = of_modalias(dev->of_node, str, len - 2);
> @@ -254,7 +254,7 @@ int of_device_uevent_modalias(const struct device *dev, struct kobj_uevent_env *
> {
> int sl;
>
> - if ((!dev) || (!dev->of_node) || dev->of_node_reused)
> + if ((!dev) || (!dev->of_node) || dev_of_node_reused(dev))
> return -ENODEV;
>
> /* Devicetree modalias is tricky, we add it in 2 steps */
> diff --git a/drivers/pci/of.c b/drivers/pci/of.c
> index 9f8eb5df279e..1f9b669abdb0 100644
> --- a/drivers/pci/of.c
> +++ b/drivers/pci/of.c
> @@ -38,7 +38,7 @@ int pci_set_of_node(struct pci_dev *dev)
> struct device *pdev __free(put_device) =
> bus_find_device_by_of_node(&platform_bus_type, node);
> if (pdev)
> - dev->bus->dev.of_node_reused = true;
> + dev_set_of_node_reused(&dev->bus->dev);
>
> device_set_node(&dev->dev, of_fwnode_handle(no_free_ptr(node)));
> return 0;
> diff --git a/drivers/pci/pwrctrl/core.c b/drivers/pci/pwrctrl/core.c
> index 7754baed67f2..72963a92362a 100644
> --- a/drivers/pci/pwrctrl/core.c
> +++ b/drivers/pci/pwrctrl/core.c
> @@ -39,7 +39,7 @@ static int pci_pwrctrl_notify(struct notifier_block *nb, unsigned long action,
> * If we got here then the PCI device is the second after the
> * power control platform device. Mark its OF node as reused.
> */
> - dev->of_node_reused = true;
> + dev_set_of_node_reused(dev);
> break;
> }
>
> diff --git a/drivers/regulator/bq257xx-regulator.c b/drivers/regulator/bq257xx-regulator.c
> index dab8f1ab4450..40e0f1a7ae81 100644
> --- a/drivers/regulator/bq257xx-regulator.c
> +++ b/drivers/regulator/bq257xx-regulator.c
> @@ -143,7 +143,7 @@ static int bq257xx_regulator_probe(struct platform_device *pdev)
> struct regulator_config cfg = {};
>
> pdev->dev.of_node = pdev->dev.parent->of_node;
> - pdev->dev.of_node_reused = true;
> + dev_set_of_node_reused(&pdev->dev);
>
> pdata = devm_kzalloc(&pdev->dev, sizeof(struct bq257xx_reg_data), GFP_KERNEL);
> if (!pdata)
> diff --git a/drivers/regulator/rk808-regulator.c b/drivers/regulator/rk808-regulator.c
> index e66408f23bb6..8297d31cde9f 100644
> --- a/drivers/regulator/rk808-regulator.c
> +++ b/drivers/regulator/rk808-regulator.c
> @@ -2115,7 +2115,7 @@ static int rk808_regulator_probe(struct platform_device *pdev)
> int ret, i, nregulators;
>
> pdev->dev.of_node = pdev->dev.parent->of_node;
> - pdev->dev.of_node_reused = true;
> + dev_set_of_node_reused(&pdev->dev);
>
> regmap = dev_get_regmap(pdev->dev.parent, NULL);
> if (!regmap)
> diff --git a/drivers/tty/serial/serial_base_bus.c b/drivers/tty/serial/serial_base_bus.c
> index a12935f6b992..5f23284a8778 100644
> --- a/drivers/tty/serial/serial_base_bus.c
> +++ b/drivers/tty/serial/serial_base_bus.c
> @@ -74,7 +74,7 @@ static int serial_base_device_init(struct uart_port *port,
> dev->parent = parent_dev;
> dev->bus = &serial_base_bus_type;
> dev->release = release;
> - dev->of_node_reused = true;
> + dev_set_of_node_reused(dev);
>
> device_set_node(dev, fwnode_handle_get(dev_fwnode(parent_dev)));
>
> diff --git a/drivers/usb/gadget/udc/aspeed-vhub/dev.c b/drivers/usb/gadget/udc/aspeed-vhub/dev.c
> index 2ecd049dacc2..8b9449d16324 100644
> --- a/drivers/usb/gadget/udc/aspeed-vhub/dev.c
> +++ b/drivers/usb/gadget/udc/aspeed-vhub/dev.c
> @@ -593,7 +593,7 @@ int ast_vhub_init_dev(struct ast_vhub *vhub, unsigned int idx)
> d->gadget.max_speed = USB_SPEED_HIGH;
> d->gadget.speed = USB_SPEED_UNKNOWN;
> d->gadget.dev.of_node = vhub->pdev->dev.of_node;
> - d->gadget.dev.of_node_reused = true;
> + dev_set_of_node_reused(&d->gadget.dev);
>
> rc = usb_add_gadget_udc(d->port_dev, &d->gadget);
> if (rc != 0)
> diff --git a/include/linux/device.h b/include/linux/device.h
> index 5b0fb6ad4c72..a79865a212e9 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -483,6 +483,8 @@ struct device_physical_location {
> * driver/bus sync_state() callback.
> * @DEV_FLAG_DMA_COHERENT: This particular device is dma coherent, even if the
> * architecture supports non-coherent devices.
> + * @DEV_FLAG_OF_NODE_REUSED: Set if the device-tree node is shared with an
> + * ancestor device.
> */
> enum struct_device_flags {
> DEV_FLAG_READY_TO_PROBE = 0,
> @@ -492,6 +494,7 @@ enum struct_device_flags {
> DEV_FLAG_DMA_OPS_BYPASS = 4,
> DEV_FLAG_STATE_SYNCED = 5,
> DEV_FLAG_DMA_COHERENT = 6,
> + DEV_FLAG_OF_NODE_REUSED = 7,
>
> DEV_FLAG_COUNT
> };
> @@ -573,8 +576,6 @@ enum struct_device_flags {
> *
> * @offline_disabled: If set, the device is permanently online.
> * @offline: Set after successful invocation of bus type's .offline().
> - * @of_node_reused: Set if the device-tree node is shared with an ancestor
> - * device.
> * @flags: DEV_FLAG_XXX flags. Use atomic bitfield operations to modify.
> *
> * At the lowest level, every device in a Linux system is represented by an
> @@ -681,7 +682,6 @@ struct device {
>
> bool offline_disabled:1;
> bool offline:1;
> - bool of_node_reused:1;
>
> DECLARE_BITMAP(flags, DEV_FLAG_COUNT);
> };
> @@ -715,6 +715,7 @@ __create_dev_flag_accessors(dma_skip_sync, DEV_FLAG_DMA_SKIP_SYNC);
> __create_dev_flag_accessors(dma_ops_bypass, DEV_FLAG_DMA_OPS_BYPASS);
> __create_dev_flag_accessors(state_synced, DEV_FLAG_STATE_SYNCED);
> __create_dev_flag_accessors(dma_coherent, DEV_FLAG_DMA_COHERENT);
> +__create_dev_flag_accessors(of_node_reused, DEV_FLAG_OF_NODE_REUSED);
>
> #undef __create_dev_flag_accessors
>
> --
> 2.53.0.1213.gd9a14994de-goog
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [net-next PATCH 01/10] net: dsa: tag_rtl8_4: update format description
From: Linus Walleij @ 2026-04-07 7:33 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Alvin Šipraga,
Yury Norov, Rasmus Villemoes, Russell King, netdev, linux-kernel
In-Reply-To: <20260331-realtek_forward-v1-1-44fb63033b7e@gmail.com>
On Wed, Apr 1, 2026 at 1:00 AM Luiz Angelo Daros de Luca
<luizluca@gmail.com> wrote:
> From: Alvin Šipraga <alsi@bang-olufsen.dk>
>
> Document the updated tag layout fields (EFID, VSEL/VIDX) and clarify
> which bits are set/cleared when emitting tags.
>
> Co-developed-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ 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