* [PATCH 1/1] net: phy: realtek: Add support for PHY LEDs on RTL8221B
From: Chukun Pan @ 2026-04-01 10:00 UTC (permalink / raw)
To: David S . Miller
Cc: Andrew Lunn, Paolo Abeni, Jakub Kicinski, Eric Dumazet,
Russell King, Daniel Golle, Heiner Kallweit, linux-kernel, netdev,
Chukun Pan
Realtek RTL8221B Ethernet PHY supports three LED pins which are used to
indicate link status and activity. Add netdev trigger support for them.
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
---
drivers/net/phy/realtek/realtek_main.c | 146 +++++++++++++++++++++++++
1 file changed, 146 insertions(+)
diff --git a/drivers/net/phy/realtek/realtek_main.c b/drivers/net/phy/realtek/realtek_main.c
index 023e47ad605b..8a22e18e5c56 100644
--- a/drivers/net/phy/realtek/realtek_main.c
+++ b/drivers/net/phy/realtek/realtek_main.c
@@ -150,6 +150,15 @@
#define RTL8221B_VND2_INSR 0xa4d4
+#define RTL822X_VND2_LED(x) (0xd032 + ((x) * 2))
+#define RTL822X_VND2_LCR_LINK_10 BIT(0)
+#define RTL822X_VND2_LCR_LINK_100 BIT(1)
+#define RTL822X_VND2_LCR_LINK_1000 BIT(2)
+#define RTL822X_VND2_LCR_LINK_2500 BIT(5)
+
+#define RTL822X_VND2_LCR6 0xd040
+#define RTL822X_VND2_LED_ACT(x) BIT(x)
+
#define RTL8224_MII_RTCT 0x11
#define RTL8224_MII_RTCT_ENABLE BIT(0)
#define RTL8224_MII_RTCT_PAIR_A BIT(4)
@@ -1661,6 +1670,135 @@ static int rtl822xb_c45_read_status(struct phy_device *phydev)
return 0;
}
+static int rtl822xb_led_brightness_set(struct phy_device *phydev, u8 index,
+ enum led_brightness value)
+{
+ int ret;
+
+ if (index >= RTL8211x_LED_COUNT)
+ return -EINVAL;
+
+ /* clear HW LED setup */
+ ret = phy_write_mmd(phydev, MDIO_MMD_VEND2,
+ RTL822X_VND2_LED(index), 0);
+ if (ret < 0)
+ return ret;
+
+ /* clear HW LED blink */
+ return phy_clear_bits_mmd(phydev, MDIO_MMD_VEND2,
+ RTL822X_VND2_LCR6,
+ RTL822X_VND2_LED_ACT(index));
+}
+
+static int rtl822xb_led_hw_is_supported(struct phy_device *phydev, u8 index,
+ unsigned long rules)
+{
+ const unsigned long act_mask = BIT(TRIGGER_NETDEV_RX) |
+ BIT(TRIGGER_NETDEV_TX);
+
+ const unsigned long link_mask = BIT(TRIGGER_NETDEV_LINK) |
+ BIT(TRIGGER_NETDEV_LINK_10) |
+ BIT(TRIGGER_NETDEV_LINK_100) |
+ BIT(TRIGGER_NETDEV_LINK_1000) |
+ BIT(TRIGGER_NETDEV_LINK_2500);
+
+ if (index >= RTL8211x_LED_COUNT)
+ return -EINVAL;
+
+ /* Filter out any other unsupported triggers. */
+ if (rules & ~(link_mask | act_mask))
+ return -EOPNOTSUPP;
+
+ /* RX and TX are not differentiated, they are not possible
+ * without combination with a link trigger.
+ */
+ if ((rules & act_mask) && !(rules & link_mask))
+ return -EOPNOTSUPP;
+
+ return 0;
+}
+
+static int rtl822xb_led_hw_control_get(struct phy_device *phydev, u8 index,
+ unsigned long *rules)
+{
+ int val;
+
+ if (index >= RTL8211x_LED_COUNT)
+ return -EINVAL;
+
+ val = phy_read_mmd(phydev, MDIO_MMD_VEND2, RTL822X_VND2_LED(index));
+ if (val < 0)
+ return val;
+
+ if (val & RTL822X_VND2_LCR_LINK_10)
+ __set_bit(TRIGGER_NETDEV_LINK_10, rules);
+
+ if (val & RTL822X_VND2_LCR_LINK_100)
+ __set_bit(TRIGGER_NETDEV_LINK_100, rules);
+
+ if (val & RTL822X_VND2_LCR_LINK_1000)
+ __set_bit(TRIGGER_NETDEV_LINK_1000, rules);
+
+ if (val & RTL822X_VND2_LCR_LINK_2500)
+ __set_bit(TRIGGER_NETDEV_LINK_2500, rules);
+
+ if ((val & RTL822X_VND2_LCR_LINK_10) &&
+ (val & RTL822X_VND2_LCR_LINK_100) &&
+ (val & RTL822X_VND2_LCR_LINK_1000) &&
+ (val & RTL822X_VND2_LCR_LINK_2500))
+ __set_bit(TRIGGER_NETDEV_LINK, rules);
+
+ val = phy_read_mmd(phydev, MDIO_MMD_VEND2, RTL822X_VND2_LCR6);
+ if (val < 0)
+ return val;
+
+ if (val & RTL822X_VND2_LED_ACT(index)) {
+ __set_bit(TRIGGER_NETDEV_RX, rules);
+ __set_bit(TRIGGER_NETDEV_TX, rules);
+ }
+
+ return 0;
+}
+
+static int rtl822xb_led_hw_control_set(struct phy_device *phydev, u8 index,
+ unsigned long rules)
+{
+ u16 val = 0;
+ bool act;
+ int ret;
+
+ if (index >= RTL8211x_LED_COUNT)
+ return -EINVAL;
+
+ if (test_bit(TRIGGER_NETDEV_LINK, &rules) ||
+ test_bit(TRIGGER_NETDEV_LINK_10, &rules))
+ val |= RTL822X_VND2_LCR_LINK_10;
+
+ if (test_bit(TRIGGER_NETDEV_LINK, &rules) ||
+ test_bit(TRIGGER_NETDEV_LINK_100, &rules))
+ val |= RTL822X_VND2_LCR_LINK_100;
+
+ if (test_bit(TRIGGER_NETDEV_LINK, &rules) ||
+ test_bit(TRIGGER_NETDEV_LINK_1000, &rules))
+ val |= RTL822X_VND2_LCR_LINK_1000;
+
+ if (test_bit(TRIGGER_NETDEV_LINK, &rules) ||
+ test_bit(TRIGGER_NETDEV_LINK_2500, &rules))
+ val |= RTL822X_VND2_LCR_LINK_2500;
+
+ ret = phy_write_mmd(phydev, MDIO_MMD_VEND2,
+ RTL822X_VND2_LED(index), val);
+ if (ret < 0)
+ return ret;
+
+ act = test_bit(TRIGGER_NETDEV_RX, &rules) ||
+ test_bit(TRIGGER_NETDEV_TX, &rules);
+
+ return phy_modify_mmd(phydev, MDIO_MMD_VEND2, RTL822X_VND2_LCR6,
+ RTL822X_VND2_LED_ACT(index), act ?
+ RTL822X_VND2_LED_ACT(index) : 0);
+}
+
static int rtl8224_cable_test_start(struct phy_device *phydev)
{
u32 val;
@@ -2427,6 +2565,10 @@ static struct phy_driver realtek_drvs[] = {
.write_page = rtl821x_write_page,
.read_mmd = rtl822xb_read_mmd,
.write_mmd = rtl822xb_write_mmd,
+ .led_brightness_set = rtl822xb_led_brightness_set,
+ .led_hw_is_supported = rtl822xb_led_hw_is_supported,
+ .led_hw_control_get = rtl822xb_led_hw_control_get,
+ .led_hw_control_set = rtl822xb_led_hw_control_set,
}, {
.match_phy_device = rtl8221b_vm_cg_match_phy_device,
.name = "RTL8221B-VM-CG 2.5Gbps PHY",
@@ -2446,6 +2588,10 @@ static struct phy_driver realtek_drvs[] = {
.write_page = rtl821x_write_page,
.read_mmd = rtl822xb_read_mmd,
.write_mmd = rtl822xb_write_mmd,
+ .led_brightness_set = rtl822xb_led_brightness_set,
+ .led_hw_is_supported = rtl822xb_led_hw_is_supported,
+ .led_hw_control_get = rtl822xb_led_hw_control_get,
+ .led_hw_control_set = rtl822xb_led_hw_control_set,
}, {
.match_phy_device = rtl8251b_c45_match_phy_device,
.name = "RTL8251B 5Gbps PHY",
--
2.34.1
^ permalink raw reply related
* Re: [PATCH net-next v4 1/2] net: hsr: require valid EOT supervision TLV
From: Fernando Fernandez Mancera @ 2026-04-01 9:52 UTC (permalink / raw)
To: luka.gejak, davem, edumazet, kuba, pabeni; +Cc: netdev, fmaurer, horms
In-Reply-To: <20260401092324.52266-2-luka.gejak@linux.dev>
On 4/1/26 11:23 AM, luka.gejak@linux.dev wrote:
> From: Luka Gejak <luka.gejak@linux.dev>
>
> Supervision frames are only valid if terminated with a zero-length EOT
> TLV. The current check fails to reject non-EOT entries as the terminal
> TLV, potentially allowing malformed supervision traffic.
>
> Fix this by strictly requiring the terminal TLV to be HSR_TLV_EOT
> with a length of zero.
>
> Reviewed-by: Felix Maurer <fmaurer@redhat.com>
> Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
> ---
Hi,
This has not been reviewed by Felix. Felix provided his Reviewed-by tag
for the v1 which was completely different than this.
Revisions of this patch:
v3: https://lore.kernel.org/all/20260329112313.17164-4-luka.gejak@linux.dev/
v2: https://lore.kernel.org/all/20260326154715.38405-4-luka.gejak@linux.dev/
v1:
https://lore.kernel.org/all/20260324143503.187642-4-luka.gejak@linux.dev/
Are these contributions LLM/AI generated? I believe so based on the
email history.
AI generated review on rtl8723bs:
https://lore.kernel.org/all/B2394A3C-25FD-4CEA-8557-3E68F1F60357@linux.dev/
Another AI generated review on rtl8723bs:
https://lore.kernel.org/all/3831D599-655E-40B2-9E5D-9DF956013088@linux.dev/
Likely an AI generated review on a 1 year old HSR patch:
https://lore.kernel.org/all/DHFG26KI6L23.1YCOVQ5SSYMO5@linux.dev/
If these are indeed, AI generated contributions or reviews they should
be disclosed beforehand. Also there is the Assisted-by: tag. Also note
that developer must take full responsibility for the contribution which
means understanding it completely.
https://docs.kernel.org/process/coding-assistants.html#signed-off-by-and-developer-certificate-of-origin
Thanks,
Fernando.
^ permalink raw reply
* Re: [PATCH 1/1] lib/zlib: use atomic GCOV counters to prevent crash in inflate_fast
From: Peter Oberparleiter @ 2026-04-01 9:44 UTC (permalink / raw)
To: Konstantin Khorenko, Mikhail Zaslonko
Cc: Steffen Klassert, Herbert Xu, Masahiro Yamada, Josh Poimboeuf,
Vasileios Almpanis, Pavel Tikhomirov, linux-kernel, netdev
In-Reply-To: <20260330143256.306326-2-khorenko@virtuozzo.com>
On 30.03.2026 16:32, Konstantin Khorenko wrote:
> GCC's GCOV instrumentation can merge global branch counters with loop
> induction variables as an optimization. In inflate_fast(), the inner
> copy loops can be transformed so that GCOV counter values participate
> in computing loop addresses and bounds. Since GCOV counters are global
> (not per-CPU), concurrent execution on different CPUs causes the counter
> to change mid-computation, producing inconsistent address calculations
> and out-of-bounds memory writes.
>
> The crash manifests during IPComp (IP Payload Compression) processing
> when inflate_fast() runs concurrently on multiple CPUs:
>
> BUG: unable to handle page fault for address: ffffd0a3c0902ffa
> RIP: inflate_fast+1431
> Call Trace:
> zlib_inflate
> __deflate_decompress
> crypto_comp_decompress
> ipcomp_decompress [xfrm_ipcomp]
> ipcomp_input [xfrm_ipcomp]
> xfrm_input
>
> In one observed case, the compiler merged a global GCOV counter with the
> loop induction variable that also indexed stores. Another CPU modified
> the counter between the setup and iteration phases, causing a write
> 3.4 MB past the end of a 65 KB buffer.
>
> The kernel already uses -fno-tree-loop-im for GCOV builds (commit
> 2b40e1ea76d4) to prevent a different optimization issue. That flag
> prevents GCC from hoisting loop-invariant memory operations but does
> NOT prevent the IVopts pass from merging counters with induction
> variables.
>
> Add -fprofile-update=atomic to zlib Makefiles. This tells GCC that
> GCOV counters may be concurrently accessed, causing counter updates to
> use atomic instructions (lock addq) instead of plain load/store.
> This prevents the compiler from merging counters with loop induction
> variables. The flag is scoped to zlib only to minimize performance
> overhead from atomic operations in the rest of the kernel.
>
> Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com>
> Reviewed-by: Vasileios Almpanis <vasileios.almpanis@virtuozzo.com>
> Reviewed-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
I'm all for introducing -fprofile-update=atomic to GCOV CFLAGS as it not
only addresses this bug, but makes coverage data more consistent
overall. My only suggestion would be to apply it at global scope
(top-level Makefile), not restricting it to zlib alone. Since
GCOV-instrumented kernels already have a significant performance hit due
to the added profiling code, this side-effect of using atomic
instructions can IMO be safely ignored.
Unfortunately, while compile-testing this suggested change to the global
Makefile, I ran into the following build assert which needs more
investigation:
net/core/skbuff.c:5163:9: note: in expansion of macro ‘BUILD_BUG_ON’
5163 | BUILD_BUG_ON(skb_ext_total_length() > 255);
--
Peter Oberparleiter
Linux on IBM Z Development - IBM Germany R&D
^ permalink raw reply
* Re: [PATCH 3/6] net: Guard Legacy IP entry points with CONFIG_LEGACY_IP
From: bot+bpf-ci @ 2026-04-01 9:38 UTC (permalink / raw)
To: dwmw2, saeedm, leon, tariqt, mbloch, andrew+netdev, davem,
edumazet, kuba, pabeni, horms, razor, idosch, martin.lau, daniel,
john.fastabend, sdf, ast, andrii, eddyz87, song, yonghong.song,
kpsingh, haoluo, jolsa, kuniyu, willemb, dsahern, ncardwell,
johannes, pablo, fw, phil, gnault, dwmw, kees, alazar, gal, paul,
netdev, linux-rdma, linux-kernel, oss-drivers, bridge, bpf,
linux-wireless, netfilter-devel, coreteam, torvalds,
jon.maddog.hall
Cc: ast, andrii, daniel, martin.lau, eddyz87, yonghong.song, clm,
ihor.solodrai
In-Reply-To: <20260401074509.1897527-4-dwmw2@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 2085 bytes --]
> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> --- a/net/ipv4/af_inet.c
> +++ b/net/ipv4/af_inet.c
> @@ -1922,7 +1922,15 @@ static int __init inet_init(void)
> /*
> * Tell SOCKET that we are alive...
> */
> + /* Initialize the socket-side protocol switch tables. */
> + for (r = &inetsw[0]; r < &inetsw[SOCK_MAX]; ++r)
> + INIT_LIST_HEAD(r);
> +
> +#ifdef CONFIG_XFRM
> + xfrm_init();
> +#endif
>
> +#ifdef CONFIG_LEGACY_IP
> (void)sock_register(&inet_family_ops);
Moving xfrm_init() here places it before sock_register(), but
xfrm_init() calls xfrm_nat_keepalive_init(AF_INET) which creates
per-cpu PF_INET sockets via this chain:
xfrm_init()
xfrm_nat_keepalive_init(AF_INET)
nat_keepalive_sk_init(&nat_keepalive_sk_ipv4, PF_INET)
inet_ctl_sock_create(&sk, PF_INET, ...)
sock_create_kern()
__sock_create()
pf = rcu_dereference(net_families[PF_INET]);
if (!pf) -> returns -EAFNOSUPPORT
Since sock_register(&inet_family_ops) has not been called yet,
net_families[PF_INET] is still NULL at this point. This causes
xfrm_nat_keepalive_init(AF_INET) to silently fail (the return
value is not checked by xfrm_init()), leaving the IPv4 XFRM NAT
keepalive sockets uninitialized.
This affects the default CONFIG_LEGACY_IP=y configuration as
well, not just IPv6-only builds. Would it be better to leave
xfrm_init() after sock_register(), or move the
xfrm_nat_keepalive_init(AF_INET) call into xfrm4_init() where
it would run after IPv4 socket registration is complete?
Previously, xfrm_init() was called from ip_rt_init() which ran
well after sock_register():
inet_init()
sock_register(&inet_family_ops) <-- AF_INET available
...
ip_init()
ip_rt_init()
xfrm_init() <-- worked fine
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/23838411859
^ permalink raw reply
* Re: [PATCH 3/6] net: Guard Legacy IP entry points with CONFIG_LEGACY_IP
From: David Woodhouse @ 2026-04-01 9:34 UTC (permalink / raw)
To: Eric Dumazet
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch,
Andrew Lunn, David S. Miller, Jakub Kicinski, Paolo Abeni,
Simon Horman, Nikolay Aleksandrov, Ido Schimmel, Martin KaFai Lau,
Daniel Borkmann, John Fastabend, Stanislav Fomichev,
Alexei Starovoitov, Andrii Nakryiko, Eduard Zingerman, Song Liu,
Yonghong Song, KP Singh, Hao Luo, Jiri Olsa, Kuniyuki Iwashima,
Willem de Bruijn, David Ahern, Neal Cardwell, Johannes Berg,
Pablo Neira Ayuso, Florian Westphal, Phil Sutter, Guillaume Nault,
Kees Cook, Alexei Lazar, Gal Pressman, Paul Moore, netdev,
linux-rdma, linux-kernel, oss-drivers, bridge, bpf,
linux-wireless, netfilter-devel, coreteam, torvalds
In-Reply-To: <CANn89i+iRUgqtd+eirfSUM3k+keNZKzLwsHxZtwE+vHdv7H5PQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 943 bytes --]
On Wed, 2026-04-01 at 02:14 -0700, Eric Dumazet wrote:
>
> >
> > /* Add UDP-Lite (RFC 3828) */
> > - udplite4_register();
> > + if (IS_ENABLED(CONFIG_LEGACY_IP))
> > + udplite4_register();
>
> udplite has been removed in net-next.
>
> I would think your patch series is net-next material ?
A more conservative variant of the patch series on another day of the
year, sure. It also probably wants to land after
https://lore.kernel.org/lkml/20260310153506.5181-1-fmancera@suse.de/
turns CONFIG_IPV6 into a boolean.
I'll need to take a closer look at CONFIG_INET too; it ends up being
possible to configure with INET && !LEGACY_IP && !IPV6 which isn't a
combination that makes sense (and I obviously didn't test).
As discussed, some of this series *is* realistic for another day, and
I'll happily work on whatever direction we think makes sense.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [PATCH net] net/mlx5: fs, fix invalid pointer dereference in mlx5_fs_add_rule tracepoint
From: Moshe Shemesh @ 2026-04-01 9:33 UTC (permalink / raw)
To: kenneth, Saeed Mahameed, Leon Romanovsky, Tariq Toukan,
Mark Bloch
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Yevgeny Kliteynik, netdev, linux-rdma, linux-kernel,
stable
In-Reply-To: <20260328192008.3525475-1-kenneth@bridgetech.tv>
On 3/28/2026 10:20 PM, kenneth@bridgetech.tv wrote:
>
> The mlx5_fs_add_rule tracepoint has used the flow destination type in
> a bitwise test since its introduction. However, that's not a valid way
> to treat it anymore (if it ever was), and after commit d639af621600dc
> ("net/mlx5: fs, split software and IFC flow destination definitions"),
> this mismatch caused nearly any destination type to be mistaken as a
> flow counter, and thus stashing 32 bits of the mlx5_flow_destination
> union into the counter_id field of the tracepoint.
>
> Later commit 95f68e06b41b9e ("net/mlx5: fs, add counter object to flow
> destination") exacerbates this issue by converting the counter union
> member from an integer to a pointer. Now the tracepoint dereferences
> whichever value is in the union, and in cases where that's not a valid
> pointer, it can lead to a kernel oops.
>
> Fix the check. Reported by GitHub user whi71800.
>
> Cc:stable@vger.kernel.org
> Fixes: 95f68e06b41b9e ("net/mlx5: fs, add counter object to flow destination")
> Closes:https://github.com/knneth/mlnx-ofa_kernel/issues/1
> Signed-off-by: Kenneth Klette Jonassen<kenneth@bridgetech.tv>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 4/4] net: macb: Remove dedicated IRQ handler for WoL
From: Kevin Hao @ 2026-04-01 9:32 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Nicolas Ferre, Claudiu Beznea, Andrew Lunn, David S. Miller,
Eric Dumazet, Paolo Abeni, netdev
In-Reply-To: <20260331195517.68108163@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2911 bytes --]
On Tue, Mar 31, 2026 at 07:55:17PM -0700, Jakub Kicinski wrote:
> On Sat, 28 Mar 2026 18:17:48 +0800 Kevin Hao wrote:
> > In the current implementation, the suspend/resume path frees the
> > existing IRQ handler and sets up a dedicated WoL IRQ handler, then
> > restores the original handler upon resume. This approach is not used
> > by any other Ethernet driver and unnecessarily complicates the
> > suspend/resume process. After adjusting the IRQ handler in the previous
> > patches, we can now handle WoL interrupts without introducing any
> > overhead in the TX/RX hot path. Therefore, the dedicated WoL IRQ
> > handler is removed.
>
> Couple of sentences on testing (platform + flows) would be great here.
I have verified WoL functionality on my AMD ZynqMP board using the following
steps. I will include this information in the v2 commit.
root@amd-zynqmp:~# ifconfig end0 192.168.3.3
root@amd-zynqmp:~# ethtool -s end0 wol a
root@amd-zynqmp:~# echo mem >/sys/power/state
PM: suspend entry (deep)
Filesystems sync: 0.055 seconds
Freezing user space processes
Freezing user space processes completed (elapsed 0.006 seconds)
OOM killer disabled.
Freezing remaining freezable tasks
Freezing remaining freezable tasks completed (elapsed 0.004 seconds)
printk: Suspending console(s) (use no_console_suspend to debug)
macb ff0e0000.ethernet: gem-ptp-timer ptp clock unregistered.
e1000e: EEE TX LPI TIMER: 00000000
xuartps ff000000.serial: ttyPS0: Unable to drain transmitter
Disabling non-boot CPUs ...
psci: CPU3 killed (polled 0 ms)
psci: CPU2 killed (polled 0 ms)
psci: CPU1 killed (polled 0 ms)
Enabling non-boot CPUs ...
Detected VIPT I-cache on CPU1
CPU1: Booted secondary processor 0x0000000001 [0x410fd034]
CPU1 is up
Detected VIPT I-cache on CPU2
CPU2: Booted secondary processor 0x0000000002 [0x410fd034]
CPU2 is up
Detected VIPT I-cache on CPU3
CPU3: Booted secondary processor 0x0000000003 [0x410fd034]
CPU3 is up
macb ff0e0000.ethernet end0: Link is Down
macb ff0e0000.ethernet end0: configuring for phy/rgmii-id link mode
macb ff0e0000.ethernet end0: Link is Up - 1Gbps/Full - flow control tx
ptp ptp0: PM: parent end0 should not be sleeping
macb ff0e0000.ethernet: gem-ptp-timer ptp clock registered.
phy phy-fd400000.phy.2: phy_power_on was called before phy_init
ata1: SATA link down (SStatus 0 SControl 330)
ata2: SATA link down (SStatus 0 SControl 330)
e1000e 0000:01:00.0 enp1s0: Hardware Error
OOM killer enabled.
Restarting tasks: Starting
Restarting tasks: Done
random: crng reseeded on system resumption
PM: suspend exit
root@amd-zynqmp:~# e1000e 0000:01:00.0 enp1s0: Hardware Error
root@amd-zynqmp:~# e1000e 0000:01:00.0 enp1s0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
root@amd-zynqmp:~#
Thanks,
Kevin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 3/4] net: macb: Factor out the handling of non-hot IRQ events into a separate function
From: Kevin Hao @ 2026-04-01 9:31 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Nicolas Ferre, Claudiu Beznea, Andrew Lunn, David S. Miller,
Eric Dumazet, Paolo Abeni, netdev
In-Reply-To: <20260331195431.7965c24a@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 444 bytes --]
On Tue, Mar 31, 2026 at 07:54:31PM -0700, Jakub Kicinski wrote:
> On Sat, 28 Mar 2026 18:17:47 +0800 Kevin Hao wrote:
> > struct macb_queue *queue = dev_id;
> > struct macb *bp = queue->bp;
> > struct net_device *dev = bp->dev;
> > - u32 status, ctrl;
> > + u32 status;
> > bool isr_clear;
>
> nit: please try to keep the variable declaration lines sorted longest to
> shortest
Will address this in v2.
Thanks,
Kevin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 2/4] net: macb: Consolidate MACB_CAPS_ISR_CLEAR_ON_WRITE checks in IRQ handler
From: Kevin Hao @ 2026-04-01 9:30 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Nicolas Ferre, Claudiu Beznea, Andrew Lunn, David S. Miller,
Eric Dumazet, Paolo Abeni, netdev
In-Reply-To: <20260331195400.16bb697c@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2416 bytes --]
> On Sat, 28 Mar 2026 18:17:46 +0800 Kevin Hao wrote:
On Tue, Mar 31, 2026 at 07:54:00PM -0700, Jakub Kicinski wrote:
> > Currently, the MACB_CAPS_ISR_CLEAR_ON_WRITE flag is checked in every
> > branch of the IRQ handler. This repeated evaluation is unnecessary.
> > By consolidating the flag check, we eliminate redundant loads of
> > bp->caps when TX and RX events occur simultaneously, a common scenario
> > under high network throughput. Additionally, this optimization reduces
> > the function size from 0x2e8 to 0x2c4.
>
> feels a bit subjective TBH. An alternative improvement would be to
> factor out the conditional to a helper:
>
> static void macb_queue_isr_clear(bp, queue, mask)
> {
> if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE)
> queue_writel(queue, ISR, mask);
> }
In addition to the similar pattern in the macb_interrupt() function, there are
seven other instances of this pattern in the macb driver.
$ git grep "if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE)" drivers/net/ethernet/cadence/ | wc -l
7
I agree that using a helper function, as you proposed, would reduce the number
of source code lines and improve the readability of the driver. However, such
changes would not affect the final generated code.
The goal of my changes is to reduce both the footprint of macb_interrupt() and
the number of assembly instructions executed within its event loop.
Before the patch, the condition `if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE)`
produced the following assembly:
ffff800080d58b1c: 387b6a68 ldrb w8, [x19, x27]
ffff800080d58b20: 360000c8 tbz w8, #0, ffff800080d58b38 <macb_interrupt+0xd0>
After the patch, the condition `if (isr_clear)` results in:
ffff800080d58a4c: 360000d8 tbz w24, #0, ffff800080d58a64 <macb_interrupt+0xac>
Thus, we eliminate two `ldrb` overheads per iteration of the event loop in
macb_interrupt() when both TX and RX events occur simultaneously. This also
reduces the function's footprint by 36 bytes, as the `ldrb` instructions are
omitted in each event branch.
Therefore, your proposed changes and mine serve different purposes.
I acknowledge that my change represents only a very slight optimization for
the interrupt handler. I am also open to your preference for improving source
code readability. Please let me know your decision.
Thanks,
Kevin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 6/6] net: Warn when processes listen on AF_INET sockets
From: David Woodhouse @ 2026-04-01 9:28 UTC (permalink / raw)
To: Eric Dumazet
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch,
Andrew Lunn, David S. Miller, Jakub Kicinski, Paolo Abeni,
Simon Horman, Nikolay Aleksandrov, Ido Schimmel, Martin KaFai Lau,
Daniel Borkmann, John Fastabend, Stanislav Fomichev,
Alexei Starovoitov, Andrii Nakryiko, Eduard Zingerman, Song Liu,
Yonghong Song, KP Singh, Hao Luo, Jiri Olsa, Kuniyuki Iwashima,
Willem de Bruijn, David Ahern, Neal Cardwell, Johannes Berg,
Pablo Neira Ayuso, Florian Westphal, Phil Sutter, Guillaume Nault,
Kees Cook, Alexei Lazar, Gal Pressman, Paul Moore, netdev,
linux-rdma, linux-kernel, oss-drivers, bridge, bpf,
linux-wireless, netfilter-devel, coreteam, torvalds
In-Reply-To: <CANn89i+GHkkubJp3MTKZ_r4tde1qLejfsxUh+w0gPZ3ec+YdjQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]
On Wed, 2026-04-01 at 02:11 -0700, Eric Dumazet wrote:
> On Wed, Apr 1, 2026 at 12:45 AM David Woodhouse <dwmw2@infradead.org> wrote:
> >
> > From: David Woodhouse <dwmw@amazon.co.uk>
> >
> > There is no need to listen on AF_INET sockets; a modern application can
> > listen on IPv6 (without IPV6_V6ONLY) and will accept connections from
> > the 20th century via IPv4-mapped addresses (::ffff:x.x.x.x) on the IPv6
> > socket.
> >
> > Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
> > ---
> > net/ipv4/af_inet.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> > index dc358faa1647..3838782a8437 100644
> > --- a/net/ipv4/af_inet.c
> > +++ b/net/ipv4/af_inet.c
> > @@ -240,6 +240,9 @@ int inet_listen(struct socket *sock, int backlog)
> > struct sock *sk = sock->sk;
> > int err = -EINVAL;
> >
> > + pr_warn_once("process '%s' (pid %d) is listening on an AF_INET socket. Consider using AF_INET6 with IPV6_V6ONLY=0 instead.\n",
> > + current->comm, task_pid_nr(current));
> > +
>
> Some kernels are built without CONFIG_IPV6, so this warning would be
> quite misleading.
Maybe on this date next year, we could make it not possible to build
the kernel *without* IPv6... ?
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [PATCH 6/6] net: Warn when processes listen on AF_INET sockets
From: bot+bpf-ci @ 2026-04-01 9:26 UTC (permalink / raw)
To: dwmw2, saeedm, leon, tariqt, mbloch, andrew+netdev, davem,
edumazet, kuba, pabeni, horms, razor, idosch, martin.lau, daniel,
john.fastabend, sdf, ast, andrii, eddyz87, song, yonghong.song,
kpsingh, haoluo, jolsa, kuniyu, willemb, dsahern, ncardwell,
johannes, pablo, fw, phil, gnault, dwmw, kees, alazar, gal, paul,
netdev, linux-rdma, linux-kernel, oss-drivers, bridge, bpf,
linux-wireless, netfilter-devel, coreteam, torvalds,
jon.maddog.hall
Cc: ast, andrii, daniel, martin.lau, eddyz87, yonghong.song, clm,
ihor.solodrai
In-Reply-To: <20260401074509.1897527-7-dwmw2@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 1465 bytes --]
> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> index dc358faa1647..3838782a8437 100644
> --- a/net/ipv4/af_inet.c
> +++ b/net/ipv4/af_inet.c
> @@ -240,6 +240,9 @@ int inet_listen(struct socket *sock, int backlog)
> struct sock *sk = sock->sk;
> int err = -EINVAL;
>
> + pr_warn_once("process '%s' (pid %d) is listening on an AF_INET socket. Consider using AF_INET6 with IPV6_V6ONLY=0 instead.\n",
> + current->comm, task_pid_nr(current));
inet_listen() is the .listen handler for both inet_stream_ops
(AF_INET) and inet6_stream_ops (AF_INET6):
net/ipv4/af_inet.c:
.listen = inet_listen,
net/ipv6/af_inet6.c:
.listen = inet_listen, /* ok */
Since pr_warn_once fires on the first listen() call regardless of
address family, won't this warn about "listening on an AF_INET
socket" when an AF_INET6 socket calls listen() first? Many services
(e.g. systemd socket activation) create AF_INET6 sockets before
AF_INET ones. Should there be a check for sk->sk_family == AF_INET
before printing?
Separately, the warning suggests using AF_INET6 with IPV6_V6ONLY=0,
but when CONFIG_IPV6 is disabled, AF_INET6 sockets are not available.
Should the warning be conditional on IS_ENABLED(CONFIG_IPV6)?
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/23838411859
^ permalink raw reply
* [PATCH net-next v4 2/2] net: hsr: reject unresolved interlink ifindex
From: luka.gejak @ 2026-04-01 9:23 UTC (permalink / raw)
To: davem, edumazet, kuba, pabeni; +Cc: netdev, fmaurer, horms, luka.gejak
In-Reply-To: <20260401092324.52266-1-luka.gejak@linux.dev>
From: Luka Gejak <luka.gejak@linux.dev>
In hsr_newlink(), a provided but invalid IFLA_HSR_INTERLINK attribute
was silently ignored if __dev_get_by_index() returned NULL. This leads
to incorrect RedBox topology creation without notifying the user.
Fix this by returning -EINVAL and an extack message when the
interlink attribute is present but cannot be resolved.
Reviewed-by: Felix Maurer <fmaurer@redhat.com>
Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
---
net/hsr/hsr_netlink.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/net/hsr/hsr_netlink.c b/net/hsr/hsr_netlink.c
index db0b0af7a692..f0ca23da3ab9 100644
--- a/net/hsr/hsr_netlink.c
+++ b/net/hsr/hsr_netlink.c
@@ -76,9 +76,14 @@ static int hsr_newlink(struct net_device *dev,
return -EINVAL;
}
- if (data[IFLA_HSR_INTERLINK])
+ if (data[IFLA_HSR_INTERLINK]) {
interlink = __dev_get_by_index(link_net,
nla_get_u32(data[IFLA_HSR_INTERLINK]));
+ if (!interlink) {
+ NL_SET_ERR_MSG_MOD(extack, "Interlink does not exist");
+ return -EINVAL;
+ }
+ }
if (interlink && interlink == link[0]) {
NL_SET_ERR_MSG_MOD(extack, "Interlink and Slave1 are the same");
--
2.53.0
^ permalink raw reply related
* [PATCH net-next v4 1/2] net: hsr: require valid EOT supervision TLV
From: luka.gejak @ 2026-04-01 9:23 UTC (permalink / raw)
To: davem, edumazet, kuba, pabeni; +Cc: netdev, fmaurer, horms, luka.gejak
In-Reply-To: <20260401092324.52266-1-luka.gejak@linux.dev>
From: Luka Gejak <luka.gejak@linux.dev>
Supervision frames are only valid if terminated with a zero-length EOT
TLV. The current check fails to reject non-EOT entries as the terminal
TLV, potentially allowing malformed supervision traffic.
Fix this by strictly requiring the terminal TLV to be HSR_TLV_EOT
with a length of zero.
Reviewed-by: Felix Maurer <fmaurer@redhat.com>
Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
---
net/hsr/hsr_forward.c | 41 ++++++++++++++++++++++-------------------
1 file changed, 22 insertions(+), 19 deletions(-)
diff --git a/net/hsr/hsr_forward.c b/net/hsr/hsr_forward.c
index 0aca859c88cb..17b705235c4a 100644
--- a/net/hsr/hsr_forward.c
+++ b/net/hsr/hsr_forward.c
@@ -82,39 +82,42 @@ static bool is_supervision_frame(struct hsr_priv *hsr, struct sk_buff *skb)
hsr_sup_tag->tlv.HSR_TLV_length != sizeof(struct hsr_sup_payload))
return false;
- /* Get next tlv */
+ /* Advance past the first TLV payload to reach next TLV header */
total_length += hsr_sup_tag->tlv.HSR_TLV_length;
- if (!pskb_may_pull(skb, total_length))
+ /* Linearize next TLV header before access */
+ if (!pskb_may_pull(skb, total_length + sizeof(struct hsr_sup_tlv)))
return false;
skb_pull(skb, total_length);
hsr_sup_tlv = (struct hsr_sup_tlv *)skb->data;
skb_push(skb, total_length);
- /* if this is a redbox supervision frame we need to verify
- * that more data is available
+ /* Walk through TLVs to find end-of-TLV marker, skipping any unknown
+ * extension TLVs to maintain forward compatibility.
*/
- if (hsr_sup_tlv->HSR_TLV_type == PRP_TLV_REDBOX_MAC) {
- /* tlv length must be a length of a mac address */
- if (hsr_sup_tlv->HSR_TLV_length != sizeof(struct hsr_sup_payload))
- return false;
+ for (;;) {
+ if (hsr_sup_tlv->HSR_TLV_type == HSR_TLV_EOT &&
+ hsr_sup_tlv->HSR_TLV_length == 0)
+ return true;
- /* make sure another tlv follows */
- total_length += sizeof(struct hsr_sup_tlv) + hsr_sup_tlv->HSR_TLV_length;
- if (!pskb_may_pull(skb, total_length))
+ /* Validate known TLV types */
+ if (hsr_sup_tlv->HSR_TLV_type == PRP_TLV_REDBOX_MAC) {
+ if (hsr_sup_tlv->HSR_TLV_length !=
+ sizeof(struct hsr_sup_payload))
+ return false;
+ }
+
+ /* Advance past current TLV: header + payload */
+ total_length += sizeof(struct hsr_sup_tlv) +
+ hsr_sup_tlv->HSR_TLV_length;
+ /* Linearize next TLV header before access */
+ if (!pskb_may_pull(skb,
+ total_length + sizeof(struct hsr_sup_tlv)))
return false;
- /* get next tlv */
skb_pull(skb, total_length);
hsr_sup_tlv = (struct hsr_sup_tlv *)skb->data;
skb_push(skb, total_length);
}
-
- /* end of tlvs must follow at the end */
- if (hsr_sup_tlv->HSR_TLV_type == HSR_TLV_EOT &&
- hsr_sup_tlv->HSR_TLV_length != 0)
- return false;
-
- return true;
}
static bool is_proxy_supervision_frame(struct hsr_priv *hsr,
--
2.53.0
^ permalink raw reply related
* [PATCH net-next v4 0/2] net: hsr: strict supervision TLV validation
From: luka.gejak @ 2026-04-01 9:23 UTC (permalink / raw)
To: davem, edumazet, kuba, pabeni; +Cc: netdev, fmaurer, horms, luka.gejak
From: Luka Gejak <luka.gejak@linux.dev>
This series improves the robustness of HSR supervision frame parsing.
It enforces strict supervision frame TLV validation and improves Netlink
error reporting for invalid interlink attributes.
These were previously part of a 4-patch set. The first two patches
(fixes) have been sent separately to the 'net' tree.
Changes in v4:
- Split from a 4-patch series into 'net' and 'net-next' as requested.
- Implemented a TLV walker in Patch 1 to correctly handle extension
TLVs and avoid regressions on paged frames/non-linearized skbs.
- Corrected pskb_may_pull() logic to include the TLV header size.
History of pre-separation series (v1-v3):
Changes in v3:
- addressed Felix review feedback in the VLAN add unwind fix
- removed the superfluous empty line
Changes in v2:
- picked up Reviewed-by tags on patches 1, 3 and 4
- changes in patch 2 per advice of Felix Maurer
Luka Gejak (2):
net: hsr: require valid EOT supervision TLV
net: hsr: reject unresolved interlink ifindex
net/hsr/hsr_forward.c | 41 ++++++++++++++++++++++-------------------
net/hsr/hsr_netlink.c | 7 ++++++-
2 files changed, 28 insertions(+), 20 deletions(-)
--
2.53.0
^ permalink raw reply
* [PATCH net v4 2/2] net: hsr: fix VLAN add unwind on slave errors
From: luka.gejak @ 2026-04-01 9:22 UTC (permalink / raw)
To: davem, edumazet, kuba, pabeni
Cc: netdev, fmaurer, horms, bigeasy, m-karicheri2, luka.gejak
In-Reply-To: <20260401092243.52121-1-luka.gejak@linux.dev>
From: Luka Gejak <luka.gejak@linux.dev>
When vlan_vid_add() fails for a secondary slave, the error path calls
vlan_vid_del() on the failing port instead of the peer slave that had
already succeeded. This results in asymmetric VLAN state across the HSR
pair.
Fix this by switching to a centralized unwind path that removes the VID
from any slave device that was already programmed.
Fixes: 1a8a63a5305e ("net: hsr: Add VLAN CTAG filter support")
Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
---
net/hsr/hsr_device.c | 32 +++++++++++++++++---------------
1 file changed, 17 insertions(+), 15 deletions(-)
diff --git a/net/hsr/hsr_device.c b/net/hsr/hsr_device.c
index 90236028817d..5555b71ab19b 100644
--- a/net/hsr/hsr_device.c
+++ b/net/hsr/hsr_device.c
@@ -532,8 +532,8 @@ static void hsr_change_rx_flags(struct net_device *dev, int change)
static int hsr_ndo_vlan_rx_add_vid(struct net_device *dev,
__be16 proto, u16 vid)
{
- bool is_slave_a_added = false;
- bool is_slave_b_added = false;
+ struct net_device *slave_a_dev = NULL;
+ struct net_device *slave_b_dev = NULL;
struct hsr_port *port;
struct hsr_priv *hsr;
int ret = 0;
@@ -549,33 +549,35 @@ static int hsr_ndo_vlan_rx_add_vid(struct net_device *dev,
switch (port->type) {
case HSR_PT_SLAVE_A:
if (ret) {
- /* clean up Slave-B */
netdev_err(dev, "add vid failed for Slave-A\n");
- if (is_slave_b_added)
- vlan_vid_del(port->dev, proto, vid);
- return ret;
+ goto unwind;
}
-
- is_slave_a_added = true;
+ slave_a_dev = port->dev;
break;
-
case HSR_PT_SLAVE_B:
if (ret) {
- /* clean up Slave-A */
netdev_err(dev, "add vid failed for Slave-B\n");
- if (is_slave_a_added)
- vlan_vid_del(port->dev, proto, vid);
- return ret;
+ goto unwind;
}
-
- is_slave_b_added = true;
+ slave_b_dev = port->dev;
break;
default:
+ if (ret)
+ goto unwind;
break;
}
}
return 0;
+
+unwind:
+ if (slave_a_dev)
+ vlan_vid_del(slave_a_dev, proto, vid);
+
+ if (slave_b_dev)
+ vlan_vid_del(slave_b_dev, proto, vid);
+
+ return ret;
}
static int hsr_ndo_vlan_rx_kill_vid(struct net_device *dev,
--
2.53.0
^ permalink raw reply related
* [PATCH net v4 1/2] net: hsr: serialize seq_blocks merge across nodes
From: luka.gejak @ 2026-04-01 9:22 UTC (permalink / raw)
To: davem, edumazet, kuba, pabeni
Cc: netdev, fmaurer, horms, bigeasy, m-karicheri2, luka.gejak
In-Reply-To: <20260401092243.52121-1-luka.gejak@linux.dev>
From: Luka Gejak <luka.gejak@linux.dev>
During node merging, hsr_handle_sup_frame() walks node_curr->seq_blocks
to update node_real without holding node_curr->seq_out_lock. This
allows concurrent mutations from duplicate registration paths, risking
inconsistent state or XArray/bitmap corruption.
Fix this by locking both nodes' seq_out_lock during the merge.
To prevent ABBA deadlocks, locks are acquired in order of memory
address.
Reviewed-by: Felix Maurer <fmaurer@redhat.com>
Fixes: 415e6367512b ("hsr: Implement more robust duplicate discard for PRP")
Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
---
net/hsr/hsr_framereg.c | 38 ++++++++++++++++++++++++++++++++++++--
1 file changed, 36 insertions(+), 2 deletions(-)
diff --git a/net/hsr/hsr_framereg.c b/net/hsr/hsr_framereg.c
index 577fb588bc2f..d09875b33588 100644
--- a/net/hsr/hsr_framereg.c
+++ b/net/hsr/hsr_framereg.c
@@ -123,6 +123,40 @@ static void hsr_free_node_rcu(struct rcu_head *rn)
hsr_free_node(node);
}
+static void hsr_lock_seq_out_pair(struct hsr_node *node_a,
+ struct hsr_node *node_b)
+{
+ if (node_a == node_b) {
+ spin_lock_bh(&node_a->seq_out_lock);
+ return;
+ }
+
+ if (node_a < node_b) {
+ spin_lock_bh(&node_a->seq_out_lock);
+ spin_lock_nested(&node_b->seq_out_lock, SINGLE_DEPTH_NESTING);
+ } else {
+ spin_lock_bh(&node_b->seq_out_lock);
+ spin_lock_nested(&node_a->seq_out_lock, SINGLE_DEPTH_NESTING);
+ }
+}
+
+static void hsr_unlock_seq_out_pair(struct hsr_node *node_a,
+ struct hsr_node *node_b)
+{
+ if (node_a == node_b) {
+ spin_unlock_bh(&node_a->seq_out_lock);
+ return;
+ }
+
+ if (node_a < node_b) {
+ spin_unlock(&node_b->seq_out_lock);
+ spin_unlock_bh(&node_a->seq_out_lock);
+ } else {
+ spin_unlock(&node_a->seq_out_lock);
+ spin_unlock_bh(&node_b->seq_out_lock);
+ }
+}
+
void hsr_del_nodes(struct list_head *node_db)
{
struct hsr_node *node;
@@ -432,7 +466,7 @@ void hsr_handle_sup_frame(struct hsr_frame_info *frame)
}
ether_addr_copy(node_real->macaddress_B, ethhdr->h_source);
- spin_lock_bh(&node_real->seq_out_lock);
+ hsr_lock_seq_out_pair(node_real, node_curr);
for (i = 0; i < HSR_PT_PORTS; i++) {
if (!node_curr->time_in_stale[i] &&
time_after(node_curr->time_in[i], node_real->time_in[i])) {
@@ -455,7 +489,7 @@ void hsr_handle_sup_frame(struct hsr_frame_info *frame)
src_blk->seq_nrs[i], HSR_SEQ_BLOCK_SIZE);
}
}
- spin_unlock_bh(&node_real->seq_out_lock);
+ hsr_unlock_seq_out_pair(node_real, node_curr);
node_real->addr_B_port = port_rcv->type;
spin_lock_bh(&hsr->list_lock);
--
2.53.0
^ permalink raw reply related
* [PATCH net v4 0/2] net: hsr: fixes for PRP duplication and VLAN unwind
From: luka.gejak @ 2026-04-01 9:22 UTC (permalink / raw)
To: davem, edumazet, kuba, pabeni
Cc: netdev, fmaurer, horms, bigeasy, m-karicheri2, luka.gejak
From: Luka Gejak <luka.gejak@linux.dev>
This series addresses two logic bugs in the HSR/PRP implementation
identified during a protocol audit. These are targeted for the 'net'
tree as they fix potential memory corruption and state inconsistency.
The primary change resolves a race condition in the node merging path by
implementing address-based lock ordering. This ensures that concurrent
mutations of sequence blocks do not lead to state corruption or
deadlocks.
An additional fix corrects asymmetric VLAN error unwinding by
implementing a centralized unwind path on slave errors.
Changes in v4:
- Split from a 4-patch series into 'net' and 'net-next' as requested.
- Added Fixes: tags to both patches to facilitate stable backporting.
- No logic changes to these patches since v3.
History of pre-separation series (v1-v3):
Changes in v3:
- addressed Felix review feedback in the VLAN add unwind fix
- removed the superfluous empty line
Changes in v2:
- picked up Reviewed-by tags on patches 1, 3 and 4
- changes in patch 2 per advice of Felix Maurer
Luka Gejak (2):
net: hsr: serialize seq_blocks merge across nodes
net: hsr: fix VLAN add unwind on slave errors
net/hsr/hsr_device.c | 32 +++++++++++++++++---------------
net/hsr/hsr_framereg.c | 38 ++++++++++++++++++++++++++++++++++++--
2 files changed, 53 insertions(+), 17 deletions(-)
--
2.53.0
^ permalink raw reply
* [PATCH net] vsock: initialize child_ns_mode_locked in vsock_net_init()
From: Stefano Garzarella @ 2026-04-01 9:21 UTC (permalink / raw)
To: netdev
Cc: Stefano Garzarella, David S. Miller, linux-kernel, Bobby Eshleman,
Jakub Kicinski, Simon Horman, virtualization, Eric Dumazet,
Paolo Abeni, Jin Liu
From: Stefano Garzarella <sgarzare@redhat.com>
The `child_ns_mode_locked` field lives in `struct net`, which persists
across vsock module reloads. When the module is unloaded and reloaded,
`vsock_net_init()` resets `mode` and `child_ns_mode` back to their
default values, but does not reset `child_ns_mode_locked`.
The stale lock from the previous module load causes subsequent writes
to `child_ns_mode` to silently fail: `vsock_net_set_child_mode()` sees
the old lock, skips updating the actual value, and returns success
when the requested mode matches the stale lock. The sysctl handler
reports no error, but `child_ns_mode` remains unchanged.
Steps to reproduce:
$ modprobe vsock
$ echo local > /proc/sys/net/vsock/child_ns_mode
$ cat /proc/sys/net/vsock/child_ns_mode
local
$ modprobe -r vsock
$ modprobe vsock
$ echo local > /proc/sys/net/vsock/child_ns_mode
$ cat /proc/sys/net/vsock/child_ns_mode
global <--- expected "local"
Fix this by initializing `child_ns_mode_locked` to 0 (unlocked) in
`vsock_net_init()`, so the write-once mechanism works correctly after
module reload.
Fixes: 102eab95f025 ("vsock: lock down child_ns_mode as write-once")
Cc: bobbyeshleman@meta.com
Reported-by: Jin Liu <jinl@redhat.com>
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
---
net/vmw_vsock/af_vsock.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index 2f7d94d682cb..d912ed2f012a 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -2928,6 +2928,7 @@ static void vsock_net_init(struct net *net)
net->vsock.mode = vsock_net_child_mode(current->nsproxy->net_ns);
net->vsock.child_ns_mode = net->vsock.mode;
+ net->vsock.child_ns_mode_locked = 0;
}
static __net_init int vsock_sysctl_init_net(struct net *net)
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 3/6] net: Guard Legacy IP entry points with CONFIG_LEGACY_IP
From: Eric Dumazet @ 2026-04-01 9:14 UTC (permalink / raw)
To: David Woodhouse
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch,
Andrew Lunn, David S. Miller, Jakub Kicinski, Paolo Abeni,
Simon Horman, Nikolay Aleksandrov, Ido Schimmel, Martin KaFai Lau,
Daniel Borkmann, John Fastabend, Stanislav Fomichev,
Alexei Starovoitov, Andrii Nakryiko, Eduard Zingerman, Song Liu,
Yonghong Song, KP Singh, Hao Luo, Jiri Olsa, Kuniyuki Iwashima,
Willem de Bruijn, David Ahern, Neal Cardwell, Johannes Berg,
Pablo Neira Ayuso, Florian Westphal, Phil Sutter, Guillaume Nault,
David Woodhouse, Kees Cook, Alexei Lazar, Gal Pressman,
Paul Moore, netdev, linux-rdma, linux-kernel, oss-drivers, bridge,
bpf, linux-wireless, netfilter-devel, coreteam, torvalds,
jon.maddog.hall
In-Reply-To: <20260401074509.1897527-4-dwmw2@infradead.org>
On Wed, Apr 1, 2026 at 12:45 AM David Woodhouse <dwmw2@infradead.org> wrote:
>
> From: David Woodhouse <dwmw@amazon.co.uk>
>
> Wrap the IPv4-specific registrations in inet_init() with
> CONFIG_LEGACY_IP guards. When LEGACY_IP is disabled, the kernel
> will not:
> - Register the AF_INET socket family
> - Register the ETH_P_IP packet handler (ip_rcv)
> - Initialize ARP, ICMP, IGMP, or IPv4 routing
> - Register IPv4 protocol handlers (TCP/UDP/ICMP over IPv4)
> - Initialize IPv4 multicast routing, proc entries, or fragmentation
>
> The shared INET infrastructure (tcp_prot, udp_prot, tcp_init, etc.)
> remains initialized for use by IPv6.
>
...
>
> /* Add UDP-Lite (RFC 3828) */
> - udplite4_register();
> + if (IS_ENABLED(CONFIG_LEGACY_IP))
> + udplite4_register();
udplite has been removed in net-next.
I would think your patch series is net-next material ?
^ permalink raw reply
* [PATCH net-next v3 3/3] dpll: zl3073x: implement frequency monitoring
From: Ivan Vecera @ 2026-04-01 9:12 UTC (permalink / raw)
To: netdev
Cc: Petr Oros, Arkadiusz Kubalewski, David S. Miller, Donald Hunter,
Eric Dumazet, Jakub Kicinski, Jiri Pirko, Jonathan Corbet,
Michal Schmidt, Paolo Abeni, Prathosh Satish, Shuah Khan,
Simon Horman, Vadim Fedorenko, linux-doc, linux-kernel
In-Reply-To: <20260401091237.1071995-1-ivecera@redhat.com>
Extract common measurement latch logic from zl3073x_ref_ffo_update()
into a new zl3073x_ref_freq_meas_latch() helper and add
zl3073x_ref_freq_meas_update() that uses it to latch and read absolute
input reference frequencies in Hz.
Add meas_freq field to struct zl3073x_ref and the corresponding
zl3073x_ref_meas_freq_get() accessor. The measured frequencies are
updated periodically alongside the existing FFO measurements.
Add freq_monitor boolean to struct zl3073x_dpll and implement the
freq_monitor_set/get device callbacks to enable/disable frequency
monitoring via the DPLL netlink interface.
Implement measured_freq_get pin callback for input pins that returns the
measured input frequency in mHz.
Reviewed-by: Petr Oros <poros@redhat.com>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
Changes v2 -> v3:
- Changed measured_freq_get to return value in mHz
Changes v1 -> v2:
- Renamed actual-frequency to measured-frequency (Vadim)
---
drivers/dpll/zl3073x/core.c | 88 ++++++++++++++++++++++++++-----
drivers/dpll/zl3073x/dpll.c | 100 ++++++++++++++++++++++++++++++++++--
drivers/dpll/zl3073x/dpll.h | 2 +
drivers/dpll/zl3073x/ref.h | 14 +++++
4 files changed, 187 insertions(+), 17 deletions(-)
diff --git a/drivers/dpll/zl3073x/core.c b/drivers/dpll/zl3073x/core.c
index 6363002d48d46..cb47a5db061aa 100644
--- a/drivers/dpll/zl3073x/core.c
+++ b/drivers/dpll/zl3073x/core.c
@@ -632,22 +632,21 @@ int zl3073x_ref_phase_offsets_update(struct zl3073x_dev *zldev, int channel)
}
/**
- * zl3073x_ref_ffo_update - update reference fractional frequency offsets
+ * zl3073x_ref_freq_meas_latch - latch reference frequency measurements
* @zldev: pointer to zl3073x_dev structure
+ * @type: measurement type (ZL_REF_FREQ_MEAS_CTRL_*)
*
- * The function asks device to update fractional frequency offsets latch
- * registers the latest measured values, reads and stores them into
+ * The function waits for the previous measurement to finish, selects all
+ * references and requests a new measurement of the given type.
*
* Return: 0 on success, <0 on error
*/
static int
-zl3073x_ref_ffo_update(struct zl3073x_dev *zldev)
+zl3073x_ref_freq_meas_latch(struct zl3073x_dev *zldev, u8 type)
{
- int i, rc;
+ int rc;
- /* Per datasheet we have to wait for 'ref_freq_meas_ctrl' to be zero
- * to ensure that the measured data are coherent.
- */
+ /* Wait for previous measurement to finish */
rc = zl3073x_poll_zero_u8(zldev, ZL_REG_REF_FREQ_MEAS_CTRL,
ZL_REF_FREQ_MEAS_CTRL);
if (rc)
@@ -663,15 +662,64 @@ zl3073x_ref_ffo_update(struct zl3073x_dev *zldev)
if (rc)
return rc;
- /* Request frequency offset measurement */
- rc = zl3073x_write_u8(zldev, ZL_REG_REF_FREQ_MEAS_CTRL,
- ZL_REF_FREQ_MEAS_CTRL_REF_FREQ_OFF);
+ /* Request measurement */
+ rc = zl3073x_write_u8(zldev, ZL_REG_REF_FREQ_MEAS_CTRL, type);
if (rc)
return rc;
/* Wait for finish */
- rc = zl3073x_poll_zero_u8(zldev, ZL_REG_REF_FREQ_MEAS_CTRL,
- ZL_REF_FREQ_MEAS_CTRL);
+ return zl3073x_poll_zero_u8(zldev, ZL_REG_REF_FREQ_MEAS_CTRL,
+ ZL_REF_FREQ_MEAS_CTRL);
+}
+
+/**
+ * zl3073x_ref_freq_meas_update - update measured input reference frequencies
+ * @zldev: pointer to zl3073x_dev structure
+ *
+ * The function asks device to latch measured input reference frequencies
+ * and stores the results in the ref state.
+ *
+ * Return: 0 on success, <0 on error
+ */
+static int
+zl3073x_ref_freq_meas_update(struct zl3073x_dev *zldev)
+{
+ int i, rc;
+
+ rc = zl3073x_ref_freq_meas_latch(zldev, ZL_REF_FREQ_MEAS_CTRL_REF_FREQ);
+ if (rc)
+ return rc;
+
+ /* Read measured frequencies in Hz (unsigned 32-bit, LSB = 1 Hz) */
+ for (i = 0; i < ZL3073X_NUM_REFS; i++) {
+ u32 value;
+
+ rc = zl3073x_read_u32(zldev, ZL_REG_REF_FREQ(i), &value);
+ if (rc)
+ return rc;
+
+ zldev->ref[i].meas_freq = value;
+ }
+
+ return 0;
+}
+
+/**
+ * zl3073x_ref_ffo_update - update reference fractional frequency offsets
+ * @zldev: pointer to zl3073x_dev structure
+ *
+ * The function asks device to latch the latest measured fractional
+ * frequency offset values, reads and stores them into the ref state.
+ *
+ * Return: 0 on success, <0 on error
+ */
+static int
+zl3073x_ref_ffo_update(struct zl3073x_dev *zldev)
+{
+ int i, rc;
+
+ rc = zl3073x_ref_freq_meas_latch(zldev,
+ ZL_REF_FREQ_MEAS_CTRL_REF_FREQ_OFF);
if (rc)
return rc;
@@ -714,6 +762,20 @@ zl3073x_dev_periodic_work(struct kthread_work *work)
dev_warn(zldev->dev, "Failed to update phase offsets: %pe\n",
ERR_PTR(rc));
+ /* Update measured input reference frequencies if any DPLL has
+ * frequency monitoring enabled.
+ */
+ list_for_each_entry(zldpll, &zldev->dplls, list) {
+ if (zldpll->freq_monitor) {
+ rc = zl3073x_ref_freq_meas_update(zldev);
+ if (rc)
+ dev_warn(zldev->dev,
+ "Failed to update measured frequencies: %pe\n",
+ ERR_PTR(rc));
+ break;
+ }
+ }
+
/* Update references' fractional frequency offsets */
rc = zl3073x_ref_ffo_update(zldev);
if (rc)
diff --git a/drivers/dpll/zl3073x/dpll.c b/drivers/dpll/zl3073x/dpll.c
index a29f606318f6d..d788ca45a17e5 100644
--- a/drivers/dpll/zl3073x/dpll.c
+++ b/drivers/dpll/zl3073x/dpll.c
@@ -39,6 +39,7 @@
* @pin_state: last saved pin state
* @phase_offset: last saved pin phase offset
* @freq_offset: last saved fractional frequency offset
+ * @measured_freq: last saved measured frequency
*/
struct zl3073x_dpll_pin {
struct list_head list;
@@ -54,6 +55,7 @@ struct zl3073x_dpll_pin {
enum dpll_pin_state pin_state;
s64 phase_offset;
s64 freq_offset;
+ u32 measured_freq;
};
/*
@@ -202,6 +204,21 @@ zl3073x_dpll_input_pin_ffo_get(const struct dpll_pin *dpll_pin, void *pin_priv,
return 0;
}
+static int
+zl3073x_dpll_input_pin_measured_freq_get(const struct dpll_pin *dpll_pin,
+ void *pin_priv,
+ const struct dpll_device *dpll,
+ void *dpll_priv, u64 *measured_freq,
+ struct netlink_ext_ack *extack)
+{
+ struct zl3073x_dpll_pin *pin = pin_priv;
+
+ *measured_freq = pin->measured_freq;
+ *measured_freq *= DPLL_PIN_MEASURED_FREQUENCY_DIVIDER;
+
+ return 0;
+}
+
static int
zl3073x_dpll_input_pin_frequency_get(const struct dpll_pin *dpll_pin,
void *pin_priv,
@@ -1116,6 +1133,35 @@ zl3073x_dpll_phase_offset_monitor_set(const struct dpll_device *dpll,
return 0;
}
+static int
+zl3073x_dpll_freq_monitor_get(const struct dpll_device *dpll,
+ void *dpll_priv,
+ enum dpll_feature_state *state,
+ struct netlink_ext_ack *extack)
+{
+ struct zl3073x_dpll *zldpll = dpll_priv;
+
+ if (zldpll->freq_monitor)
+ *state = DPLL_FEATURE_STATE_ENABLE;
+ else
+ *state = DPLL_FEATURE_STATE_DISABLE;
+
+ return 0;
+}
+
+static int
+zl3073x_dpll_freq_monitor_set(const struct dpll_device *dpll,
+ void *dpll_priv,
+ enum dpll_feature_state state,
+ struct netlink_ext_ack *extack)
+{
+ struct zl3073x_dpll *zldpll = dpll_priv;
+
+ zldpll->freq_monitor = (state == DPLL_FEATURE_STATE_ENABLE);
+
+ return 0;
+}
+
static const struct dpll_pin_ops zl3073x_dpll_input_pin_ops = {
.direction_get = zl3073x_dpll_pin_direction_get,
.esync_get = zl3073x_dpll_input_pin_esync_get,
@@ -1123,6 +1169,7 @@ static const struct dpll_pin_ops zl3073x_dpll_input_pin_ops = {
.ffo_get = zl3073x_dpll_input_pin_ffo_get,
.frequency_get = zl3073x_dpll_input_pin_frequency_get,
.frequency_set = zl3073x_dpll_input_pin_frequency_set,
+ .measured_freq_get = zl3073x_dpll_input_pin_measured_freq_get,
.phase_offset_get = zl3073x_dpll_input_pin_phase_offset_get,
.phase_adjust_get = zl3073x_dpll_input_pin_phase_adjust_get,
.phase_adjust_set = zl3073x_dpll_input_pin_phase_adjust_set,
@@ -1151,6 +1198,8 @@ static const struct dpll_device_ops zl3073x_dpll_device_ops = {
.phase_offset_avg_factor_set = zl3073x_dpll_phase_offset_avg_factor_set,
.phase_offset_monitor_get = zl3073x_dpll_phase_offset_monitor_get,
.phase_offset_monitor_set = zl3073x_dpll_phase_offset_monitor_set,
+ .freq_monitor_get = zl3073x_dpll_freq_monitor_get,
+ .freq_monitor_set = zl3073x_dpll_freq_monitor_set,
.supported_modes_get = zl3073x_dpll_supported_modes_get,
};
@@ -1572,6 +1621,7 @@ zl3073x_dpll_pin_ffo_check(struct zl3073x_dpll_pin *pin)
struct zl3073x_dev *zldev = zldpll->dev;
const struct zl3073x_ref *ref;
u8 ref_id;
+ s64 ffo;
/* Get reference monitor status */
ref_id = zl3073x_input_pin_ref_get(pin->id);
@@ -1582,10 +1632,47 @@ zl3073x_dpll_pin_ffo_check(struct zl3073x_dpll_pin *pin)
return false;
/* Compare with previous value */
- if (pin->freq_offset != ref->ffo) {
+ ffo = zl3073x_ref_ffo_get(ref);
+ if (pin->freq_offset != ffo) {
dev_dbg(zldev->dev, "%s freq offset changed: %lld -> %lld\n",
- pin->label, pin->freq_offset, ref->ffo);
- pin->freq_offset = ref->ffo;
+ pin->label, pin->freq_offset, ffo);
+ pin->freq_offset = ffo;
+
+ return true;
+ }
+
+ return false;
+}
+
+/**
+ * zl3073x_dpll_pin_measured_freq_check - check for pin measured frequency
+ * change
+ * @pin: pin to check
+ *
+ * Check for the given pin's measured frequency change.
+ *
+ * Return: true on measured frequency change, false otherwise
+ */
+static bool
+zl3073x_dpll_pin_measured_freq_check(struct zl3073x_dpll_pin *pin)
+{
+ struct zl3073x_dpll *zldpll = pin->dpll;
+ struct zl3073x_dev *zldev = zldpll->dev;
+ const struct zl3073x_ref *ref;
+ u8 ref_id;
+ u32 freq;
+
+ if (!zldpll->freq_monitor)
+ return false;
+
+ ref_id = zl3073x_input_pin_ref_get(pin->id);
+ ref = zl3073x_ref_state_get(zldev, ref_id);
+
+ freq = zl3073x_ref_meas_freq_get(ref);
+ if (pin->measured_freq != freq) {
+ dev_dbg(zldev->dev, "%s measured freq changed: %u -> %u\n",
+ pin->label, pin->measured_freq, freq);
+ pin->measured_freq = freq;
return true;
}
@@ -1677,13 +1764,18 @@ zl3073x_dpll_changes_check(struct zl3073x_dpll *zldpll)
pin_changed = true;
}
- /* Check for phase offset and ffo change once per second */
+ /* Check for phase offset, ffo, and measured freq change
+ * once per second.
+ */
if (zldpll->check_count % 2 == 0) {
if (zl3073x_dpll_pin_phase_offset_check(pin))
pin_changed = true;
if (zl3073x_dpll_pin_ffo_check(pin))
pin_changed = true;
+
+ if (zl3073x_dpll_pin_measured_freq_check(pin))
+ pin_changed = true;
}
if (pin_changed)
diff --git a/drivers/dpll/zl3073x/dpll.h b/drivers/dpll/zl3073x/dpll.h
index 115ee4f67e7ab..434c32a7db123 100644
--- a/drivers/dpll/zl3073x/dpll.h
+++ b/drivers/dpll/zl3073x/dpll.h
@@ -15,6 +15,7 @@
* @id: DPLL index
* @check_count: periodic check counter
* @phase_monitor: is phase offset monitor enabled
+ * @freq_monitor: is frequency monitor enabled
* @ops: DPLL device operations for this instance
* @dpll_dev: pointer to registered DPLL device
* @tracker: tracking object for the acquired reference
@@ -28,6 +29,7 @@ struct zl3073x_dpll {
u8 id;
u8 check_count;
bool phase_monitor;
+ bool freq_monitor;
struct dpll_device_ops ops;
struct dpll_device *dpll_dev;
dpll_tracker tracker;
diff --git a/drivers/dpll/zl3073x/ref.h b/drivers/dpll/zl3073x/ref.h
index 06d8d4d97ea26..be16be20dbc7e 100644
--- a/drivers/dpll/zl3073x/ref.h
+++ b/drivers/dpll/zl3073x/ref.h
@@ -23,6 +23,7 @@ struct zl3073x_dev;
* @sync_ctrl: reference sync control
* @config: reference config
* @ffo: current fractional frequency offset
+ * @meas_freq: measured input frequency in Hz
* @mon_status: reference monitor status
*/
struct zl3073x_ref {
@@ -40,6 +41,7 @@ struct zl3073x_ref {
);
struct_group(stat, /* Status */
s64 ffo;
+ u32 meas_freq;
u8 mon_status;
);
};
@@ -68,6 +70,18 @@ zl3073x_ref_ffo_get(const struct zl3073x_ref *ref)
return ref->ffo;
}
+/**
+ * zl3073x_ref_meas_freq_get - get measured input frequency
+ * @ref: pointer to ref state
+ *
+ * Return: measured input frequency in Hz
+ */
+static inline u32
+zl3073x_ref_meas_freq_get(const struct zl3073x_ref *ref)
+{
+ return ref->meas_freq;
+}
+
/**
* zl3073x_ref_freq_get - get given input reference frequency
* @ref: pointer to ref state
--
2.52.0
^ permalink raw reply related
* [PATCH net-next v3 2/3] dpll: add frequency monitoring callback ops
From: Ivan Vecera @ 2026-04-01 9:12 UTC (permalink / raw)
To: netdev
Cc: Vadim Fedorenko, Arkadiusz Kubalewski, David S. Miller,
Donald Hunter, Eric Dumazet, Jakub Kicinski, Jiri Pirko,
Jonathan Corbet, Michal Schmidt, Paolo Abeni, Petr Oros,
Prathosh Satish, Shuah Khan, Simon Horman, linux-doc,
linux-kernel
In-Reply-To: <20260401091237.1071995-1-ivecera@redhat.com>
Add new callback operations for a dpll device:
- freq_monitor_get(..) - to obtain current state of frequency monitor
feature from dpll device,
- freq_monitor_set(..) - to allow feature configuration.
Add new callback operation for a dpll pin:
- measured_freq_get(..) - to obtain the measured frequency in mHz.
Obtain the feature state value using the get callback and provide it to
the user if the device driver implements callbacks. The measured_freq_get
pin callback is only invoked when the frequency monitor is enabled.
The freq_monitor_get device callback is required when measured_freq_get
is provided by the driver.
Execute the set callback upon user requests.
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
Changes v2 -> v3:
- Made freq_monitor_get required when measured_freq_get is present (Jakub)
Changes v1 -> v2:
- Renamed actual-frequency to measured-frequency (Vadim)
---
drivers/dpll/dpll_netlink.c | 92 +++++++++++++++++++++++++++++++++++++
include/linux/dpll.h | 10 ++++
2 files changed, 102 insertions(+)
diff --git a/drivers/dpll/dpll_netlink.c b/drivers/dpll/dpll_netlink.c
index 83cbd64abf5a4..576d0cd074bd4 100644
--- a/drivers/dpll/dpll_netlink.c
+++ b/drivers/dpll/dpll_netlink.c
@@ -175,6 +175,26 @@ dpll_msg_add_phase_offset_monitor(struct sk_buff *msg, struct dpll_device *dpll,
return 0;
}
+static int
+dpll_msg_add_freq_monitor(struct sk_buff *msg, struct dpll_device *dpll,
+ struct netlink_ext_ack *extack)
+{
+ const struct dpll_device_ops *ops = dpll_device_ops(dpll);
+ enum dpll_feature_state state;
+ int ret;
+
+ if (ops->freq_monitor_set && ops->freq_monitor_get) {
+ ret = ops->freq_monitor_get(dpll, dpll_priv(dpll),
+ &state, extack);
+ if (ret)
+ return ret;
+ if (nla_put_u32(msg, DPLL_A_FREQUENCY_MONITOR, state))
+ return -EMSGSIZE;
+ }
+
+ return 0;
+}
+
static int
dpll_msg_add_phase_offset_avg_factor(struct sk_buff *msg,
struct dpll_device *dpll,
@@ -400,6 +420,40 @@ static int dpll_msg_add_ffo(struct sk_buff *msg, struct dpll_pin *pin,
ffo);
}
+static int dpll_msg_add_measured_freq(struct sk_buff *msg, struct dpll_pin *pin,
+ struct dpll_pin_ref *ref,
+ struct netlink_ext_ack *extack)
+{
+ const struct dpll_device_ops *dev_ops = dpll_device_ops(ref->dpll);
+ const struct dpll_pin_ops *ops = dpll_pin_ops(ref);
+ struct dpll_device *dpll = ref->dpll;
+ enum dpll_feature_state state;
+ u64 measured_freq;
+ int ret;
+
+ if (!ops->measured_freq_get)
+ return 0;
+ if (WARN_ON(!dev_ops->freq_monitor_get))
+ return -EINVAL;
+ ret = dev_ops->freq_monitor_get(dpll, dpll_priv(dpll),
+ &state, extack);
+ if (ret)
+ return ret;
+ if (state == DPLL_FEATURE_STATE_DISABLE)
+ return 0;
+ ret = ops->measured_freq_get(pin, dpll_pin_on_dpll_priv(dpll, pin),
+ dpll, dpll_priv(dpll), &measured_freq,
+ extack);
+ if (ret)
+ return ret;
+ if (nla_put_64bit(msg, DPLL_A_PIN_MEASURED_FREQUENCY,
+ sizeof(measured_freq), &measured_freq,
+ DPLL_A_PIN_PAD))
+ return -EMSGSIZE;
+
+ return 0;
+}
+
static int
dpll_msg_add_pin_freq(struct sk_buff *msg, struct dpll_pin *pin,
struct dpll_pin_ref *ref, struct netlink_ext_ack *extack)
@@ -670,6 +724,9 @@ dpll_cmd_pin_get_one(struct sk_buff *msg, struct dpll_pin *pin,
if (ret)
return ret;
ret = dpll_msg_add_ffo(msg, pin, ref, extack);
+ if (ret)
+ return ret;
+ ret = dpll_msg_add_measured_freq(msg, pin, ref, extack);
if (ret)
return ret;
ret = dpll_msg_add_pin_esync(msg, pin, ref, extack);
@@ -722,6 +779,9 @@ dpll_device_get_one(struct dpll_device *dpll, struct sk_buff *msg,
if (ret)
return ret;
ret = dpll_msg_add_phase_offset_avg_factor(msg, dpll, extack);
+ if (ret)
+ return ret;
+ ret = dpll_msg_add_freq_monitor(msg, dpll, extack);
if (ret)
return ret;
@@ -948,6 +1008,32 @@ dpll_phase_offset_avg_factor_set(struct dpll_device *dpll, struct nlattr *a,
extack);
}
+static int
+dpll_freq_monitor_set(struct dpll_device *dpll, struct nlattr *a,
+ struct netlink_ext_ack *extack)
+{
+ const struct dpll_device_ops *ops = dpll_device_ops(dpll);
+ enum dpll_feature_state state = nla_get_u32(a), old_state;
+ int ret;
+
+ if (!(ops->freq_monitor_set && ops->freq_monitor_get)) {
+ NL_SET_ERR_MSG_ATTR(extack, a,
+ "dpll device not capable of frequency monitor");
+ return -EOPNOTSUPP;
+ }
+ ret = ops->freq_monitor_get(dpll, dpll_priv(dpll), &old_state,
+ extack);
+ if (ret) {
+ NL_SET_ERR_MSG(extack,
+ "unable to get current state of frequency monitor");
+ return ret;
+ }
+ if (state == old_state)
+ return 0;
+
+ return ops->freq_monitor_set(dpll, dpll_priv(dpll), state, extack);
+}
+
static int
dpll_pin_freq_set(struct dpll_pin *pin, struct nlattr *a,
struct netlink_ext_ack *extack)
@@ -1878,6 +1964,12 @@ dpll_set_from_nlattr(struct dpll_device *dpll, struct genl_info *info)
if (ret)
return ret;
break;
+ case DPLL_A_FREQUENCY_MONITOR:
+ ret = dpll_freq_monitor_set(dpll, a,
+ info->extack);
+ if (ret)
+ return ret;
+ break;
}
}
diff --git a/include/linux/dpll.h b/include/linux/dpll.h
index 2ce295b46b8cd..b7277a8b484d2 100644
--- a/include/linux/dpll.h
+++ b/include/linux/dpll.h
@@ -52,6 +52,12 @@ struct dpll_device_ops {
int (*phase_offset_avg_factor_get)(const struct dpll_device *dpll,
void *dpll_priv, u32 *factor,
struct netlink_ext_ack *extack);
+ int (*freq_monitor_set)(const struct dpll_device *dpll, void *dpll_priv,
+ enum dpll_feature_state state,
+ struct netlink_ext_ack *extack);
+ int (*freq_monitor_get)(const struct dpll_device *dpll, void *dpll_priv,
+ enum dpll_feature_state *state,
+ struct netlink_ext_ack *extack);
};
struct dpll_pin_ops {
@@ -110,6 +116,10 @@ struct dpll_pin_ops {
int (*ffo_get)(const struct dpll_pin *pin, void *pin_priv,
const struct dpll_device *dpll, void *dpll_priv,
s64 *ffo, struct netlink_ext_ack *extack);
+ int (*measured_freq_get)(const struct dpll_pin *pin, void *pin_priv,
+ const struct dpll_device *dpll,
+ void *dpll_priv, u64 *measured_freq,
+ struct netlink_ext_ack *extack);
int (*esync_set)(const struct dpll_pin *pin, void *pin_priv,
const struct dpll_device *dpll, void *dpll_priv,
u64 freq, struct netlink_ext_ack *extack);
--
2.52.0
^ permalink raw reply related
* [PATCH net-next v3 1/3] dpll: add frequency monitoring to netlink spec
From: Ivan Vecera @ 2026-04-01 9:12 UTC (permalink / raw)
To: netdev
Cc: Vadim Fedorenko, Arkadiusz Kubalewski, David S. Miller,
Donald Hunter, Eric Dumazet, Jakub Kicinski, Jiri Pirko,
Jonathan Corbet, Michal Schmidt, Paolo Abeni, Petr Oros,
Prathosh Satish, Shuah Khan, Simon Horman, linux-doc,
linux-kernel
In-Reply-To: <20260401091237.1071995-1-ivecera@redhat.com>
Add DPLL_A_FREQUENCY_MONITOR device attribute to allow control over
the frequency monitor feature. The attribute uses the existing
dpll_feature_state enum (enable/disable) and is present in both
device-get reply and device-set request.
Add DPLL_A_PIN_MEASURED_FREQUENCY pin attribute to expose the measured
input frequency in millihertz (mHz). The attribute is present in the
pin-get reply. Add DPLL_PIN_MEASURED_FREQUENCY_DIVIDER constant to
allow userspace to extract integer and fractional parts.
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
Changes v2 -> v3:
- Improved frequency-monitor doc wording (Jakub)
- Changed measured-frequency to mHz with divider constant (Jakub)
Changes v1 -> v2:
- Renamed actual-frequency to measured-frequency (Vadim)
---
Documentation/driver-api/dpll.rst | 20 +++++++++++++++
Documentation/netlink/specs/dpll.yaml | 35 +++++++++++++++++++++++++++
drivers/dpll/dpll_nl.c | 5 ++--
include/uapi/linux/dpll.h | 5 +++-
4 files changed, 62 insertions(+), 3 deletions(-)
diff --git a/Documentation/driver-api/dpll.rst b/Documentation/driver-api/dpll.rst
index 83118c728ed90..93c191b2d0898 100644
--- a/Documentation/driver-api/dpll.rst
+++ b/Documentation/driver-api/dpll.rst
@@ -250,6 +250,24 @@ in the ``DPLL_A_PIN_PHASE_OFFSET`` attribute.
``DPLL_A_PHASE_OFFSET_MONITOR`` attr state of a feature
=============================== ========================
+Frequency monitor
+=================
+
+Some DPLL devices may offer the capability to measure the actual
+frequency of all available input pins. The attribute and current feature state
+shall be included in the response message of the ``DPLL_CMD_DEVICE_GET``
+command for supported DPLL devices. In such cases, users can also control
+the feature using the ``DPLL_CMD_DEVICE_SET`` command by setting the
+``enum dpll_feature_state`` values for the attribute.
+Once enabled the measured input frequency for each input pin shall be
+returned in the ``DPLL_A_PIN_MEASURED_FREQUENCY`` attribute. The value
+is in millihertz (mHz), using ``DPLL_PIN_MEASURED_FREQUENCY_DIVIDER``
+as the divider.
+
+ =============================== ========================
+ ``DPLL_A_FREQUENCY_MONITOR`` attr state of a feature
+ =============================== ========================
+
Embedded SYNC
=============
@@ -411,6 +429,8 @@ according to attribute purpose.
``DPLL_A_PIN_STATE`` attr state of pin on the parent
pin
``DPLL_A_PIN_CAPABILITIES`` attr bitmask of pin capabilities
+ ``DPLL_A_PIN_MEASURED_FREQUENCY`` attr measured frequency of
+ an input pin in mHz
==================================== ==================================
==================================== =================================
diff --git a/Documentation/netlink/specs/dpll.yaml b/Documentation/netlink/specs/dpll.yaml
index 3dd48a32f7837..40465a3d7fc20 100644
--- a/Documentation/netlink/specs/dpll.yaml
+++ b/Documentation/netlink/specs/dpll.yaml
@@ -240,6 +240,20 @@ definitions:
integer part of a measured phase offset value.
Value of (DPLL_A_PHASE_OFFSET % DPLL_PHASE_OFFSET_DIVIDER) is a
fractional part of a measured phase offset value.
+ -
+ type: const
+ name: pin-measured-frequency-divider
+ value: 1000
+ doc: |
+ pin measured frequency divider allows userspace to calculate
+ a value of measured input frequency as a fractional value with
+ three digit decimal precision (millihertz).
+ Value of (DPLL_A_PIN_MEASURED_FREQUENCY /
+ DPLL_PIN_MEASURED_FREQUENCY_DIVIDER) is an integer part of
+ a measured frequency value.
+ Value of (DPLL_A_PIN_MEASURED_FREQUENCY %
+ DPLL_PIN_MEASURED_FREQUENCY_DIVIDER) is a fractional part of
+ a measured frequency value.
-
type: enum
name: feature-state
@@ -319,6 +333,13 @@ attribute-sets:
name: phase-offset-avg-factor
type: u32
doc: Averaging factor applied to calculation of reported phase offset.
+ -
+ name: frequency-monitor
+ type: u32
+ enum: feature-state
+ doc: Current or desired state of the frequency monitor feature.
+ If enabled, dpll device shall measure all currently available
+ inputs for their actual input frequency.
-
name: pin
enum-name: dpll_a_pin
@@ -456,6 +477,17 @@ attribute-sets:
Value is in PPT (parts per trillion, 10^-12).
Note: This attribute provides higher resolution than the standard
fractional-frequency-offset (which is in PPM).
+ -
+ name: measured-frequency
+ type: u64
+ doc: |
+ The measured frequency of the input pin in millihertz (mHz).
+ Value of (DPLL_A_PIN_MEASURED_FREQUENCY /
+ DPLL_PIN_MEASURED_FREQUENCY_DIVIDER) is an integer part (Hz)
+ of a measured frequency value.
+ Value of (DPLL_A_PIN_MEASURED_FREQUENCY %
+ DPLL_PIN_MEASURED_FREQUENCY_DIVIDER) is a fractional part
+ of a measured frequency value.
-
name: pin-parent-device
@@ -544,6 +576,7 @@ operations:
- type
- phase-offset-monitor
- phase-offset-avg-factor
+ - frequency-monitor
dump:
reply: *dev-attrs
@@ -563,6 +596,7 @@ operations:
- mode
- phase-offset-monitor
- phase-offset-avg-factor
+ - frequency-monitor
-
name: device-create-ntf
doc: Notification about device appearing
@@ -643,6 +677,7 @@ operations:
- esync-frequency-supported
- esync-pulse
- reference-sync
+ - measured-frequency
dump:
request:
diff --git a/drivers/dpll/dpll_nl.c b/drivers/dpll/dpll_nl.c
index a2b22d4921142..1e652340a5d73 100644
--- a/drivers/dpll/dpll_nl.c
+++ b/drivers/dpll/dpll_nl.c
@@ -43,11 +43,12 @@ static const struct nla_policy dpll_device_get_nl_policy[DPLL_A_ID + 1] = {
};
/* DPLL_CMD_DEVICE_SET - do */
-static const struct nla_policy dpll_device_set_nl_policy[DPLL_A_PHASE_OFFSET_AVG_FACTOR + 1] = {
+static const struct nla_policy dpll_device_set_nl_policy[DPLL_A_FREQUENCY_MONITOR + 1] = {
[DPLL_A_ID] = { .type = NLA_U32, },
[DPLL_A_MODE] = NLA_POLICY_RANGE(NLA_U32, 1, 2),
[DPLL_A_PHASE_OFFSET_MONITOR] = NLA_POLICY_MAX(NLA_U32, 1),
[DPLL_A_PHASE_OFFSET_AVG_FACTOR] = { .type = NLA_U32, },
+ [DPLL_A_FREQUENCY_MONITOR] = NLA_POLICY_MAX(NLA_U32, 1),
};
/* DPLL_CMD_PIN_ID_GET - do */
@@ -115,7 +116,7 @@ static const struct genl_split_ops dpll_nl_ops[] = {
.doit = dpll_nl_device_set_doit,
.post_doit = dpll_post_doit,
.policy = dpll_device_set_nl_policy,
- .maxattr = DPLL_A_PHASE_OFFSET_AVG_FACTOR,
+ .maxattr = DPLL_A_FREQUENCY_MONITOR,
.flags = GENL_ADMIN_PERM | GENL_CMD_CAP_DO,
},
{
diff --git a/include/uapi/linux/dpll.h b/include/uapi/linux/dpll.h
index de0005f28e5c5..871685f7c353b 100644
--- a/include/uapi/linux/dpll.h
+++ b/include/uapi/linux/dpll.h
@@ -191,7 +191,8 @@ enum dpll_pin_capabilities {
DPLL_PIN_CAPABILITIES_STATE_CAN_CHANGE = 4,
};
-#define DPLL_PHASE_OFFSET_DIVIDER 1000
+#define DPLL_PHASE_OFFSET_DIVIDER 1000
+#define DPLL_PIN_MEASURED_FREQUENCY_DIVIDER 1000
/**
* enum dpll_feature_state - Allow control (enable/disable) and status checking
@@ -218,6 +219,7 @@ enum dpll_a {
DPLL_A_CLOCK_QUALITY_LEVEL,
DPLL_A_PHASE_OFFSET_MONITOR,
DPLL_A_PHASE_OFFSET_AVG_FACTOR,
+ DPLL_A_FREQUENCY_MONITOR,
__DPLL_A_MAX,
DPLL_A_MAX = (__DPLL_A_MAX - 1)
@@ -254,6 +256,7 @@ enum dpll_a_pin {
DPLL_A_PIN_REFERENCE_SYNC,
DPLL_A_PIN_PHASE_ADJUST_GRAN,
DPLL_A_PIN_FRACTIONAL_FREQUENCY_OFFSET_PPT,
+ DPLL_A_PIN_MEASURED_FREQUENCY,
__DPLL_A_PIN_MAX,
DPLL_A_PIN_MAX = (__DPLL_A_PIN_MAX - 1)
--
2.52.0
^ permalink raw reply related
* [PATCH net-next v3 0/3] dpll: add frequency monitoring feature
From: Ivan Vecera @ 2026-04-01 9:12 UTC (permalink / raw)
To: netdev
Cc: Arkadiusz Kubalewski, David S. Miller, Donald Hunter,
Eric Dumazet, Jakub Kicinski, Jiri Pirko, Jonathan Corbet,
Michal Schmidt, Paolo Abeni, Petr Oros, Prathosh Satish,
Shuah Khan, Simon Horman, Vadim Fedorenko, linux-doc,
linux-kernel
This series adds support for monitoring the measured input frequency
of DPLL input pins via the DPLL netlink interface.
Some DPLL devices can measure the actual frequency being received on
input pins. The approach mirrors the existing phase-offset-monitor
feature: a device-level attribute (DPLL_A_FREQUENCY_MONITOR) enables
or disables monitoring, and a per-pin attribute
(DPLL_A_PIN_MEASURED_FREQUENCY) exposes the measured frequency in
millihertz (mHz) when monitoring is enabled.
Patch 1 adds the new attributes to the DPLL netlink spec (dpll.yaml),
the DPLL_PIN_MEASURED_FREQUENCY_DIVIDER constant, regenerates the
auto-generated UAPI header and netlink policy, and updates
Documentation/driver-api/dpll.rst.
Patch 2 adds the callback operations (freq_monitor_get/set for
devices, measured_freq_get for pins) and the corresponding netlink
GET/SET handlers in the DPLL core. The core only invokes
measured_freq_get when the frequency monitor is enabled on the parent
device. The freq_monitor_get callback is required when measured_freq_get
is provided.
Patch 3 implements the feature in the ZL3073x driver by extracting
a common measurement latch helper from the existing FFO update path,
adding a frequency measurement function, and wiring up the new
callbacks.
Changes v2 -> v3:
- Improved frequency-monitor doc wording (Jakub)
- Changed measured-frequency to mHz with divider constant (Jakub)
- Made freq_monitor_get required when measured_freq_get is present (Jakub)
Changes v1 -> v2:
- Renamed actual-frequency to measured-frequency (Vadim)
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Ivan Vecera (3):
dpll: add frequency monitoring to netlink spec
dpll: add frequency monitoring callback ops
dpll: zl3073x: implement frequency monitoring
Documentation/driver-api/dpll.rst | 20 ++++++
Documentation/netlink/specs/dpll.yaml | 35 +++++++++
drivers/dpll/dpll_netlink.c | 92 ++++++++++++++++++++++++
drivers/dpll/dpll_nl.c | 5 +-
drivers/dpll/zl3073x/core.c | 88 +++++++++++++++++++----
drivers/dpll/zl3073x/dpll.c | 100 ++++++++++++++++++++++++--
drivers/dpll/zl3073x/dpll.h | 2 +
drivers/dpll/zl3073x/ref.h | 14 ++++
include/linux/dpll.h | 10 +++
include/uapi/linux/dpll.h | 5 +-
10 files changed, 351 insertions(+), 20 deletions(-)
--
2.52.0
^ permalink raw reply
* Re: [PATCH 6/6] net: Warn when processes listen on AF_INET sockets
From: Eric Dumazet @ 2026-04-01 9:11 UTC (permalink / raw)
To: David Woodhouse
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch,
Andrew Lunn, David S. Miller, Jakub Kicinski, Paolo Abeni,
Simon Horman, Nikolay Aleksandrov, Ido Schimmel, Martin KaFai Lau,
Daniel Borkmann, John Fastabend, Stanislav Fomichev,
Alexei Starovoitov, Andrii Nakryiko, Eduard Zingerman, Song Liu,
Yonghong Song, KP Singh, Hao Luo, Jiri Olsa, Kuniyuki Iwashima,
Willem de Bruijn, David Ahern, Neal Cardwell, Johannes Berg,
Pablo Neira Ayuso, Florian Westphal, Phil Sutter, Guillaume Nault,
David Woodhouse, Kees Cook, Alexei Lazar, Gal Pressman,
Paul Moore, netdev, linux-rdma, linux-kernel, oss-drivers, bridge,
bpf, linux-wireless, netfilter-devel, coreteam, torvalds,
jon.maddog.hall
In-Reply-To: <20260401074509.1897527-7-dwmw2@infradead.org>
On Wed, Apr 1, 2026 at 12:45 AM David Woodhouse <dwmw2@infradead.org> wrote:
>
> From: David Woodhouse <dwmw@amazon.co.uk>
>
> There is no need to listen on AF_INET sockets; a modern application can
> listen on IPv6 (without IPV6_V6ONLY) and will accept connections from
> the 20th century via IPv4-mapped addresses (::ffff:x.x.x.x) on the IPv6
> socket.
>
> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
> ---
> net/ipv4/af_inet.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> index dc358faa1647..3838782a8437 100644
> --- a/net/ipv4/af_inet.c
> +++ b/net/ipv4/af_inet.c
> @@ -240,6 +240,9 @@ int inet_listen(struct socket *sock, int backlog)
> struct sock *sk = sock->sk;
> int err = -EINVAL;
>
> + pr_warn_once("process '%s' (pid %d) is listening on an AF_INET socket. Consider using AF_INET6 with IPV6_V6ONLY=0 instead.\n",
> + current->comm, task_pid_nr(current));
> +
Some kernels are built without CONFIG_IPV6, so this warning would be
quite misleading.
^ permalink raw reply
* Re: [PATCH 1/1] net: ipv6: flowlabel: defer exclusive option free until RCU teardown
From: Eric Dumazet @ 2026-04-01 9:02 UTC (permalink / raw)
To: Yuan Tan
Cc: kuniyu, Ren Wei, security, netdev, davem, dsahern, kuba, pabeni,
horms, afaerber, mani, yoshfuji, yifanwucs, tomapufckgml, bird,
enjou1224z, zcliangcn, Greg KH
In-Reply-To: <7c26a74d-90c5-4520-a10a-22f06e098b86@gmail.com>
On Wed, Apr 1, 2026 at 12:05 AM Yuan Tan <yuantan098@gmail.com> wrote:
>
>
> On 3/31/2026 6:05 PM, Eric Dumazet wrote:
> > On Tue, Mar 31, 2026 at 5:41 PM Yuan Tan <yuantan098@gmail.com> wrote:
> >>
> >> On 3/31/2026 1:52 AM, Eric Dumazet wrote:
> >>> On Tue, Mar 31, 2026 at 1:34 AM Ren Wei <n05ec@lzu.edu.cn> wrote:
> >>>> From: Zhengchuan Liang <zcliangcn@gmail.com>
> >>>>
> >>>> `ip6fl_seq_show()` walks the global flowlabel hash under the seq-file
> >>>> RCU read-side lock and prints `fl->opt->opt_nflen` when an option block
> >>>> is present.
> >>> Some points :
> >>>
> >>> Please do not CC security@ if you submit a public patch, there is
> >>> absolutely no reason for it.
> >>>
> >>> Please do not resend the same version within 24 hours; this creates noise.
> >>> Your patch wasn't lost; we have many patch reviews and similar bugs to address.
> >>>
> >>> Thank you.
> >> We sincerely apologize for the confusion caused by our previous email. Previously, when we sent reports and patches to the security list, we were advised that patches should be submitted to netdev@ for public review. To follow this, we are now sending the full vulnerability details to security@ while additionally submitting the patches to netdev@. Please let us know if this is the correct way to handle such cases.
> > When/If an issue and a patch is sent publicly, security@ involvement
> > ends. netdev maintainers take over.
> >
> > Thus there is no point CCing this list of security officers, which is
> > currently flooded by many LLM-based findings.
> > Please help them by keeping their inbox a bit saner.
> We would like to standardize our workflow to ensure it aligns with
> community expectations. We've checked the maillist and netdev docs for
> these details but found no clear answers. Could you please clarify which of
> the following is preferred?
>
> Option 1: Send the security report to security@ and submit the patches
> directly to the subsystem mailing list without CC security@.
>
> Option 2: Send both the report and the patches to security@ for an initial
> review. After approval, re-send the patches to the subsystem mailing list.
>
> For Option 1, I have hread that there are bots on the public lists to help
> with the review. The Option 2 feels slightly redundant and might cause
> confusion. We are open to any other workflow that the community prefers.
>
> We are wondering if it's better to send the PoC and detailed analysis
> directly to netdev@ for bugs we deem to have low exploitability, which
> would help minimize the burden on the security@ team. However, these bugs
> are still triggerable by unprivileged users, we are concerned that posting
> full PoC to a public mailing list might be inappropriate or risky.
> >> Regarding the CC list, could you provide further guidance on who we should include? Currently, we are CCing everyone suggested by get_maintainer.pl because we previously received feedback about missing relevant maintainers. For public mailing lists, we should only including netdev@. Should we be more selective?
> > Yes, folks that are interesting into following netdev changes are
> > subscribed to netdev@ mailing list.
> >
> > Unless a patch touches non-networking parts and requires approval from
> > other branch maintainers, there is no
> > point CCing other lists.
> Thank you for your advice. We will no longer CC individual maintainers on
> patches sent to netdev.
>
> Regarding security reports, however, we had previously been advised to CC
> more people to avoid manual forwarding.
>
> To be honest, we are a bit confused by the conflicting guidance we've
> received. We sincerely want to establish a standardized process for our
> future contributions to make everyone happy.
>
> >> Finally, regarding our tags, our team has a clear division of labor—some focus on finding vulnerabilities, others on fixing them, followed by an internal review and testing before a dedicated member handles community outreach.
> >>
> > You included 8 tags, this seems a bit too much for such a small patch.
> CC Greg here, as he knows a bit about our team's background.
>
> Our team has developed a tool that found hundreds of non-root bugs with
> PoCs. We want to ensure these are fixed properly and quickly rather than
> dumping reports onto the mailing list and hoping for others to find the
> time to fix. So we have organized a group of promising students. As some of
> them are new to kernel development, we have been providing hands-on
> mentorship to guide them through the process.
>
> Regarding credit attribution: Yuan, Yifan, Jufei, and Xin were all
> instrumental in the tool's design and implementation, so we listed them
> with Reported-by tags. Xin provided the funding and led the fixing team, so
> we included a Suggested-by tag for him (though this could be changed to
> Reported-by as well). Then after including the patch author, this naturally
> results in five tags.
>
>
> As for using a designated sender to submit these patches, it's because
> using Gmail with git send-email is difficult in China and the university
> email servers prohibit the use of the SMTP protocol. Therefore, we had to
> apply for a separate account specifically with SMTP permissions to submit
> patches.
>
> We fully respect the maintainers' discretion in this matter. If the current
> tags are still considered unacceptable, we will make the necessary internal
> adjustments.
Again, no need for all this, I already gave a 'Reviewed-by', I was not
saying it was unaccptable.
Oh well.
^ 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