* Re: [PATCH nf] ipvs: skip IPv6 extension headers in SCTP state lookup
From: Yizhou Zhao @ 2026-07-06 8:22 UTC (permalink / raw)
To: Julian Anastasov
Cc: netdev, Simon Horman, Pablo Neira Ayuso, Florian Westphal,
Phil Sutter, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, lvs-devel, netfilter-devel, coreteam, linux-kernel,
Yuxiang Yang, Ao Wang, Xuewei Feng, Qi Li, Ke Xu, stable
In-Reply-To: <92783c87-7e6a-e90a-b2fc-e5d1332139e0@ssi.bg>
Hi Julian,
Thanks for your review.
> On Jul 6, 2026, at 01:35, Julian Anastasov <ja@ssi.bg> wrote:
>
> May be it is better starting from ip_vs_set_state()
> to provide new arg 'int iph_len/offset' (set to iph.len), down to
> state_transition(), sctp_state_transition() and set_sctp_state().
> Same for all protos. It should cost less stack and ipv6_find_hdr()
> calls and what matters most, correct iph context in case we
> have IP+ICMP+TCP (with just two ports or even with TCP flags)
> and are scheduling ICMP, i.e. not IP+TCP as usually.
I agree that the already parsed transport-header offset should be
passed from ip_vs_set_state() down to the protocol state_transition()
callbacks, instead of reparsing the skb in set_sctp_state(). We will
send a v2 that does this for SCTP, TCP and the other IPVS protocols
in one combined fix.
> But what I see is that ip_vs_in_icmp*() are missing
> the ip_vs_set_state(cp, IP_VS_DIR_INPUT, skb, pd) call just
> after ip_vs_in_stats() and before ip_vs_icmp_xmit() where
> we should provide ciph.len. That is why we don't reach the
> set_tcp_state() calls to set correct cp->state and timeout
> when scheduling related ICMP. So, this should be fixed too.
For the ICMP path, I agree that the missing ip_vs_set_state() call is
worth looking at, but using ICMP errors to drive the upper L4 state
needs some care, because spoofed ICMP packets can match an
existing embedded tuple before the endpoint TCP/SCTP stack
performs its own validation. Maybe this change needs further
discussion?
Thanks,
Yizhou
^ permalink raw reply
* Re: [PATCH net 0/9] netfilter: updates for net
From: Florian Westphal @ 2026-07-06 8:26 UTC (permalink / raw)
To: netdev
Cc: Paolo Abeni, David S. Miller, Eric Dumazet, Jakub Kicinski,
netfilter-devel, pablo
In-Reply-To: <20260703125709.16493-1-fw@strlen.de>
Florian Westphal <fw@strlen.de> wrote:
> The following patchset contains Netfilter fixes for *net*, all
> for ancient problems. Patch 7 raised drive-by sashiko findings,
> but those are not related to the change itself.
There more unrelated findings, those will be addressed in a future PR.
^ permalink raw reply
* Re: [PATCH net] net: stmmac: intel: don't reconfigure SerDes on unchanged mode
From: Maxime Chevallier @ 2026-07-06 8:29 UTC (permalink / raw)
To: Markus Breitenberger, netdev
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Choong Yong Liang, stable, Markus Breitenberger
In-Reply-To: <20260706061954.94842-1-bre@breiti.cc>
Hi Markus,
On 7/6/26 08:19, Markus Breitenberger wrote:
> From: Markus Breitenberger <bre@keba.com>
>
> intel_mac_finish() is registered as the phylink mac_finish() callback
> for the Elkhart Lake SGMII ports. phylink calls mac_finish() at the end
> of every major link reconfiguration, including the initial one during
> probe, before any interface mode has actually changed.
>
> The callback reprograms the shared ModPHY LCPLL through the PMC IPC and
> then power-cycles the SerDes. On Elkhart Lake that ModPHY is also used
> by the on-die AHCI SATA PHY. Running the reconfiguration during the
> initial boot-time link-up disturbs the shared analog block while it is
> still driving SATA, so the SATA link fails to train:
>
> ata1: SATA link down (SStatus 1 SControl 300)
>
> The disk carrying the root filesystem is never detected and the system
> hangs at rootwait. Ethernet itself comes up normally, which makes the
> failure look unrelated to the network driver.
>
> Firmware already programs the ModPHY for the configured interface, so
> the reconfiguration is redundant unless the interface mode really
> changes. Return early when the requested mode equals the current one.
> This avoids touching the shared ModPHY (and the SATA PHY) during boot
> while preserving runtime SGMII to 2500BASE-X switching, which still
> sees a genuine mode change and reconfigures as before.
One thing is that now we 'blindly' rely on the bootloader / fw having
correctly configured the initial interface.
From what I see the only configuration that's done is regarding the serdes
rate. Maybe instead the serdes interaction logic can be reworked so that you
query the serdes rate, see if you need to adjust it based on the selected
interface, and if so you re-configure it ?
Maxime
^ permalink raw reply
* Re: [PATCH net-next] net: dpaa_eth: convert to napi_gro_receive
From: Vladimir Oltean @ 2026-07-06 8:39 UTC (permalink / raw)
To: Rosen Penev
Cc: netdev, Madalin Bucur, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, open list
In-Reply-To: <20260706030632.1826810-1-rosenp@gmail.com>
Hi Rosen,
On Sun, Jul 05, 2026 at 08:06:32PM -0700, Rosen Penev wrote:
> Replace netif_receive_skb() with napi_gro_receive() to improve receive
> performance for this driver. It has rx checksum support so routing speed
> shouldn't suffer.
>
> Tested on a WatchGuard Firebox M300.
>
> iperf3 bidir speed test:
>
> [ ID][Role] Interval Transfer Bitrate Retr
> [ 5][TX-C] 0.00-60.01 sec 5.35 GBytes 766 Mbits/sec 184 sender
> [ 5][TX-C] 0.00-60.02 sec 5.35 GBytes 766 Mbits/sec receiver
> [ 7][RX-C] 0.00-60.01 sec 5.50 GBytes 787 Mbits/sec 124 sender
> [ 7][RX-C] 0.00-60.02 sec 5.49 GBytes 786 Mbits/sec receiver
>
> After:
>
> [ ID][Role] Interval Transfer Bitrate Retr
> [ 5][TX-C] 0.00-60.01 sec 6.49 GBytes 929 Mbits/sec 0 sender
> [ 5][TX-C] 0.00-60.02 sec 6.49 GBytes 928 Mbits/sec receiver
> [ 7][RX-C] 0.00-60.01 sec 6.55 GBytes 938 Mbits/sec 0 sender
> [ 7][RX-C] 0.00-60.02 sec 6.55 GBytes 937 Mbits/sec receiver
>
> Assisted-by: Opencode:big-pickle
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> index ad2d8256eb8d..83191f636ec7 100644
> --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> @@ -2824,10 +2824,7 @@ static enum qman_cb_dqrr_result rx_default_dqrr(struct qman_portal *portal,
>
> skb_len = skb->len;
>
> - if (unlikely(netif_receive_skb(skb) == NET_RX_DROP)) {
> - percpu_stats->rx_dropped++;
> - return qman_cb_dqrr_consume;
> - }
> + napi_gro_receive(&np->napi, skb);
>
> percpu_stats->rx_packets++;
> percpu_stats->rx_bytes += skb_len;
> --
> 2.55.0
>
>
(thanks to Madalin for pointing out this change to me)
I do not have time this week to test this patch, but in premise, you are
creating exactly the conditions for this bug to occur:
https://github.com/nxp-qoriq/linux/commit/d0ebec2092d6c5fe327513cb66e02d8c2c1a8f87
In sdk_dpaa we already do GRO for TCP flows and it has the problems
pointed out in the above commit. With your change to use GRO for all
capable flows, I currently have no reason to believe that without
similar countermeasures as those taken by sdk_dpaa (napi_gro_receive()
global to the entire QMan portal) the outcome would be different.
Have you tested traffic in mixed scenarios, where flows from multiple
interfaces land on the same CPU?
Until further evidence comes in:
pw-bot: cr
^ permalink raw reply
* Re: [PATCH] timekeeping: Document monotonic raw timestamps in snapshots correctly
From: Thomas Weißschuh @ 2026-07-06 8:42 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, David Woodhouse, Miroslav Lichvar, John Stultz,
Stephen Boyd, Anna-Maria Behnsen, Frederic Weisbecker,
Arthur Kiyanovski, Rodolfo Giometti, Vincent Donnefort,
Marc Zyngier, Oliver Upton, kvmarm, Oliver Upton, Richard Cochran,
netdev, Takashi Iwai, Miri Korenblit, Johannes Berg, Jacob Keller,
Tony Nguyen, Saeed Mahameed, Peter Hilber, Michael S. Tsirkin,
virtualization, linux-wireless, linux-sound
In-Reply-To: <87wlv9k3wz.ffs@fw13>
On Sun, Jul 05, 2026 at 02:38:04PM +0200, Thomas Gleixner wrote:
> The comments related to raw monotonic timestamps for the various
> snapshot mechanisms in code and struct documentation are ambiguous. They
> reference them as CLOCK_MONOTONIC_RAW timestamps, but with the arrival
> of AUX clocks that's not longer correct.
>
> The raw monotonic timestamps only represent CLOCK_MONOTONIC_RAW for the
> system time clock IDs, i.e. REALTIME, MONOTONIC, BOOTTIME, TAI.
>
> For AUX clocks they refer to the monotonic raw clock which is related to
> the individual AUX clocks. These monotonic raw timestamps have the same
> conversion factor as CLOCK_MONOTONIC_RAW, but differ from that by an
> offset:
>
> MONORAW(AUX$N) = MONORAW(SYSTEM) + OFFSET(AUX$N)
>
> The offset is established when a AUX clock is enabled and stays constant
> for the lifetime of the AUX clock.
>
> Update the comments so they reflect reality.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Reported-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Thanks!
Reviewed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
(...)
^ permalink raw reply
* [PATCH] bonding: fix devconf_all NULL dereference when IPv6 is disabled
From: zhangzl2013 @ 2026-07-06 8:45 UTC (permalink / raw)
To: Zhaolong Zhang, Jay Vosburgh
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Hangbin Liu, netdev, linux-kernel, Qianheng Peng,
Zhaolong Zhang
From: Zhaolong Zhang <zhangzl68@chinatelecom.cn>
When booting with the 'ipv6.disable=1' parameter, the devconf_all is
never initialized because inet6_init() exits before addrconf_init() is
called which initializes it. bond_send_validate(), however, will still
call bond_ns_send_all() even ipv6 is indeed disabled. It will lead to
NULL derefence of net->ipv6.devconf_all in ip6_pol_route().
BUG: kernel NULL pointer dereference, address: 000000000000000c
[...]
Workqueue: bond0 bond_arp_monitor [bonding]
RIP: 0010:ip6_pol_route+0x69/0x480
[...]
Call Trace:
<TASK>
? srso_return_thunk+0x5/0x5f
? __pfx_ip6_pol_route_output+0x10/0x10
fib6_rule_lookup+0xfe/0x260
? wakeup_preempt+0x8a/0x90
? srso_return_thunk+0x5/0x5f
? srso_return_thunk+0x5/0x5f
? sched_balance_rq+0x369/0x810
ip6_route_output_flags+0xd7/0x170
bond_ns_send_all+0xde/0x280 [bonding]
bond_ab_arp_probe+0x296/0x320 [bonding]
? srso_return_thunk+0x5/0x5f
bond_activebackup_arp_mon+0xb4/0x2c0 [bonding]
process_one_work+0x196/0x370
worker_thread+0x1af/0x320
? srso_return_thunk+0x5/0x5f
? __pfx_worker_thread+0x10/0x10
kthread+0xe3/0x120
? __pfx_kthread+0x10/0x10
ret_from_fork+0x199/0x260
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK>
Fix this by adding ipv6_mod_enabled() condition check in the caller.
Fixes: 4e24be018eb9 ("bonding: add new parameter ns_targets")
Signed-off-by: Qianheng Peng <pengqh1@chinatelecom.cn>
Signed-off-by: Zhaolong Zhang <zhangzl68@chinatelecom.cn>
---
drivers/net/bonding/bond_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index e044fc733b8c..522eab060f9e 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3455,7 +3455,8 @@ static void bond_send_validate(struct bonding *bond, struct slave *slave)
{
bond_arp_send_all(bond, slave);
#if IS_ENABLED(CONFIG_IPV6)
- bond_ns_send_all(bond, slave);
+ if (likely(ipv6_mod_enabled()))
+ bond_ns_send_all(bond, slave);
#endif
}
--
2.52.0
^ permalink raw reply related
* Re: [PATCH rdma-next v9] RDMA: Change capability fields in ib_device_attr from int to u32
From: Leon Romanovsky @ 2026-07-06 8:49 UTC (permalink / raw)
To: Erni Sri Satya Vennela
Cc: Jason Gunthorpe, mkalderon, zyjzyj2000, sagi, mgurtovoy,
haris.iqbal, jinpu.wang, bvanassche, kbusch, Jens Axboe,
Christoph Hellwig, kch, smfrench, linkinjeon, metze, tom, cel,
jlayton, neil, okorniev, Dai.Ngo, trondmy, anna, achender, davem,
edumazet, kuba, pabeni, horms, kees, andriy.shevchenko, clm,
ebadger, linux-rdma, linux-kernel, target-devel, linux-nvme,
linux-cifs, samba-technical, linux-nfs, netdev, rds-devel,
Jason Gunthorpe
In-Reply-To: <20260703060329.896125-1-ernis@linux.microsoft.com>
On Thu, Jul 02, 2026 at 11:02:57PM -0700, Erni Sri Satya Vennela wrote:
> The capability counter fields in struct ib_device_attr are declared
> as signed int, but these values are inherently non-negative. Drivers
> maintain their cached caps as u32 and assign them directly into these
> int fields; if a cap exceeds INT_MAX the implicit narrowing yields a
> negative value visible to the IB core.
>
> Change the signed int capability fields to u32 to match the
> underlying nature of the data. Also update consumers across the IB
> core, ULPs, NVMe-oF target, RDS, and NFS/RDMA so the new u32 values
> are not forced back through signed int or u8 via min()/min_t() or
> narrowing local variables.
>
> Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
> Signed-off-by: Erni Sri Satya Vennela <ernis@linux.microsoft.com>
> Acked-by: Stefan Metzmacher <metze@samba.org> # smbdirect
> ---
> Changes in v9:
> * Switch the srq_size module parameter accessors to param_get_uint and
> kstrtouint()/param_set_uint() so they match the now-unsigned
> nvmet_rdma_srq_size variable.
> Changes in v8:
> * Convert the remaining non-negative counter fields max_ee_rd_atom,
> max_ee_init_rd_atom, max_ee, max_rdd, max_raw_ipv6_qp and max_srq_wr
> to u32; keep max_srq as int (its consumer compares it against
> ib_device.num_comp_vectors, still int).
> * Drop all remaining min_t() where plain min() now works.
> * Make the srq_size module parameters unsigned int so the srq_size min()
> stays a plain min().
> * Replace the ternary-inside-min() with the simpler "if (x) x--;".
> * Reorder the send_queue_depth min() to min(value, CONST) to match the
> sibling site.
> * Restore reverse xmas-tree declaration order.
> * Collapse the min()/min3() assignments that now fit onto a single line
> within 100 columns.
> * Print the now-u32 fields with %u instead of %d.
> Changes in v7:
> * Drop min_t() in all sites where a plain min() (or min3()) works
> cleanly
> * Guard nvme/host/rdma.c num_inline_segments computation against a
> device reporting max_send_sge == 0, so the u32 subtract
> cannot wrap to UINT_MAX.
> * Use %u when printing the newly-u32 capability fields
> in diagnostic messages.
> Changes in v6:
> * Fix subject prefix: net-next -> rdma-next.
> Changes in v5:
> * Add U8_MAX clamps in iser_verbs, nvme/host, nvme/target, isert,
> * rds/ib_cm, smbdirect/connect and smbdirect/accept where u32 capability
> fields were directly narrowed into u8 rdma_conn_param fields without
> clamping.
> * Guard the inline_sge_count calculation in nvmet_rdma_find_get_device()
> to prevent u32 underflow when both max_sge_rd and max_recv_sge are
> zero.
> * Expand type migration to 9 additional fields (max_mw, max_raw_ethy_qp,
> max_mcast_grp, max_mcast_qp_attach, max_total_mcast_qp_attach, max_ah,
> max_srq, max_srq_wr, max_srq_sge)
> * Fix min_t(int,...) in svc_rdma_transport; min_t(u32,...) in ipoib,
> srpt, nvme/target, rds/ib, rtrs-clt, rtrs-srv, xprtrdma/verbsdd.
> * Fix frwr_ops.c u32 underflow guard (reorder check before subtraction)
> * Change sc_max_send_sges to unsigned int, inline_sge_count to u32
> * Fix %d -> %u in rxe_qp, rxe_srq, ipoib_cm, ib_isert,
> * svc_rdma_transport
> * Update commit message.
> Changes in v4:
> * Drop clamping the values in mana_ib_query_device, instead update
> the props values from int to u32.
> Changes in v3:
> * Drop clamping from mana_ib_gd_query_adapter_caps(). The internal u32
> caps cache does not need to be clamped.
> * Move all clamping exclusively to mana_ib_query_device(), which is the
> only place the cached u32 values are narrowed into the signed int
> fields of struct ib_device_attr.
> * Reframe commit message: this is a u32-to-int type boundary fix, not a
> CVM/untrusted-hardware hardening patch.
> Changes in v2:
> * Update patch title.
> ---
> drivers/infiniband/core/cq.c | 3 +-
> drivers/infiniband/hw/qedr/verbs.c | 2 +-
> drivers/infiniband/sw/rxe/rxe_qp.c | 22 +++++-----
> drivers/infiniband/sw/rxe/rxe_srq.c | 16 +++----
> drivers/infiniband/ulp/ipoib/ipoib_cm.c | 10 ++---
> drivers/infiniband/ulp/ipoib/ipoib_verbs.c | 3 +-
> drivers/infiniband/ulp/iser/iser_verbs.c | 5 +--
> drivers/infiniband/ulp/isert/ib_isert.c | 7 ++-
> drivers/infiniband/ulp/rtrs/rtrs-clt.c | 11 ++---
> drivers/infiniband/ulp/rtrs/rtrs-srv.c | 11 ++---
> drivers/infiniband/ulp/srp/ib_srp.c | 2 +-
> drivers/infiniband/ulp/srpt/ib_srpt.c | 21 +++++----
> drivers/nvme/host/rdma.c | 8 ++--
> drivers/nvme/target/rdma.c | 22 ++++++----
> fs/smb/smbdirect/accept.c | 5 ++-
> fs/smb/smbdirect/connect.c | 5 ++-
> fs/smb/smbdirect/connection.c | 8 ++--
> include/linux/sunrpc/svc_rdma.h | 4 +-
> include/rdma/ib_verbs.h | 50 +++++++++++-----------
> net/rds/ib.c | 10 ++---
> net/rds/ib_cm.c | 10 ++---
> net/sunrpc/xprtrdma/frwr_ops.c | 7 +--
> net/sunrpc/xprtrdma/svc_rdma_transport.c | 5 +--
> net/sunrpc/xprtrdma/verbs.c | 2 +-
> 24 files changed, 122 insertions(+), 127 deletions(-)
The following code is still missing. Also, what about mxa_srq?
Why wasn't it converted as well?
diff --git a/drivers/infiniband/core/nldev.c b/drivers/infiniband/core/nldev.c
index f599c24b34e8..aae4f3f6bcba 100644
--- a/drivers/infiniband/core/nldev.c
+++ b/drivers/infiniband/core/nldev.c
@@ -454,7 +454,8 @@ static int fill_res_info(struct sk_buff *msg, struct ib_device *device,
};
struct nlattr *table_attr;
- int ret, i, curr, max;
+ u64 curr, max;
+ int ret, i;
if (fill_nldev_handle(msg, device))
return -EMSGSIZE;
diff --git a/drivers/infiniband/core/restrack.c b/drivers/infiniband/core/restrack.c
index cfee2071586c..1b2f9df49e28 100644
--- a/drivers/infiniband/core/restrack.c
+++ b/drivers/infiniband/core/restrack.c
@@ -61,7 +61,7 @@ void rdma_restrack_clean(struct ib_device *dev)
* @type: actual type of object to operate
* @show_details: count driver specific objects
*/
-int rdma_restrack_count(struct ib_device *dev, enum rdma_restrack_type type,
+u32 rdma_restrack_count(struct ib_device *dev, enum rdma_restrack_type type,
bool show_details)
{
struct rdma_restrack_root *rt = &dev->res[type];
diff --git a/include/rdma/restrack.h b/include/rdma/restrack.h
index 451f99e3717d..c081384740ce 100644
--- a/include/rdma/restrack.h
+++ b/include/rdma/restrack.h
@@ -123,7 +123,7 @@ struct rdma_restrack_entry {
u32 id;
};
-int rdma_restrack_count(struct ib_device *dev, enum rdma_restrack_type type,
+u32 rdma_restrack_count(struct ib_device *dev, enum rdma_restrack_type type,
bool show_details);
/**
* rdma_is_kernel_res() - check the owner of resource
^ permalink raw reply related
* Re: [PATCH 05/13] mfd: replace linux/gpio.h inclusions
From: Charles Keepax @ 2026-07-06 8:59 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, Arnd Bergmann, Bartosz Golaszewski, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Greg Ungerer, Thomas Bogendoerfer,
Hauke Mehrtens, Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Linus Walleij, Dmitry Torokhov,
Jakub Kicinski, Paolo Abeni, Dominik Brodowski, linux-kernel,
linux-arm-kernel, linux-samsung-soc, patches, linux-m68k,
linux-mips, linux-sh, linux-input, linux-media, netdev,
linux-sunxi, linux-phy, linux-rockchip, linux-sound
In-Reply-To: <20260629132633.1300009-6-arnd@kernel.org>
On Mon, Jun 29, 2026 at 03:26:25PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> linux/gpio.h should no longer be used, convert these instead to
> either linux/gpio/consumer.h or linux/gpio/legacy.h as needed.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/mfd/arizona-irq.c | 2 +-
> drivers/mfd/wm8994-irq.c | 2 +-
For the wolfson bits:
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Thanks,
Charles
^ permalink raw reply
* Re: [PATCH net 2/3] net/sched: Handle TC_ACT_REDIRECT from qdisc filter chains
From: Paolo Abeni @ 2026-07-06 9:01 UTC (permalink / raw)
To: Daniel Borkmann, kuba
Cc: jhs, bigeasy, andrii, memxor, bpf, netdev, Victor Nogueira
In-Reply-To: <20260630123331.186840-3-daniel@iogearbox.net>
On 6/30/26 2:33 PM, Daniel Borkmann wrote:
> From: Jamal Hadi Salim <jhs@mojatatu.com>
>
> When a TC filter attached to a qdisc filter chain returns
> TC_ACT_REDIRECT (ex: via an eBPF program calling bpf_redirect() or an
> act_bpf action), the redirect was silently lost i.e no qdisc classify
> function handled TC_ACT_REDIRECT, so the packet fell through the
> switch and was enqueued normally instead of being redirected.
>
> This has been broken since bpf_redirect() was introduced for TC in
> commit 27b29f63058d ("bpf: add bpf_redirect() helper"). We got lucky
> for a long time because bpf_net_context was a per-CPU variable that
> was always available.
>
> commit 401cb7dae813 ("net: Reference bpf_redirect_info via task_struct
> on PREEMPT_RT.") turned bpf_net_context into a task_struct member that
> is only set up by explicit callers. Without a caller setting it up,
> bpf_redirect() itself crashes with a NULL pointer dereference in
> bpf_net_ctx_get_ri(). However, even with bpf_net_context available,
> TC_ACT_REDIRECT from qdisc filter chains cannot be honored without
> adding skb_do_redirect() calls to every qdisc classify function, which
> would require changes across net/sched/. Isolate it to ebpf core where
> it belongs.
>
> Instead, add a tcf_classify_qdisc() inline helper in pkt_cls.h, as a
> wrapper around tcf_classify() for use by qdisc classify functions and
> tcf_qevent_handle(). When the classify verdict is TC_ACT_REDIRECT,
> the wrapper converts it to TC_ACT_SHOT, dropping the packet rather
> than letting it continue silently. Dropping is preferred over
> letting the packet through because the user immediately sees packet
> loss. Silently passing the packet through would hide the problem and
> leave the user wondering why their redirect is not working.
>
> The clsact fast path, tc_run() continues to call tcf_classify() directly
> and is unaffected: TC_ACT_REDIRECT is returned as-is and handled by
> sch_handle_egress/ingress() calling skb_do_redirect() as before.
>
> Fixes: 27b29f63058d ("bpf: add bpf_redirect() helper")
> Fixes: 401cb7dae813 ("net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.")
> Tested-by: Victor Nogueira <victor@mojatatu.com>
> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
I'm sorry, this does not apply cleanly anymore.
Could you please rebase and repost?
Thanks!
Paolo
^ permalink raw reply
* [PATCH net v3] ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF
From: Norbert Szetei @ 2026-07-06 9:01 UTC (permalink / raw)
To: netdev
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Qingfang Deng, Yue Haibing, Guillaume Nault,
Kees Cook, Taegu Ha, linux-ppp, netdev, linux-kernel, gnault
pppol2tp_recv() runs in the L2TP UDP-encap softirq RX path:
l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv()
-> ppp_input(&po->chan)
It runs under rcu_read_lock() holding only an l2tp_session reference and
takes NO reference on the internal PPP channel (struct channel,
chan->ppp) that ppp_input() dereferences.
The pppox socket is SOCK_RCU_FREE, so 'po' and the embedded ppp_channel
are RCU-safe. But the internal struct channel is a separate allocation
that ppp_release_channel() frees with a plain kfree():
close(data socket) -> pppol2tp_release() -> pppox_unbind_sock()
-> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch)
For a channel that is bound (PPPIOCGCHAN) but not attached to a ppp unit
(no PPPIOCCONNECT, pch->ppp == NULL) and not bridged, teardown skips
both ppp_disconnect_channel()'s synchronize_net() and
ppp_unbridge_channels()'s synchronize_rcu(), so the kfree() has no grace
period. rcu_read_lock() in pppol2tp_recv() does not protect against a
plain kfree(), so an in-flight ppp_input() on one CPU can dereference
the channel just freed by close() on another CPU.
The bug is reachable by an unprivileged user.
Defer the channel free to an RCU callback via call_rcu() so the grace
period fences any in-flight ppp_input(). The disconnect and unbridge
teardown paths already fence with synchronize_net()/synchronize_rcu();
call_rcu() does the same here without stalling the close() path.
Fixes: ee40fb2e1eb5 ("l2tp: protect sock pointer of struct pppol2tp_session with RCU")
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Norbert Szetei <norbert@doyensec.com>
---
v3:
- Added rcu_barrier() at the end of ppp_cleanup() to ensure all
ppp_release_channel_free() callbacks complete before the module's
text segment is unloaded (Documentation/RCU/rcubarrier.rst).
v2: https://lore.kernel.org/linux-ppp/D9C0245B-608B-4884-8A09-F55BA4A9F948@doyensec.com/
- Moved skb_queue_purge() to a dedicated RCU callback to prevent leaking
skbs added by an in-flight ppp_input() during the grace period (Sebastian).
- Retained call_rcu() to avoid introducing synchronous multi-millisecond
latency into the teardown path.
v1: https://lore.kernel.org/netdev/C954A7EA-AA98-4E3C-80B5-42C34B3183A3@doyensec.com/
drivers/net/ppp/ppp_generic.c | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
index 57c68efa5ff8..717c1d3aa953 100644
--- a/drivers/net/ppp/ppp_generic.c
+++ b/drivers/net/ppp/ppp_generic.c
@@ -184,6 +184,7 @@ struct channel {
struct list_head clist; /* link in list of channels per unit */
spinlock_t upl; /* protects `ppp' and 'bridge' */
struct channel __rcu *bridge; /* "bridged" ppp channel */
+ struct rcu_head rcu; /* for RCU-deferred free of the channel */
#ifdef CONFIG_PPP_MULTILINK
u8 avail; /* flag used in multilink stuff */
u8 had_frag; /* >= 1 fragments have been sent */
@@ -3562,6 +3563,18 @@ ppp_disconnect_channel(struct channel *pch)
return err;
}
+/* Purge after the grace period: a late ppp_input() may still queue an
+ * skb on pch->file.rq before the last RCU reader drains.
+ */
+static void ppp_release_channel_free(struct rcu_head *rcu)
+{
+ struct channel *pch = container_of(rcu, struct channel, rcu);
+
+ skb_queue_purge(&pch->file.xq);
+ skb_queue_purge(&pch->file.rq);
+ kfree(pch);
+}
+
/*
* Drop a reference to a ppp channel and free its memory if the refcount reaches
* zero.
@@ -3581,9 +3594,7 @@ static void ppp_release_channel(struct channel *pch)
pr_err("ppp: destroying undead channel %p !\n", pch);
return;
}
- skb_queue_purge(&pch->file.xq);
- skb_queue_purge(&pch->file.rq);
- kfree(pch);
+ call_rcu(&pch->rcu, ppp_release_channel_free);
}
static void __exit ppp_cleanup(void)
@@ -3596,6 +3607,7 @@ static void __exit ppp_cleanup(void)
device_destroy(&ppp_class, MKDEV(PPP_MAJOR, 0));
class_unregister(&ppp_class);
unregister_pernet_device(&ppp_net_ops);
+ rcu_barrier(); /* wait for RCU callbacks before module unload */
}
/*
--
2.55.0
^ permalink raw reply related
* Re: [PATCH 07/13] ASoC: replace linux/gpio.h inclusions
From: Charles Keepax @ 2026-07-06 9:01 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, Arnd Bergmann, Bartosz Golaszewski, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Greg Ungerer, Thomas Bogendoerfer,
Hauke Mehrtens, Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Linus Walleij, Dmitry Torokhov,
Jakub Kicinski, Paolo Abeni, Dominik Brodowski, linux-kernel,
linux-arm-kernel, linux-samsung-soc, patches, linux-m68k,
linux-mips, linux-sh, linux-input, linux-media, netdev,
linux-sunxi, linux-phy, linux-rockchip, linux-sound
In-Reply-To: <20260629132633.1300009-8-arnd@kernel.org>
On Mon, Jun 29, 2026 at 03:26:27PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> linux/gpio.h is going away,s o use linux/gpio/consumer.h instead.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> sound/soc/codecs/cs42l84.c | 2 +-
> sound/soc/codecs/cx2072x.c | 2 +-
For the Cirrus bits:
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Thanks,
Charles
^ permalink raw reply
* RE: [PATCH iwl-net v1] idpf: fix lan_regs leak on core init failure
From: Jagielski, Jedrzej @ 2026-07-06 9:12 UTC (permalink / raw)
To: xuanqiang.luo@linux.dev, intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Nguyen, Anthony L, Kitszel, Przemyslaw, Andrew Lunn,
Hay, Joshua A, Nikolova, Tatyana E, Xuanqiang Luo
In-Reply-To: <20260703104132.47419-1-xuanqiang.luo@linux.dev>
From: xuanqiang.luo@linux.dev <xuanqiang.luo@linux.dev>
Sent: Friday, July 3, 2026 12:42 PM
>From: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
>
>idpf_vc_core_init() gets the LAN memory region layout before mapping the
>regions and allocating vport resources. Both layout paths allocate
>hw->lan_regs, but later error paths return without freeing it.
>
>idpf_vc_core_deinit() does not cover these paths because it returns unless
>IDPF_VC_CORE_INIT is set, and that bit is set only after core init
>succeeds.
>
>Free hw->lan_regs on the post-allocation error paths and clear the
>pointer and region count.
>
>Fixes: 6aa53e861c1a ("idpf: implement get LAN MMIO memory regions")
>Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Looks fine, thanks for the patch!
Reviewed-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
^ permalink raw reply
* Re: [PATCH net-next v2 1/3] net: ti: icssm-prueth: Add HSR and PRP HW offload mode support for AM57xx, AM437x and AM335x
From: Paolo Abeni @ 2026-07-06 9:13 UTC (permalink / raw)
To: parvathi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, danishanwar, rogerq,
pmohan, afd, basharath, arnd, linux-kernel, netdev,
linux-arm-kernel, pratheesh, j-rameshbabu, vigneshr, praneeth,
srk, rogerq, m-malladi, krishna, mohan
In-Reply-To: <20260630124958.894360-2-parvathi@couthit.com>
From: AI Reviewer <ai@example.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev/
---
Subject: net: ti: icssm-prueth: Add HSR and PRP HW offload mode support for AM57xx, AM437x and AM335x
This commit introduces hardware offload support for the HSR and PRP redundancy
protocols on TI PRU-ICSS Ethernet MACs. It enables firmware-based frame
duplicate detection and L2 forwarding, treating PRU Ethernet ports as Link
Redundancy Entity (LRE) slaves. The driver can now dynamically switch between
dual-EMAC, switch, and HSR/PRP modes.
> diff --git a/drivers/net/ethernet/ti/icssm/icssm_prueth.c b/drivers/net/ethernet/ti/icssm/icssm_prueth.c
[ ... ]
> @@ -564,7 +592,7 @@ static int icssm_prueth_tx_enqueue(struct prueth_emac *emac,
[ ... ]
> /* update first buffer descriptor */
> wr_buf_desc = (pktlen << PRUETH_BD_LENGTH_SHIFT) &
> PRUETH_BD_LENGTH_MASK;
> + if (PRUETH_IS_HSR(prueth))
> + wr_buf_desc |= BIT(PRUETH_BD_HSR_FRAME_SHIFT);
[Severity: High]
Does padding small packets with eth_skb_pad() in icssm_emac_ndo_start_xmit()
interfere with PRP trailer detection here?
When a short PRP frame is padded to 60 bytes in icssm_emac_ndo_start_xmit(),
the zero-padding is appended after the RCT. Later, in
icssm_prueth_tx_enqueue(), the driver attempts to read the RCT like this:
struct prp_txopt_rct *rct =
(struct prp_txopt_rct *)(skb_tail_pointer(skb) - ICSSM_LRE_TAG_SIZE);
Won't this calculation point into the trailing zero-padding instead of the
actual RCT? This would cause small PRP frames to bypass redundancy
duplication.
[ ... ]
> @@ -912,6 +963,25 @@ static int icssm_emac_request_irqs(struct prueth_emac *emac)
> return ret;
> }
>
> +static int icssm_emac_sanitize_feature_flags(struct prueth_emac *emac)
> +{
> + netdev_features_t request_lre;
> +
> + request_lre = emac->ndev->features & NETIF_PRUETH_LRE_OFFLOAD_FEATURES;
> +
> + if (prueth_is_lre(emac->prueth) && !request_lre) {
> + netdev_err(emac->ndev, "Error: Turn ON HSR offload\n");
> + return -EINVAL;
> + }
[Severity: Medium]
Is this check sufficient to handle partial feature toggling?
If a user disables NETIF_F_HW_HSR_TAG_RM via ethtool while leaving
NETIF_F_HW_HSR_FWD active, request_lre will still evaluate to non-zero and
bypass this validation. Since the firmware unconditionally strips the tag,
could this mismatched configuration cause the software stack to misinterpret
the inner IP header as an HSR tag?
[ ... ]
> @@ -1079,6 +1162,9 @@ static int icssm_emac_ndo_stop(struct net_device *ndev)
> else
> rproc_shutdown(emac->pru);
>
> + if (prueth_is_lre(prueth))
> + icssm_prueth_lre_cleanup(prueth);
[Severity: High]
Could this unconditionally cancel the global HSR/PRP duplicate table check
timer while the other LRE port is still running?
If eth0 is brought down, the timer is canceled here, but if eth1 remains
active, the duplication tables could silently fill up and drop legitimate
frames because the check timer is never restarted.
[ ... ]
> @@ -1122,7 +1208,8 @@ static int icssm_prueth_change_mode(struct prueth *prueth,
> }
> }
>
> - if (mode == PRUSS_ETHTYPE_EMAC || mode == PRUSS_ETHTYPE_SWITCH) {
> + if (mode == PRUSS_ETHTYPE_EMAC || mode == PRUSS_ETHTYPE_SWITCH ||
> + mode == PRUSS_ETHTYPE_HSR || mode == PRUSS_ETHTYPE_PRP) {
[Severity: High]
This is a pre-existing issue, but can the direct invocation of ndo_open() and
ndo_stop() inside icssm_prueth_change_mode() cause a deadlock?
If ndev->netdev_ops->ndo_open(ndev) fails and returns an error, the function
aborts without restoring the NAPI state. Later, when the interface is brought
down, the kernel naturally invokes ndo_stop() again. A second napi_disable()
call on an already disabled NAPI might trigger an infinite sleep waiting for
NAPI_STATE_SCHED.
[ ... ]
> @@ -1360,6 +1465,8 @@ static void icssm_emac_ndo_set_rx_mode(struct net_device *ndev)
[ ... ]
> /* It is a shared table. So lock the access */
> - spin_lock_irqsave(&emac->addr_lock, flags);
> + spin_lock_irqsave(mc_filter_tbl_lock, flags);
>
> /* Disable and reset multicast filter, allows allmulti */
> icssm_emac_mc_filter_ctrl(emac, false);
[Severity: High]
Does this function corrupt the shared multicast hardware filter table in LRE
mode?
By calling icssm_emac_mc_filter_reset() the shared table in DRAM1 is cleared.
The code then repopulates the table by iterating only over the current
net_device's multicast addresses. Could this silently drop multicast traffic
for the other active slave port since its addresses are wiped out?
[ ... ]
> +static int icssm_prueth_hsr_port_link(struct net_device *ndev,
> + struct net_device *hsr_ndev)
> +{
[ ... ]
> + spin_lock_irqsave(&emac->addr_lock, flags);
> +
> + if (!prueth->hsr_members) {
[Severity: Low]
Is the per-port emac->addr_lock the correct lock to use when modifying the
device-wide shared state in prueth->hsr_members and prueth->hsr_dev?
While the networking core's global rtnl_lock might serialize this path during
NETDEV_CHANGEUPPER, using a local instance lock to protect global state could
be a maintainability hazard.
[ ... ]
> +free_hsr:
> + spin_lock_irqsave(&emac->addr_lock, flags);
> +
> + prueth->hsr_dev = NULL;
> + prueth->hsr_members &= ~BIT(emac->port_id);
> +
> + spin_unlock_irqrestore(&emac->addr_lock, flags);
> + return ret;
> +}
[Severity: High]
If adding the second HSR/PRP port fails (e.g., during
icssm_prueth_change_mode), does this error path corrupt the bridge state?
Unconditionally clearing the shared prueth->hsr_dev pointer while the first
port is still present in prueth->hsr_members appears to permanently break
subsequent link attempts for the second port, because future links will fail
on the earlier condition:
if (prueth->hsr_dev != hsr_ndev)
--
This is an AI-generated review.
^ permalink raw reply
* Re: [PATCH net-next v2 2/3] net: ti: icssm-prueth: Add priority based RX IRQ handlers
From: Paolo Abeni @ 2026-07-06 9:13 UTC (permalink / raw)
To: parvathi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, danishanwar, rogerq,
pmohan, afd, basharath, arnd, linux-kernel, netdev,
linux-arm-kernel, pratheesh, j-rameshbabu, vigneshr, praneeth,
srk, rogerq, m-malladi, krishna, mohan
In-Reply-To: <20260630124958.894360-3-parvathi@couthit.com>
From: AI Reviewer <ai@example.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev/
---
net: ti: icssm-prueth: Add priority based RX IRQ handlers
This patch adds support for priority based interrupt handling for the STP/
RSTP Switch, HSR and PRP protocols along with extra logic to address first
come first served to avoid port dominance. The driver will read the RX HW
timestamp from the frame to achieve wire-arrival ordering.
> diff --git a/drivers/net/ethernet/ti/icssm/icssm_prueth.c b/drivers/net/ethernet/ti/icssm/icssm_prueth.c
> --- a/drivers/net/ethernet/ti/icssm/icssm_prueth.c
> +++ b/drivers/net/ethernet/ti/icssm/icssm_prueth.c
[ ... ]
> @@ -1188,26 +1188,26 @@ static int icssm_emac_ndo_stop(struct net_device *ndev)
> /* disable the mac port */
> icssm_prueth_port_enable(emac, false);
>
> + netif_stop_queue(ndev);
> +
> /* stop PHY */
> phy_stop(emac->phydev);
>
> - napi_disable(&emac->napi);
> hrtimer_cancel(&emac->tx_hrtimer);
>
[ ... ]
> /* stop the PRU */
> if (!PRUETH_IS_EMAC(prueth))
> icssm_prueth_sw_shutdown_prus(emac, ndev);
>
> if (prueth_is_lre(prueth))
> icssm_prueth_lre_cleanup(prueth);
[Severity: High]
This is a pre-existing issue, but is the LRE duplicate detection timer
prematurely canceled when a single port goes down?
In icssm_emac_ndo_stop, icssm_prueth_lre_cleanup is called unconditionally
when any interface is brought down.
If one port in the HSR/PRP bridge goes down while the other remains active,
this cancels the shared tbl_check_timer, potentially causing duplicate
frames to stop being detected and dropped by the hardware.
> diff --git a/drivers/net/ethernet/ti/icssm/icssm_prueth_common.c b/drivers/net/ethernet/ti/icssm/icssm_prueth_common.c
> new file mode 100644
> --- /dev/null
> +++ b/drivers/net/ethernet/ti/icssm/icssm_prueth_common.c
> @@ -0,0 +1,286 @@
[ ... ]
> +static int icssm_prueth_common_emac_rx_packets(struct prueth_emac *emac,
> + int quota, u8 qid1, u8 qid2)
> +{
[ ... ]
> + if ((*pkt_info_p).length < EMAC_MIN_PKTLEN) {
> + /* Undersized frame: firmware should have filtered
> + * these before they reach the host queue. Advance
> + * the read pointer to skip it.
> + */
> + update_rd_ptr = *bd_wr_ptr_p;
> + ndevstats_p->rx_length_errors++;
[Severity: High]
This is a pre-existing issue, but does this error path flush the entire
pending RX queue?
When the driver detects an undersized or oversized packet, it attempts to
skip it by updating the read pointer. However, setting update_rd_ptr to
*bd_wr_ptr_p appears to assign the hardware's write pointer (the very end of
the queue), rather than advancing by one descriptor.
Could this discard all pending descriptors instead of just the malformed one?
[Severity: High]
Does this introduce a race condition on the network statistics?
This patch introduces split NAPI polling with separate priority threads
(napi_hpq and napi_lpq) that process the high and low priority queues across
both physical ports. These NAPI instances can be scheduled on different CPUs
concurrently.
Both instances invoke icssm_prueth_common_emac_rx_packets, which updates raw
unsigned long statistics like ndevstats_p->rx_length_errors (and 64-bit
stats like emac->stats.rx_bytes in icssm_emac_rx_packet) using += without
atomic instructions or locks.
On 32-bit platforms, could this cause lost updates for concurrent writers, or
torn reads when read by ndo_get_stats64?
> + } else if ((*pkt_info_p).length > EMAC_MAX_FRM_SUPPORT) {
> + /* Oversized frame: firmware should have filtered
> + * these before they reach the host queue. Advance
> + * the read pointer to skip it.
> + */
> + update_rd_ptr = *bd_wr_ptr_p;
> + ndevstats_p->rx_length_errors++;
> + } else {
> + update_rd_ptr = *bd_rd_ptr_p;
> + ret = icssm_emac_rx_packet(emac_p, &update_rd_ptr,
> + pkt_info_p, rxqueue_p);
> + if (ret)
> + return used;
[Severity: High]
This is a pre-existing issue, but does a memory allocation failure in this RX
path cause a permanent RX queue stall?
If icssm_emac_rx_packet fails to allocate an SKB, it returns -ENOMEM. The
driver immediately aborts the NAPI polling loop without updating the hardware
read pointer or consuming the packet.
Because it returns used (which is less than budget), it triggers
napi_complete_done() which re-enables the RX interrupt. Since the packet is
still pending in the hardware queue, the interrupt fires again immediately in
an infinite loop.
> diff --git a/drivers/net/ethernet/ti/icssm/icssm_prueth_lre.c b/drivers/net/ethernet/ti/icssm/icssm_prueth_lre.c
> --- a/drivers/net/ethernet/ti/icssm/icssm_prueth_lre.c
> +++ b/drivers/net/ethernet/ti/icssm/icssm_prueth_lre.c
> @@ -152,6 +152,14 @@ static void icssm_prueth_lre_protocol_init(struct prueth *prueth)
> dram1 + ICSS_LRE_SUP_ADDR_LOW);
> }
>
> +static void icssm_prueth_lre_config_packet_timestamping(struct prueth *prueth)
> +{
> + void __iomem *sram = prueth->mem[PRUETH_MEM_SHARED_RAM].va;
> +
> + writeb(1, sram + ICSS_LRE_PRIORITY_INTRS_STATUS_OFFSET);
> + writeb(1, sram + ICSS_LRE_TIMESTAMP_PKTS_STATUS_OFFSET);
> +}
> +
[ ... ]
> @@ -202,6 +210,11 @@ void icssm_prueth_lre_config(struct prueth *prueth)
> icssm_prueth_lre_init(prueth);
> icssm_prueth_lre_dbg_init(prueth);
> icssm_prueth_lre_protocol_init(prueth);
> + /* Enable per-packet timestamping so the driver can order
> + * received frames by arrival time across the two slave ports.
> + */
> + icssm_prueth_lre_config_packet_timestamping(prueth);
> +
> }
[Severity: High]
Does this fail to enable hardware timestamping in Switch mode?
The patch introduces timestamp-based packet ordering for Switch, HSR, and PRP
modes, requiring configuration via ICSS_LRE_PRIORITY_INTRS_STATUS_OFFSET and
ICSS_LRE_TIMESTAMP_PKTS_STATUS_OFFSET.
However, icssm_prueth_lre_config_packet_timestamping is only called from
icssm_prueth_lre_config, which is gated by prueth_is_lre() (only true for HSR
and PRP).
In Switch mode, these registers appear to never be written, potentially
leaving timestamps disabled in firmware and breaking the wire-arrival
ordering logic.
[Severity: High]
This is a pre-existing issue, but are the dynamically allocated FDB learning
work items tracked for cleanup?
When learning a new source MAC address in icssm_prueth_sw_learn_fdb()
(drivers/net/ethernet/ti/icssm/icssm_prueth_switch.c), the driver dynamically
allocates a struct icssm_prueth_sw_fdb_work and queues it.
If these are not tracked in a list, unloading the module could leave pending
work items that execute unmapped memory, potentially causing a kernel panic.
[Severity: High]
This is a pre-existing issue, but can the unbounded GFP_ATOMIC allocations
for FDB learning lead to memory exhaustion?
Every received frame with an unlearned source MAC address triggers
icssm_prueth_sw_learn_fdb(), which uses kzalloc_obj(..., GFP_ATOMIC) without
rate limiting.
A continuous flood of frames with randomized source MAC addresses could
trigger thousands of allocations per second, potentially exhausting the
kernel's atomic memory pools.
--
This is an AI-generated review.
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] net: ti: icssm-prueth: Support duplicate HW offload feature for HSR and PRP
From: Paolo Abeni @ 2026-07-06 9:13 UTC (permalink / raw)
To: parvathi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, danishanwar, rogerq,
pmohan, afd, basharath, arnd, linux-kernel, netdev,
linux-arm-kernel, pratheesh, j-rameshbabu, vigneshr, praneeth,
srk, rogerq, m-malladi, krishna, mohan
In-Reply-To: <20260630124958.894360-4-parvathi@couthit.com>
From: AI Reviewer <ai@example.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev/
---
net: ti: icssm-prueth: Support duplicate HW offload feature for HSR and PRP
This commit introduces hardware duplicate offload for HSR and PRP modes. It
implements a common shared queue between the two ports, writing frames once
to OCMC RAM and relying on the firmware to replicate the transmission.
> diff --git a/drivers/net/ethernet/ti/icssm/icssm_prueth.c b/drivers/net/ethernet/ti/icssm/icssm_prueth.c
> index 2ab78a98f8568..cbe666a212c3b 100644
> --- a/drivers/net/ethernet/ti/icssm/icssm_prueth.c
> +++ b/drivers/net/ethernet/ti/icssm/icssm_prueth.c
> @@ -97,6 +125,17 @@ static void icssm_prueth_write_reg(struct prueth *prueth,
> static enum pruss_mem pruss_mem_ids[] = { PRUSS_MEM_DRAM0, PRUSS_MEM_DRAM1,
> PRUSS_MEM_SHRD_RAM2 };
>
> +struct prp_txopt_rct {
> + __be16 sequence_nr;
> + __be16 lan_id_and_lsdu_size;
> + __be16 prp_suffix;
> +};
[Severity: High]
Does this structure definition need the __packed attribute?
This struct consists of three 16-bit fields but lacks the __packed attribute,
so it inherits a 2-byte alignment requirement. Later in
icssm_prueth_tx_enqueue, a pointer to this structure is derived directly
from skb_tail_pointer.
If an ethernet frame payload has an odd byte length, wouldn't casting and
dereferencing this pointer cause an unaligned 16-bit memory access, resulting
in hardware traps or panics on architectures that do not support it?
[ ... ]
> @@ -549,15 +588,24 @@ static int icssm_prueth_tx_enqueue(struct prueth_emac *emac,
[ ... ]
> + other_emac = emac->prueth->emac[(emac->port_id == PRUETH_PORT_MII0) ?
> + PRUETH_PORT_MII1 - 1 : PRUETH_PORT_MII0 - 1];
> +
> + if (prueth_is_lre(prueth) && (emac->link || other_emac->link))
> + link_up = true;
[Severity: High]
Could this logical OR cause the shared transmission queue to stall completely
if only one of the slave links goes down?
If one port loses its link, its emac->link is 0, but the other active port
will still evaluate link_up as true. The active port would continue sending
duplicate frames to the shared queue.
[ ... ]
> @@ -605,6 +659,29 @@ static int icssm_prueth_tx_enqueue(struct prueth_emac *emac,
[ ... ]
> + if (free_blocks_other_port < free_blocks)
> + free_blocks = free_blocks_other_port;
> + }
[Severity: High]
Following up on the link_up logic above, since the available queue space is
bounded by the slowest reader here, wouldn't the inactive port's read pointer
remain frozen?
This appears to exhaust the free_blocks pool, causing the active port to
eventually spin and return -ENOBUFS permanently, defeating the redundancy.
[ ... ]
> + } else {
> + /* Read PRP RCT to extract sequence number and LAN ID */
> + struct prp_txopt_rct *rct =
> + (struct prp_txopt_rct *)(skb_tail_pointer(skb) -
> + ICSSM_LRE_TAG_SIZE);
> +
> + if (rct->prp_suffix == htons(ETH_P_PRP)) {
[Severity: High]
Is it safe to directly dereference rct->prp_suffix here?
As mentioned above regarding the struct definition, this might lead to an
unaligned memory access on certain architectures. Perhaps using the
get_unaligned_be16 helper would be safer here, or adding the __packed
attribute to the structure definition.
[ ... ]
> @@ -1341,18 +1516,30 @@ static enum netdev_tx icssm_emac_ndo_start_xmit(struct sk_buff *skb,
[ ... ]
> + raw_spin_lock(lock_queue);
> + ret = icssm_prueth_tx_enqueue(emac, skb, qid);
> + raw_spin_unlock(lock_queue);
[Severity: High]
Does this need to use the irqsave variant to protect against cross-device
deadlocks with netpoll?
The lre_host_queue_lock is shared between the two ports. If a hardirq
preempts a CPU while it holds this lock during a transmission, and the
interrupt handler invokes a printk that triggers netconsole over the second
interface, netpoll might bypass the netif_tx_lock.
When the second interface calls into ndo_start_xmit, it would attempt to
acquire the exact same lre_host_queue_lock, causing it to spin forever on
the same CPU.
--
This is an AI-generated review.
^ permalink raw reply
* [PATCH v2 0/5] ARM: rockchip: rv1126: Add support for Alientek ATK-DLRV1126
From: Yanan He @ 2026-07-06 9:14 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue, Frank,
Andrew Lunn, Heiner Kallweit, Russell King
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32, Yanan He
The ATK-DLRV1126 board consists of a CLRV1126F core module and a
DLRV1126 carrier board. The core module contains the Rockchip RV1126
SoC, eMMC and RK809 PMIC. The carrier board provides Gigabit Ethernet,
SD card, AP6212 WiFi and Bluetooth, PCF8563 RTC, ADC keys, GPIO LEDs and
audio connectors.
This series adds the Alientek vendor prefix and board compatible, updates
the Motorcomm PHY driver to consume an optional external PHY reference
clock, adds missing RV1126 SoC description pieces, and finally adds the
CLRV1126F core module and DLRV1126 carrier board device trees.
The board was tested with Ethernet/NFS boot, eMMC, SD card, SDIO WiFi
enumeration, Bluetooth LE scanning, RTC, ADC keys, GPIO LEDs and RK809
audio card registration.
Changes in v2:
- Model CLK_GMAC_ETHERNET_OUT as an external PHY clock consumed by the
YT8531 PHY instead of keeping it alive from dwmac-rk.
- Add optional clock enable support to the YT8531 path in the Motorcomm
PHY driver.
- Use phy-mode = "rgmii-id" for the Alientek DLRV1126 GMAC.
- Keep the PHY reference clock in the ethernet-phy node, following the
rk3588-tiger.dtsi pattern.
Signed-off-by: Yanan He <grumpycat921013@gmail.com>
---
Yanan He (5):
dt-bindings: vendor-prefixes: add alientek
dt-bindings: arm: rockchip: Add Alientek DLRV1126
net: phy: motorcomm: Enable optional clock for YT8531
ARM: dts: rockchip: Add RV1126 I2C5
ARM: dts: rockchip: Add Alientek DLRV1126
.../devicetree/bindings/arm/rockchip.yaml | 7 +
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
arch/arm/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rv1126-alientek-clrv1126f.dtsi | 277 +++++++++++++++++++++
.../boot/dts/rockchip/rv1126-alientek-dlrv1126.dts | 256 +++++++++++++++++++
arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi | 10 +
arch/arm/boot/dts/rockchip/rv1126.dtsi | 15 ++
drivers/net/phy/motorcomm.c | 7 +
8 files changed, 575 insertions(+)
---
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
change-id: 20260618-rv1126-alientek-dlrv1126-d94abdcf8580
Best regards,
--
Yanan He <grumpycat921013@gmail.com>
^ permalink raw reply
* [PATCH v2 1/5] dt-bindings: vendor-prefixes: add alientek
From: Yanan He @ 2026-07-06 9:14 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue, Frank,
Andrew Lunn, Heiner Kallweit, Russell King
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32, Yanan He
In-Reply-To: <20260706-rv1126-alientek-dlrv1126-v2-0-ff3176ca362b@gmail.com>
Add a vendor prefix for Alientek, a board and module vendor used by the
ATK-DLRV1126 board.
Link: https://en.alientek.com
Signed-off-by: Yanan He <grumpycat921013@gmail.com>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 396044f368e7..914d5a8fd628 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -88,6 +88,8 @@ patternProperties:
description: ALFA Network Inc.
"^algoltek,.*":
description: AlgolTek, Inc.
+ "^alientek,.*":
+ description: Guangzhou Xingyi Intelligent Technology Co., Ltd.
"^allegro,.*":
description: Allegro DVT
"^allegromicro,.*":
--
2.54.0
^ permalink raw reply related
* [PATCH v2 2/5] dt-bindings: arm: rockchip: Add Alientek DLRV1126
From: Yanan He @ 2026-07-06 9:14 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue, Frank,
Andrew Lunn, Heiner Kallweit, Russell King
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32, Yanan He
In-Reply-To: <20260706-rv1126-alientek-dlrv1126-v2-0-ff3176ca362b@gmail.com>
The board consists of a DLRV1126 carrier board and a CLRV1126F core
module based on the Rockchip RV1126 SoC.
Signed-off-by: Yanan He <grumpycat921013@gmail.com>
---
Documentation/devicetree/bindings/arm/rockchip.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 1a9dde18626d..9058f2a461d5 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -162,6 +162,13 @@ properties:
- const: coolpi,pi-4b
- const: rockchip,rk3588s
+ - description: Alientek CLRV1126F SoM based boards
+ items:
+ - enum:
+ - alientek,dlrv1126
+ - const: alientek,clrv1126f
+ - const: rockchip,rv1126
+
- description: Edgeble Neural Compute Module 2(Neu2) SoM based boards
items:
- const: edgeble,neural-compute-module-2-io # Edgeble Neural Compute Module 2 IO Board
--
2.54.0
^ permalink raw reply related
* [PATCH v2 3/5] net: phy: motorcomm: Enable optional clock for YT8531
From: Yanan He @ 2026-07-06 9:14 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue, Frank,
Andrew Lunn, Heiner Kallweit, Russell King
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32, Yanan He
In-Reply-To: <20260706-rv1126-alientek-dlrv1126-v2-0-ff3176ca362b@gmail.com>
Some boards feed the YT8531 PHY from an SoC-provided external
reference clock described by the common ethernet-phy "clocks" property.
Enable the optional PHY clock during probe so boards can model this
clock as a PHY input instead of keeping the clock alive from the MAC
driver.
This is needed on the Alientek DLRV1126, where the PHY reference clock
is provided by CLK_GMAC_ETHERNET_OUT.
Signed-off-by: Yanan He <grumpycat921013@gmail.com>
---
drivers/net/phy/motorcomm.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/phy/motorcomm.c b/drivers/net/phy/motorcomm.c
index 5071605a1a11..3396a38cfc0f 100644
--- a/drivers/net/phy/motorcomm.c
+++ b/drivers/net/phy/motorcomm.c
@@ -6,6 +6,7 @@
* Author: Frank <Frank.Sae@motor-comm.com>
*/
+#include <linux/clk.h>
#include <linux/etherdevice.h>
#include <linux/kernel.h>
#include <linux/module.h>
@@ -1180,9 +1181,15 @@ static int yt8521_probe(struct phy_device *phydev)
static int yt8531_probe(struct phy_device *phydev)
{
struct device *dev = &phydev->mdio.dev;
+ struct clk *clk;
u16 mask, val;
u32 freq;
+ clk = devm_clk_get_optional_enabled(dev, NULL);
+ if (IS_ERR(clk))
+ return dev_err_probe(dev, PTR_ERR(clk),
+ "failed to get and enable PHY clock\n");
+
if (device_property_read_u32(dev, "motorcomm,clk-out-frequency-hz", &freq))
freq = YTPHY_DTS_OUTPUT_CLK_DIS;
--
2.54.0
^ permalink raw reply related
* [PATCH v2 4/5] ARM: dts: rockchip: Add RV1126 I2C5
From: Yanan He @ 2026-07-06 9:14 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue, Frank,
Andrew Lunn, Heiner Kallweit, Russell King
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32, Yanan He
In-Reply-To: <20260706-rv1126-alientek-dlrv1126-v2-0-ff3176ca362b@gmail.com>
The controller is present in the SoC and can be used by boards for
external peripherals, such as an RTC on the Alientek DLRV1126 carrier
board.
Signed-off-by: Yanan He <grumpycat921013@gmail.com>
---
arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi | 10 ++++++++++
arch/arm/boot/dts/rockchip/rv1126.dtsi | 15 +++++++++++++++
2 files changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi b/arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi
index 35ef6732281f..1d883b80aed4 100644
--- a/arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi
+++ b/arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi
@@ -123,6 +123,16 @@ i2c3m2_xfer: i2c3m2-xfer {
<1 RK_PD7 3 &pcfg_pull_none>;
};
};
+ i2c5 {
+ /omit-if-no-ref/
+ i2c5m0_xfer: i2c5m0-xfer {
+ rockchip,pins =
+ /* i2c5_scl_m0 */
+ <2 RK_PA5 7 &pcfg_pull_none_drv_level_0_smt>,
+ /* i2c5_sda_m0 */
+ <2 RK_PB3 7 &pcfg_pull_none_drv_level_0_smt>;
+ };
+ };
i2s0 {
i2s0m0_lrck_tx: i2s0m0-lrck-tx {
rockchip,pins =
diff --git a/arch/arm/boot/dts/rockchip/rv1126.dtsi b/arch/arm/boot/dts/rockchip/rv1126.dtsi
index d6e8b63daa42..d0cdc5f74212 100644
--- a/arch/arm/boot/dts/rockchip/rv1126.dtsi
+++ b/arch/arm/boot/dts/rockchip/rv1126.dtsi
@@ -23,6 +23,7 @@ aliases {
i2c0 = &i2c0;
i2c2 = &i2c2;
i2c3 = &i2c3;
+ i2c5 = &i2c5;
serial0 = &uart0;
serial1 = &uart1;
serial2 = &uart2;
@@ -400,6 +401,20 @@ i2c3: i2c@ff520000 {
status = "disabled";
};
+ i2c5: i2c@ff540000 {
+ compatible = "rockchip,rv1126-i2c", "rockchip,rk3399-i2c";
+ reg = <0xff540000 0x1000>;
+ interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru CLK_I2C5>, <&cru PCLK_I2C5>;
+ clock-names = "i2c", "pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c5m0_xfer>;
+ rockchip,grf = <&pmugrf>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
pwm8: pwm@ff550000 {
compatible = "rockchip,rv1126-pwm", "rockchip,rk3328-pwm";
reg = <0xff550000 0x10>;
--
2.54.0
^ permalink raw reply related
* [PATCH v2 5/5] ARM: dts: rockchip: Add Alientek DLRV1126
From: Yanan He @ 2026-07-06 9:14 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue, Frank,
Andrew Lunn, Heiner Kallweit, Russell King
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32, Yanan He
In-Reply-To: <20260706-rv1126-alientek-dlrv1126-v2-0-ff3176ca362b@gmail.com>
The board consists of a CLRV1126F core module and a DLRV1126 carrier
board. The core module contains the RV1126 SoC, eMMC and RK809 PMIC,
while the carrier board provides Ethernet, SD card, AP6212 WiFi and
Bluetooth, PCF8563 RTC, ADC keys, GPIO LEDs and audio connectors.
The board has been tested with Ethernet/NFS boot, eMMC, SD card, SDIO
WiFi enumeration, Bluetooth LE scanning, RTC, ADC keys, GPIO LEDs and
RK809 audio card registration.
Signed-off-by: Yanan He <grumpycat921013@gmail.com>
---
arch/arm/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rv1126-alientek-clrv1126f.dtsi | 277 +++++++++++++++++++++
.../boot/dts/rockchip/rv1126-alientek-dlrv1126.dts | 256 +++++++++++++++++++
3 files changed, 534 insertions(+)
diff --git a/arch/arm/boot/dts/rockchip/Makefile b/arch/arm/boot/dts/rockchip/Makefile
index d0154fd7ff24..e9f9e0ac3bfd 100644
--- a/arch/arm/boot/dts/rockchip/Makefile
+++ b/arch/arm/boot/dts/rockchip/Makefile
@@ -5,6 +5,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rv1108-evb.dtb \
rv1109-relfor-saib.dtb \
rv1109-sonoff-ihost.dtb \
+ rv1126-alientek-dlrv1126.dtb \
rv1126-edgeble-neu2-io.dtb \
rv1126-sonoff-ihost.dtb \
rk3036-evb.dtb \
diff --git a/arch/arm/boot/dts/rockchip/rv1126-alientek-clrv1126f.dtsi b/arch/arm/boot/dts/rockchip/rv1126-alientek-clrv1126f.dtsi
new file mode 100644
index 000000000000..9bee424b1797
--- /dev/null
+++ b/arch/arm/boot/dts/rockchip/rv1126-alientek-clrv1126f.dtsi
@@ -0,0 +1,277 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2026 Yanan He <grumpycat921013@gmail.com>
+ */
+
+#include "rv1126.dtsi"
+
+/ {
+ compatible = "alientek,clrv1126f", "rockchip,rv1126";
+
+ aliases {
+ mmc0 = &emmc;
+ };
+};
+
+&cpu0 {
+ cpu-supply = <&vdd_arm>;
+};
+
+&cpu1 {
+ cpu-supply = <&vdd_arm>;
+};
+
+&cpu2 {
+ cpu-supply = <&vdd_arm>;
+};
+
+&cpu3 {
+ cpu-supply = <&vdd_arm>;
+};
+
+&emmc {
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ mmc-hs200-1_8v;
+ non-removable;
+ pinctrl-names = "default";
+ pinctrl-0 = <&emmc_bus8 &emmc_cmd &emmc_clk &emmc_rstnout>;
+ rockchip,default-sample-phase = <90>;
+ vmmc-supply = <&vcc_3v3>;
+ vqmmc-supply = <&vcc_1v8>;
+ status = "okay";
+};
+
+&i2c0 {
+ clock-frequency = <400000>;
+ status = "okay";
+
+ rk809: pmic@20 {
+ compatible = "rockchip,rk809";
+ reg = <0x20>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PB1 IRQ_TYPE_LEVEL_LOW>;
+ #clock-cells = <1>;
+ #sound-dai-cells = <0>;
+ clock-output-names = "rk808-clkout1", "rk808-clkout2";
+ clock-names = "mclk";
+ clocks = <&cru MCLK_I2S0_TX_OUT2IO>;
+ assigned-clocks = <&cru MCLK_I2S0_TX_OUT2IO>;
+ assigned-clock-parents = <&cru MCLK_I2S0_TX>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_int_l>;
+ rockchip,system-power-controller;
+ wakeup-source;
+
+ vcc1-supply = <&vcc5v0_sys>;
+ vcc2-supply = <&vcc5v0_sys>;
+ vcc3-supply = <&vcc5v0_sys>;
+ vcc4-supply = <&vcc5v0_sys>;
+ vcc5-supply = <&vcc_buck5>;
+ vcc6-supply = <&vcc_buck5>;
+ vcc7-supply = <&vcc5v0_sys>;
+ vcc8-supply = <&vcc3v3_sys>;
+ vcc9-supply = <&vcc5v0_sys>;
+
+ regulators {
+ vdd_npu_vepu: DCDC_REG1 {
+ regulator-name = "vdd_npu_vepu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-initial-mode = <0x2>;
+ regulator-min-microvolt = <650000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <6001>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_arm: DCDC_REG2 {
+ regulator-name = "vdd_arm";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-initial-mode = <0x2>;
+ regulator-min-microvolt = <725000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_ddr: DCDC_REG3 {
+ regulator-name = "vcc_ddr";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-initial-mode = <0x2>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vcc3v3_sys: DCDC_REG4 {
+ regulator-name = "vcc3v3_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-initial-mode = <0x2>;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+
+ vcc_buck5: DCDC_REG5 {
+ regulator-name = "vcc_buck5";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <2200000>;
+ regulator-max-microvolt = <2200000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <2200000>;
+ };
+ };
+
+ vcc_0v8: LDO_REG1 {
+ regulator-name = "vcc_0v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <800000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc1v8_pmu: LDO_REG2 {
+ regulator-name = "vcc1v8_pmu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vdd0v8_pmu: LDO_REG3 {
+ regulator-name = "vcc0v8_pmu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <800000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <800000>;
+ };
+ };
+
+ vcc_1v8: LDO_REG4 {
+ regulator-name = "vcc_1v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcc_dovdd: LDO_REG5 {
+ regulator-name = "vcc_dovdd";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_dvdd: LDO_REG6 {
+ regulator-name = "vcc_dvdd";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_avdd: LDO_REG7 {
+ regulator-name = "vcc_avdd";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vccio_sd: LDO_REG8 {
+ regulator-name = "vccio_sd";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc3v3_sd: LDO_REG9 {
+ regulator-name = "vcc3v3_sd";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_5v0: SWITCH_REG1 {
+ regulator-name = "vcc_5v0";
+ };
+
+ vcc_3v3: SWITCH_REG2 {
+ regulator-name = "vcc_3v3";
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ };
+ };
+};
+
+&pinctrl {
+ pmic {
+ pmic_int_l: pmic-int-l {
+ rockchip,pins = <0 RK_PB1 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+};
+
+&pmu_io_domains {
+ pmuio0-supply = <&vcc3v3_sys>;
+ pmuio1-supply = <&vcc3v3_sys>;
+ vccio1-supply = <&vcc_1v8>;
+ vccio2-supply = <&vccio_sd>;
+ vccio3-supply = <&vcc_1v8>;
+ vccio4-supply = <&vcc_3v3>;
+ vccio5-supply = <&vcc_3v3>;
+ vccio6-supply = <&vcc_3v3>;
+ vccio7-supply = <&vcc_1v8>;
+ status = "okay";
+};
+
+&saradc {
+ vref-supply = <&vcc_1v8>;
+ status = "okay";
+};
+
+&wdt {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/rockchip/rv1126-alientek-dlrv1126.dts b/arch/arm/boot/dts/rockchip/rv1126-alientek-dlrv1126.dts
new file mode 100644
index 000000000000..33c6c74d08b9
--- /dev/null
+++ b/arch/arm/boot/dts/rockchip/rv1126-alientek-dlrv1126.dts
@@ -0,0 +1,256 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2026 Yanan He <grumpycat921013@gmail.com>
+ */
+
+/dts-v1/;
+#include <dt-bindings/input/input.h>
+#include "rv1126-alientek-clrv1126f.dtsi"
+
+/ {
+ model = "Alientek ATK-DLRV1126";
+ compatible = "alientek,dlrv1126", "alientek,clrv1126f", "rockchip,rv1126";
+
+ aliases {
+ ethernet0 = &gmac;
+ mmc1 = &sdio;
+ mmc2 = &sdmmc;
+ };
+
+ chosen {
+ stdout-path = "serial2:1500000n8";
+ };
+
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = <&saradc 0>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <1800000>;
+ poll-interval = <100>;
+
+ button-esc {
+ label = "esc";
+ linux,code = <KEY_ESC>;
+ press-threshold-microvolt = <0>;
+ };
+
+ button-right {
+ label = "right";
+ linux,code = <KEY_RIGHT>;
+ press-threshold-microvolt = <400781>;
+ };
+
+ button-left {
+ label = "left";
+ linux,code = <KEY_LEFT>;
+ press-threshold-microvolt = <801562>;
+ };
+
+ button-menu {
+ label = "menu";
+ linux,code = <KEY_MENU>;
+ press-threshold-microvolt = <1198828>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led-0 {
+ label = "sys-led";
+ gpios = <&gpio3 RK_PD4 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ default-state = "on";
+ };
+
+ led-1 {
+ label = "user-led";
+ gpios = <&gpio3 RK_PD6 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "none";
+ default-state = "on";
+ };
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,name = "Analog RK809";
+ simple-audio-card,mclk-fs = <256>;
+ simple-audio-card,widgets =
+ "Speaker", "Speaker",
+ "Headphone", "Headphones",
+ "Microphone", "Mic Jack";
+ simple-audio-card,routing =
+ "Speaker", "SPKO",
+ "Headphones", "HPOL",
+ "Headphones", "HPOR",
+ "MICL", "Mic Jack";
+
+ simple-audio-card,cpu {
+ sound-dai = <&i2s0>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&rk809>;
+ };
+ };
+
+ vcc5v0_sys: regulator-vcc5v0-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
+ sdio_pwrseq: pwrseq-sdio {
+ compatible = "mmc-pwrseq-simple";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_enable_h>;
+ reset-gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_LOW>;
+ post-power-on-delay-ms = <200>;
+ power-off-delay-us = <20000>;
+ };
+};
+
+&i2c5 {
+ status = "okay";
+ clock-frequency = <400000>;
+
+ pcf8563: rtc@51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ #clock-cells = <0>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <RK_PD0 IRQ_TYPE_LEVEL_LOW>;
+ clock-output-names = "xin32k";
+ };
+};
+
+&gmac {
+ phy-mode = "rgmii-id";
+ clock_in_out = "input";
+ assigned-clocks = <&cru CLK_GMAC_SRC>, <&cru CLK_GMAC_TX_RX>,
+ <&cru CLK_GMAC_ETHERNET_OUT>;
+ assigned-clock-parents = <&cru CLK_GMAC_SRC_M1>,
+ <&cru RGMII_MODE_CLK>;
+ assigned-clock-rates = <125000000>, <0>, <25000000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmiim1_miim &rgmiim1_bus2 &rgmiim1_bus4
+ &clk_out_ethernetm1_pins>;
+ phy-handle = <&phy>;
+ status = "okay";
+};
+
+&mdio {
+ phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0x1>;
+ clocks = <&cru CLK_GMAC_ETHERNET_OUT>;
+ pinctrl-names = "default";
+ pinctrl-0 = <ð_phy_rst>;
+ reset-gpios = <&gpio3 RK_PA0 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <20000>;
+ reset-deassert-us = <100000>;
+ };
+};
+
+&pinctrl {
+ ethernet {
+ eth_phy_rst: eth-phy-rst {
+ rockchip,pins = <3 RK_PA0 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+ };
+
+ bt {
+ bt_enable: bt-enable {
+ rockchip,pins = <0 RK_PA7 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ bt_wake_dev: bt-wake-dev {
+ rockchip,pins = <1 RK_PD1 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ bt_wake_host: bt-wake-host {
+ rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ wifi {
+ wifi_enable_h: wifi-enable-h {
+ rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
+
+&sdio {
+ bus-width = <4>;
+ cap-sdio-irq;
+ keep-power-in-suspend;
+ max-frequency = <25000000>;
+ mmc-pwrseq = <&sdio_pwrseq>;
+ non-removable;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc1_clk &sdmmc1_cmd &sdmmc1_bus4>;
+ rockchip,default-sample-phase = <90>;
+ vmmc-supply = <&vcc3v3_sd>;
+ vqmmc-supply = <&vcc_1v8>;
+ status = "okay";
+};
+
+&sdmmc {
+ bus-width = <4>;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
+ card-detect-delay = <200>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc0_clk &sdmmc0_cmd &sdmmc0_bus4 &sdmmc0_det>;
+ rockchip,default-sample-phase = <90>;
+ sd-uhs-sdr12;
+ sd-uhs-sdr25;
+ sd-uhs-sdr104;
+ vmmc-supply = <&vcc3v3_sd>;
+ vqmmc-supply = <&vccio_sd>;
+ status = "okay";
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_xfer &uart0_ctsn &uart0_rtsn>;
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth {
+ compatible = "brcm,bcm43430a1-bt";
+ shutdown-gpios = <&gpio0 RK_PA7 GPIO_ACTIVE_HIGH>;
+ device-wakeup-gpios = <&gpio1 RK_PD1 GPIO_ACTIVE_HIGH>;
+ clocks = <&rk809 1>;
+ clock-names = "lpo";
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PA5 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "host-wakeup";
+ max-speed = <115200>;
+ vbat-supply = <&vcc_3v3>;
+ vddio-supply = <&vcc_1v8>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&bt_enable>, <&bt_wake_dev>, <&bt_wake_host>;
+ };
+};
+
+&uart2 {
+ status = "okay";
+};
+
+&i2s0 {
+ rockchip,trcm-sync-tx-only;
+ rockchip,i2s-rx-route = <3 1 2 0>;
+ rockchip,i2s-tx-route = <0 1 2 3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2s0m0_sclk_tx>,
+ <&i2s0m0_mclk>,
+ <&i2s0m0_lrck_tx>,
+ <&i2s0m0_sdo0>,
+ <&i2s0m0_sdo1_sdi3>;
+ status = "okay";
+};
--
2.54.0
^ permalink raw reply related
* RE: [PATCH net] tipc: fix NULL deref in tipc_named_node_up() on empty publication list
From: Tung Quang Nguyen @ 2026-07-06 9:21 UTC (permalink / raw)
To: Weiming Shi
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Xiang Mei, linux-kernel@vger.kernel.org, Jon Maloy,
netdev@vger.kernel.org, tipc-discussion@lists.sourceforge.net
In-Reply-To: <20260705115958.1066751-1-bestswngs@gmail.com>
>Subject: [PATCH net] tipc: fix NULL deref in tipc_named_node_up() on empty
>publication list
>
>named_distribute() builds the bulk messages for @pls into @list and then
>dereferences the tail skb:
>
> hdr = buf_msg(skb_peek_tail(list));
> msg_set_last_bulk(hdr);
>
>If @pls is empty no skb is enqueued, skb_peek_tail() returns NULL, and
>msg_set_last_bulk() writes through buf_msg(NULL).
>
>tipc_named_node_up() passes &nt->cluster_scope. With a node-id
>configuration the TIPC_NODE_STATE name is published by tipc_net_finalize()
>from a work item, which sets the node address before publishing the name.
>The node accepts links once the address is set, so a link that comes up before
>the publish runs named_distribute() on an empty cluster_scope:
>
> KASAN: null-ptr-deref in range [0x00000000000000d8-0x00000000000000df]
> RIP: 0010:tipc_named_node_up (net/tipc/name_distr.c:196)
> tipc_named_node_up (net/tipc/name_distr.c:196 net/tipc/name_distr.c:221)
> tipc_node_write_unlock (net/tipc/node.c:428)
> tipc_rcv (net/tipc/node.c:2185)
> tipc_udp_recv (net/tipc/udp_media.c:392) Kernel panic - not syncing: Fatal
>exception in interrupt
>
>TIPC genl ops use GENL_UNS_ADMIN_PERM, so an unprivileged user can reach
>this from a user+net namespace.
>
>Return early from named_distribute() when the list is empty, and skip
>tipc_node_xmit() for an empty chain. The empty chain would otherwise hit
>tipc_lxc_xmit() -> buf_msg(skb_peek(list)), the same zero-skb case fixed for
>tipc_link_xmit() in commit b77413446408 ("tipc: fix NULL deref in
>tipc_link_xmit()").
It needs to return earlier in tipc_named_node_up() like this:
diff --git a/net/tipc/name_distr.c b/net/tipc/name_distr.c
index ba4f4906e13b..60ccaa862162 100644
--- a/net/tipc/name_distr.c
+++ b/net/tipc/name_distr.c
@@ -218,6 +218,10 @@ void tipc_named_node_up(struct net *net, u32 dnode, u16 capabilities)
spin_unlock_bh(&tn->nametbl_lock);
read_lock_bh(&nt->cluster_scope_lock);
+ if (list_empty(&nt->cluster_scope)) {
+ read_unlock_bh(&nt->cluster_scope_lock);
+ return;
+ }
named_distribute(net, &head, dnode, &nt->cluster_scope, seqno);
tipc_node_xmit(net, &head, dnode, 0);
read_unlock_bh(&nt->cluster_scope_lock);
>
>Fixes: cad2929dc432 ("tipc: update a binding service via broadcast")
>Reported-by: Xiang Mei <xmei5@asu.edu>
>Assisted-by: Claude:claude-opus-4-8
>Signed-off-by: Weiming Shi <bestswngs@gmail.com>
>---
> net/tipc/name_distr.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
>diff --git a/net/tipc/name_distr.c b/net/tipc/name_distr.c index
>ba4f4906e13b..c04fea4650a5 100644
>--- a/net/tipc/name_distr.c
>+++ b/net/tipc/name_distr.c
>@@ -192,7 +192,10 @@ static void named_distribute(struct net *net, struct
>sk_buff_head *list,
> skb_trim(skb, INT_H_SIZE + (msg_dsz - msg_rem));
> __skb_queue_tail(list, skb);
> }
>- hdr = buf_msg(skb_peek_tail(list));
>+ skb = skb_peek_tail(list);
>+ if (!skb)
>+ return;
>+ hdr = buf_msg(skb);
> msg_set_last_bulk(hdr);
> msg_set_named_seqno(hdr, seqno);
> }
>@@ -219,7 +222,8 @@ void tipc_named_node_up(struct net *net, u32 dnode,
>u16 capabilities)
>
> read_lock_bh(&nt->cluster_scope_lock);
> named_distribute(net, &head, dnode, &nt->cluster_scope, seqno);
>- tipc_node_xmit(net, &head, dnode, 0);
>+ if (!skb_queue_empty(&head))
>+ tipc_node_xmit(net, &head, dnode, 0);
> read_unlock_bh(&nt->cluster_scope_lock);
> }
>
>--
>2.43.0
>
^ permalink raw reply related
* [PATCH net] arm64: dts: ti: k3-am64: Fix MDIO clock reference for ICSSG0 node
From: Meghana Malladi @ 2026-07-06 9:22 UTC (permalink / raw)
To: Vignesh Raghavendra, Nishanth Menon
Cc: s-anna, grygorii.strashko, conor+dt, krzk+dt, robh, kristo,
linux-arm-kernel, devicetree, linux-kernel, netdev, srk,
danishanwar, m-malladi
MDIO clock index changed from 62:3 to 81:0 to match proper clock
definition in the SoC device tree. Clock Id 81:0 belongs to ICSSG0
core clock, where as 62 belongs to EQEP2 device.
reference: https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am64x/clocks.html
Fixes: c9087e3898a1d0 ("arm64: dts: ti: k3-am64-main: Add ICSSG nodes")
Signed-off-by: Meghana Malladi <m-malladi@ti.com>
---
arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
index 1b1d3970888b..a9a83781d40f 100644
--- a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
@@ -1401,7 +1401,7 @@ tx_pru0_1: txpru@c000 {
icssg0_mdio: mdio@32400 {
compatible = "ti,davinci_mdio";
reg = <0x32400 0x100>;
- clocks = <&k3_clks 62 3>;
+ clocks = <&k3_clks 81 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <0>;
base-commit: d7a8d500d7e42837bd8dce40cb52c97c6e8706a9
--
2.43.0
^ permalink raw reply related
* Re: [syzbot] Monthly virt report (Jun 2026)
From: Stefano Garzarella @ 2026-07-06 9:24 UTC (permalink / raw)
To: mawupeng
Cc: syzbot+listbf7b8eeeb8dda31d6de1, linux-kernel, syzkaller-bugs,
virtualization, mst, jasowang, xuanzhuo, eperezma, stefanha,
davem, edumazet, kuba, pabeni, horms, kvm, netdev
In-Reply-To: <d1e9d389-affa-4d12-aaf7-3fcf3218966c@huawei.com>
On Thu, 2 Jul 2026 at 04:55, mawupeng <mawupeng1@huawei.com> wrote:
> On 周四 2026-6-25 04:32, syzbot wrote:
> > Hello virt maintainers/developers,
> >
> > This is a 31-day syzbot report for the virt subsystem.
> > All related reports/information can be found at:
> > https://syzkaller.appspot.com/upstream/s/virt
> >
> > During the period, 0 new issues were detected and 0 were fixed.
> > In total, 5 issues are still open and 61 have already been fixed.
> > There are also 2 low-priority issues.
> >
> > Some of the still happening issues:
> >
> > Ref Crashes Repro Title
> > <1> 24 No WARNING: refcount bug in call_timer_fn (4)
> > https://syzkaller.appspot.com/bug?extid=07dcf509f4c013e25dc5
> > <2> 3 Yes memory leak in __vsock_create (2)
> > https://syzkaller.appspot.com/bug?extid=1b2c9c4a0f8708082678
>
> Hi,
>
> This is regarding the still-open "memory leak in __vsock_create (2)"
> bug (#2 in the monthly virt report, extid 1b2c9c4a0f8708082678):
> https://syzkaller.appspot.com/bug?extid=1b2c9c4a0f8708082678
>
> I spent some time analyzing the root cause and the previous fix
> attempt; below is a summary and a direction that tested out.
[...]
>
> I'm not subscribed to follow the list at full volume; happy to send a
> formal patch (with the af_vsock.h / pending_work changes folded in)
> if the direction looks right to the maintainers.
Yes, please, a formal patch with a great commit message is much better
than a long text to read IMO.
Thanks,
Stefano
^ permalink raw reply
* [PATCH] ixgbe: validate E610 PFA TLV bounds
From: Pengpeng Hou @ 2026-07-06 9:25 UTC (permalink / raw)
To: Tony Nguyen
Cc: Pengpeng Hou, Przemek Kitszel, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, intel-wired-lan,
netdev, linux-kernel
ixgbe_get_pfa_module_tlv() walks E610 PFA TLV records stored in
EEPROM.
Stop parsing malformed TLVs whose header or declared value length would
exceed the PFA boundary.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_e610.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_e610.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_e610.c
index 4d8ae5b56145..03e88bdf5a43 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_e610.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_e610.c
@@ -3895,6 +3895,9 @@ static int ixgbe_get_pfa_module_tlv(struct ixgbe_hw *hw, u16 *module_tlv,
while (next_tlv < pfa_end_ptr) {
u16 tlv_sub_module_type, tlv_len;
+ if (pfa_end_ptr - next_tlv < 2)
+ break;
+
/* Read TLV type */
err = ixgbe_read_ee_aci_e610(hw, next_tlv,
&tlv_sub_module_type);
@@ -3917,6 +3920,9 @@ static int ixgbe_get_pfa_module_tlv(struct ixgbe_hw *hw, u16 *module_tlv,
/* Check next TLV, i.e. current TLV pointer + length + 2 words
* (for current TLV's type and length).
*/
+ if (tlv_len > pfa_end_ptr - next_tlv - 2)
+ break;
+
next_tlv = next_tlv + tlv_len + 2;
}
/* Module does not exist */
--
2.43.0
^ permalink raw reply related
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