* Re: [PATCH RFC v3 09/11] platform/x86: ideapad-laptop: Decouple hardware & classdev brightness for keyboard backlight
From: Ilpo Järvinen @ 2026-07-21 17:08 UTC (permalink / raw)
To: Rong Zhang
Cc: Lee Jones, Pavel Machek, Jonathan Corbet, Shuah Khan,
Thomas Weißschuh, Benson Leung, Guenter Roeck,
Marek Behún, Mark Pearson, Derek J. Clark, Hans de Goede,
Ike Panhc, Andrew Lunn, Jakub Kicinski, Vishnu Sankar,
Vishnu Sankar, linux-leds, Netdev, linux-doc, LKML,
chrome-platform, platform-driver-x86
In-Reply-To: <20260719-leds-trigger-hw-changed-v3-9-5fb55722e36e@rong.moe>
On Sun, 19 Jul 2026, Rong Zhang wrote:
> Some recent models come with an ambient light sensor (ALS). On these
> models, their EC will automatically set the keyboard backlight to an
> appropriate brightness when the effective "hardware brightness" is 3.
> "Hardware brightness" can't be perfectly mapped to an LED classdev
> brightness, but the EC does use this predefined brightness value to
> represent auto mode.
>
> Currently, the code processing keyboard backlight is coupled with LED
> classdev, making it hard to expose the auto brightness (ALS) mode to the
> userspace.
>
> As the first step toward the goal, decouple hardware brightness from LED
> classdev brightness, and update comments about corresponding backlight
> modes.
>
> Since upcoming changes will heavily rely on kbd_bl.last_hw_brightness,
> also convert it into an atomic_t to prevent potential race conditions.
>
> To minimalize the diff set in upcoming changes, a trivial refactor
> also converts the initialization path into another equivalent form.
>
> Signed-off-by: Rong Zhang <i@rong.moe>
> ---
> drivers/platform/x86/lenovo/Kconfig | 1 +
> drivers/platform/x86/lenovo/ideapad-laptop.c | 144 ++++++++++++++++++---------
> 2 files changed, 100 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/platform/x86/lenovo/Kconfig b/drivers/platform/x86/lenovo/Kconfig
> index 4443f40ef8aa..e92b1e900795 100644
> --- a/drivers/platform/x86/lenovo/Kconfig
> +++ b/drivers/platform/x86/lenovo/Kconfig
> @@ -16,6 +16,7 @@ config IDEAPAD_LAPTOP
> select INPUT_SPARSEKMAP
> select NEW_LEDS
> select LEDS_CLASS
> + select LEDS_TRIGGERS
> help
> This is a driver for Lenovo IdeaPad netbooks contains drivers for
> rfkill switch, hotkey, fan control and backlight control.
> diff --git a/drivers/platform/x86/lenovo/ideapad-laptop.c b/drivers/platform/x86/lenovo/ideapad-laptop.c
> index 4fbc904f1fc3..5aa2fedb8472 100644
> --- a/drivers/platform/x86/lenovo/ideapad-laptop.c
> +++ b/drivers/platform/x86/lenovo/ideapad-laptop.c
> @@ -9,6 +9,7 @@
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> #include <linux/acpi.h>
> +#include <linux/atomic.h>
> #include <linux/backlight.h>
> #include <linux/bitfield.h>
> #include <linux/bitops.h>
> @@ -134,10 +135,31 @@ enum {
> };
>
> /*
> - * These correspond to the number of supported states - 1
> - * Future keyboard types may need a new system, if there's a collision
> - * KBD_BL_TRISTATE_AUTO has no way to report or set the auto state
> - * so it effectively has 3 states, but needs to handle 4
> + * The enumeration has two purposes:
> + * - as an internal identifier for all known types of keyboard backlight
> + * - as a mandatory parameter of the KBLC command
> + *
> + * For each type, the hardware brightness values are defined as follows:
> + * +--------------------------+----------+-----+------+------+
> + * | Hardware brightness | 0 | 1 | 2 | 3 |
> + * | Type | | | | |
> + * +--------------------------+----------+-----+------+------+
> + * | KBD_BL_STANDARD | off | on | N/A | N/A |
> + * +--------------------------+----------+-----+------+------+
> + * | KBD_BL_TRISTATE | off | low | high | N/A |
> + * +--------------------------+----------+-----+------+------+
> + * | KBD_BL_TRISTATE_AUTO | off | low | high | auto |
> + * +--------------------------+----------+-----+------+------+
> + *
> + * We map LED classdev brightness for KBD_BL_TRISTATE_AUTO as follows:
> + * +--------------------------+----------+-----+------+
> + * | LED classdev brightness | 0 | 1 | 2 |
> + * | Operation | | | |
> + * +--------------------------+----------+-----+------+
> + * | Read | off/auto | low | high |
> + * +--------------------------+----------+-----+------+
> + * | Write | off | low | high |
> + * +--------------------------+----------+-----+------+
> */
> enum {
> KBD_BL_STANDARD = 1,
> @@ -145,6 +167,8 @@ enum {
> KBD_BL_TRISTATE_AUTO = 3,
> };
>
> +#define KBD_BL_AUTO_MODE_HW_BRIGHTNESS 3
> +
> #define KBD_BL_QUERY_TYPE 0x1
> #define KBD_BL_TRISTATE_TYPE 0x5
> #define KBD_BL_TRISTATE_AUTO_TYPE 0x7
> @@ -203,7 +227,7 @@ struct ideapad_private {
> bool initialized;
> int type;
> struct led_classdev led;
> - unsigned int last_brightness;
> + atomic_t last_hw_brightness;
> } kbd_bl;
> struct {
> bool initialized;
> @@ -1592,7 +1616,24 @@ static int ideapad_kbd_bl_check_tristate(int type)
> return (type == KBD_BL_TRISTATE) || (type == KBD_BL_TRISTATE_AUTO);
> }
>
> -static int ideapad_kbd_bl_brightness_get(struct ideapad_private *priv)
> +static int ideapad_kbd_bl_brightness_parse(struct ideapad_private *priv, int hw_brightness)
> +{
> + /* Off, low or high */
> + if (hw_brightness <= priv->kbd_bl.led.max_brightness)
> + return hw_brightness;
> +
> + /* Auto (controlled by EC according to ALS), report as off */
> + if (priv->kbd_bl.type == KBD_BL_TRISTATE_AUTO &&
> + hw_brightness == KBD_BL_AUTO_MODE_HW_BRIGHTNESS)
> + return 0;
> +
> + /* Unknown value */
> + dev_warn(&priv->platform_device->dev,
Please (finally) add the include.
> + "Unknown keyboard backlight value: %d", hw_brightness);
> + return -EINVAL;
> +}
> +
> +static int ideapad_kbd_bl_hw_brightness_get(struct ideapad_private *priv)
> {
> unsigned long value;
> int err;
> @@ -1606,21 +1647,7 @@ static int ideapad_kbd_bl_brightness_get(struct ideapad_private *priv)
> if (err)
> return err;
>
> - /* Convert returned value to brightness level */
> - value = FIELD_GET(KBD_BL_GET_BRIGHTNESS, value);
> -
> - /* Off, low or high */
> - if (value <= priv->kbd_bl.led.max_brightness)
> - return value;
> -
> - /* Auto, report as off */
> - if (value == priv->kbd_bl.led.max_brightness + 1)
> - return 0;
> -
> - /* Unknown value */
> - dev_warn(&priv->platform_device->dev,
> - "Unknown keyboard backlight value: %lu", value);
> - return -EINVAL;
> + return FIELD_GET(KBD_BL_GET_BRIGHTNESS, value);
> }
>
> err = eval_hals(priv->adev->handle, &value);
> @@ -1630,6 +1657,16 @@ static int ideapad_kbd_bl_brightness_get(struct ideapad_private *priv)
> return !!test_bit(HALS_KBD_BL_STATE_BIT, &value);
> }
>
> +static int ideapad_kbd_bl_brightness_get(struct ideapad_private *priv)
> +{
> + int hw_brightness = ideapad_kbd_bl_hw_brightness_get(priv);
> +
> + if (hw_brightness < 0)
> + return hw_brightness;
> +
> + return ideapad_kbd_bl_brightness_parse(priv, hw_brightness);
> +}
> +
> static enum led_brightness ideapad_kbd_bl_led_cdev_brightness_get(struct led_classdev *led_cdev)
> {
> struct ideapad_private *priv = container_of(led_cdev, struct ideapad_private, kbd_bl.led);
> @@ -1637,32 +1674,37 @@ static enum led_brightness ideapad_kbd_bl_led_cdev_brightness_get(struct led_cla
> return ideapad_kbd_bl_brightness_get(priv);
> }
>
> -static int ideapad_kbd_bl_brightness_set(struct ideapad_private *priv, unsigned int brightness)
> +static int ideapad_kbd_bl_hw_brightness_set(struct ideapad_private *priv, int hw_brightness)
> {
> - int err;
> unsigned long value;
> int type = priv->kbd_bl.type;
> + int err;
>
> if (ideapad_kbd_bl_check_tristate(type)) {
> - if (brightness > priv->kbd_bl.led.max_brightness)
> - return -EINVAL;
> -
> - value = FIELD_PREP(KBD_BL_SET_BRIGHTNESS, brightness) |
> + value = FIELD_PREP(KBD_BL_SET_BRIGHTNESS, hw_brightness) |
> FIELD_PREP(KBD_BL_COMMAND_TYPE, type) |
> KBD_BL_COMMAND_SET;
> err = exec_kblc(priv->adev->handle, value);
> } else {
> - err = exec_sals(priv->adev->handle, brightness ? SALS_KBD_BL_ON : SALS_KBD_BL_OFF);
> + value = hw_brightness ? SALS_KBD_BL_ON : SALS_KBD_BL_OFF;
> + err = exec_sals(priv->adev->handle, value);
> }
> -
> if (err)
> return err;
>
> - priv->kbd_bl.last_brightness = brightness;
> + atomic_set(&priv->kbd_bl.last_hw_brightness, hw_brightness);
>
> return 0;
> }
>
> +static int ideapad_kbd_bl_brightness_set(struct ideapad_private *priv, int brightness)
> +{
> + if (brightness > priv->kbd_bl.led.max_brightness)
> + return -EINVAL;
> +
> + return ideapad_kbd_bl_hw_brightness_set(priv, brightness);
> +}
> +
> static int ideapad_kbd_bl_led_cdev_brightness_set(struct led_classdev *led_cdev,
> enum led_brightness brightness)
> {
> @@ -1673,26 +1715,29 @@ static int ideapad_kbd_bl_led_cdev_brightness_set(struct led_classdev *led_cdev,
>
> static void ideapad_kbd_bl_notify(struct ideapad_private *priv)
> {
> - int brightness;
> + int hw_brightness, brightness, last_hw_brightness;
>
> if (!priv->kbd_bl.initialized)
> return;
>
> - brightness = ideapad_kbd_bl_brightness_get(priv);
> - if (brightness < 0)
> + hw_brightness = ideapad_kbd_bl_hw_brightness_get(priv);
> + if (hw_brightness < 0)
> return;
>
> - if (brightness == priv->kbd_bl.last_brightness)
> - return;
> + brightness = ideapad_kbd_bl_brightness_parse(priv, hw_brightness);
> + if (brightness < 0)
> + return; /* Reject insane values early. */
>
> - priv->kbd_bl.last_brightness = brightness;
> + last_hw_brightness = atomic_xchg(&priv->kbd_bl.last_hw_brightness, hw_brightness);
> + if (hw_brightness == last_hw_brightness)
> + return;
>
> led_classdev_notify_brightness_hw_changed(&priv->kbd_bl.led, brightness);
> }
>
> static int ideapad_kbd_bl_init(struct ideapad_private *priv)
> {
> - int brightness, err;
> + int hw_brightness, err;
>
> if (!priv->features.kbd_bl)
> return -ENODEV;
> @@ -1700,21 +1745,30 @@ static int ideapad_kbd_bl_init(struct ideapad_private *priv)
> if (WARN_ON(priv->kbd_bl.initialized))
> return -EEXIST;
>
> - if (ideapad_kbd_bl_check_tristate(priv->kbd_bl.type))
> - priv->kbd_bl.led.max_brightness = 2;
> - else
> - priv->kbd_bl.led.max_brightness = 1;
> + hw_brightness = ideapad_kbd_bl_hw_brightness_get(priv);
> + if (hw_brightness < 0)
> + return hw_brightness;
>
> - brightness = ideapad_kbd_bl_brightness_get(priv);
> - if (brightness < 0)
> - return brightness;
> + atomic_set(&priv->kbd_bl.last_hw_brightness, hw_brightness);
>
> - priv->kbd_bl.last_brightness = brightness;
> priv->kbd_bl.led.name = "platform::" LED_FUNCTION_KBD_BACKLIGHT;
> priv->kbd_bl.led.brightness_get = ideapad_kbd_bl_led_cdev_brightness_get;
> priv->kbd_bl.led.brightness_set_blocking = ideapad_kbd_bl_led_cdev_brightness_set;
> priv->kbd_bl.led.flags = LED_BRIGHT_HW_CHANGED | LED_RETAIN_AT_SHUTDOWN;
>
> + switch (priv->kbd_bl.type) {
> + case KBD_BL_TRISTATE_AUTO:
> + case KBD_BL_TRISTATE:
> + priv->kbd_bl.led.max_brightness = 2;
> + break;
> + case KBD_BL_STANDARD:
> + priv->kbd_bl.led.max_brightness = 1;
> + break;
> + default:
> + /* This has already been validated by ideapad_check_features(). */
> + unreachable();
Please add include.
> + }
> +
> err = led_classdev_register(&priv->platform_device->dev, &priv->kbd_bl.led);
> if (err)
> return err;
>
>
--
i.
^ permalink raw reply
* Re: [PATCH v5 2/3] drm/xe/xe_ras: Report correctable error events to userspace
From: Raag Jadav @ 2026-07-21 17:08 UTC (permalink / raw)
To: Tauro, Riana
Cc: intel-xe, dri-devel, netdev, aravind.iddamsetty, anshuman.gupta,
rodrigo.vivi, joonas.lahtinen, kuba, simona.vetter, airlied,
pratik.bari, joshua.santosh.ranjan, ashwin.kumar.kulkarni,
shubham.kumar, ravi.kishore.koppuravuri, maarten.lankhorst,
mallesh.koujalagi, soham.purkait, Michal Wajdeczko
In-Reply-To: <0e842368-3bbf-436e-839d-cc7fec29b0cb@intel.com>
On Tue, Jul 21, 2026 at 06:52:51PM +0530, Tauro, Riana wrote:
> On 21-07-2026 14:07, Raag Jadav wrote:
> > On Mon, Jul 20, 2026 at 01:52:11PM +0530, Riana Tauro wrote:
> > > When an interrupt is received indicating that error counter has crossed
> > > its threshold, read the current counter value and deliver a drm_ras error
> > > event to userspace for each affected component.
> > >
> > > To avoid sending duplicate events when the same component appears multiple
> > > times in the response. Send the error-event once per component.
> > ...
> >
> > > +void xe_drm_ras_event(struct xe_device *xe, u8 component, u8 severity, u32 value)
> > > +{
> > > + struct xe_drm_ras *ras = &xe->ras;
> > > + struct xe_drm_ras_counter *info;
> > > + struct drm_ras_node *node;
> > > + int ret;
> > > +
> > > + /* Event is supported only if drm_ras is enabled */
> > > + if (!xe->info.has_drm_ras)
> > > + return;
> > > +
> > > + if (component >= DRM_XE_RAS_ERR_COMP_MAX) {
> > IIUC this is error_id and should be validated against first/last counter
> > range in drm_ras layer (similar to registration code).
>
> This should be done before because we are accessing the nodes here.
> The nodes anyway won't be available in xe_drm_ras if not registered with
> drm_ras.
Yes. We get the node from severity which we already validate here, but
error_counter_range is the property of the node and unrelated to xe.
Even if you prefer it here, these checks must be in core functions to
make sure they are not abused.
> > > + drm_warn(&xe->drm, "unsupported component %u\n", component);
> > > + return;
> > > + }
> > > +
> > > + if (severity >= DRM_XE_RAS_ERR_SEV_MAX) {
> > > + drm_warn(&xe->drm, "unsupported severity %u\n", severity);
> > > + return;
> > > + }
> > > +
> > > + node = &ras->node[severity];
> > > + info = ras->info[severity];
> > > +
> > > + if (!info || !info[component].name)
> > > + return;
> > > +
> > > + ret = drm_ras_nl_error_event(node, component, info[component].name, value);
> > > + if (ret)
> > > + drm_err_ratelimited(&xe->drm, "drm_ras error-event failed: %d for %s %s\n", ret,
> > > + info[component].name, error_severity[severity]);
> > > +}
> > ...
> >
> > > +static void ras_send_error_event(struct xe_device *xe, u8 severity, u8 component)
> > > +{
> > > + struct xe_ras_error_class counter = {0};
> > > + u8 drm_severity, drm_component;
> > > + u32 value;
> > > + int ret;
> > > +
> > > + counter.common.severity = severity;
> > > + counter.common.component = component;
> > > +
> > > + ret = get_counter(xe, &counter, &value);
> > > + if (ret)
> > > + return;
> > > +
> > > + drm_severity = xe_to_drm_ras_severity(severity);
> > > + drm_component = xe_to_drm_ras_component(component);
> > > +
> > > + xe_drm_ras_event(xe, drm_component, drm_severity, value);
> > > +}
> > This entire function can be dropped. See below.
>
> We don't need to drop function. It's cleaner to have it in the function
> than repeating it twice.
I thought we'd lay the groundwork for cper which'll also need get_counter()
in the same path, but upto you.
Raag
^ permalink raw reply
* Re: [PATCH net v3] tun/tap & vhost-net: make qdisc backpressure opt-in via IFF_BACKPRESSURE
From: Jakub Kicinski @ 2026-07-21 17:07 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Simon Schippers, Willem de Bruijn, Jason Wang, David S . Miller,
Eric Dumazet, Paolo Abeni, netdev, Simon Horman, Jonathan Corbet,
Shuah Khan, Andrew Lunn, Tim Gebauer, Brett Sheffield, linux-doc,
linux-kernel
In-Reply-To: <20260721105853-mutt-send-email-mst@kernel.org>
On Tue, 21 Jul 2026 10:59:52 -0400 Michael S. Tsirkin wrote:
> > > I prefer applying it, but you maintainers must decide that.
> >
> > Hi,
> > just a gentle ping.
> > Has there been any decision on this patch?
>
> Hi netdev maintainers. Given there's a perf regression otherwise,
> we should either take this or revert the original and reapply
> in next.
Revert, please. We were AFK and are now working thru a backlog
of 1k patches. The new IFF_* flag needs scrutiny we can't afford
at present.
^ permalink raw reply
* Re: [PATCH net v3 1/2] pds_core: fix deadlock between reset thread and remove
From: Simon Horman @ 2026-07-21 16:55 UTC (permalink / raw)
To: nikhil.rao
Cc: Simon Horman, netdev, kuba, brett.creeley, eric.joyner,
andrew+netdev, davem, edumazet, pabeni
In-Reply-To: <20260714180223.1642792-2-nikhil.rao@amd.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.
https://sashiko.dev/#/patchset/20260714180223.1642792-2-nikhil.rao@amd.com?part=1
---
--- Patch [1]: [PATCH net v3 1/2] pds_core: fix deadlock between reset thread and remove ---
commit e973ecbe07b7edd4ed406cf37388217ed5a167be
Author: Nikhil P. Rao <nikhil.rao@amd.com>
pds_core: fix deadlock between reset thread and remove
This commit switches the PCI reset function in pdsc_pci_reset_thread() to
use pci_try_reset_function(). This avoids a deadlock that occurs when
pdsc_remove() holds the device_lock while waiting for destroy_workqueue()
to complete.
Link: https://patchwork.kernel.org/comment/27002369/
> pci_reset_function() acquires device_lock before performing the reset.
> pdsc_remove() is called by the PCI core with device_lock already held.
> If pdsc_pci_reset_thread() is running when pdsc_remove() is called,
> destroy_workqueue() will block waiting for the work to complete, while
> the work is blocked waiting for device_lock - deadlock.
>
> Use pci_try_reset_function() which uses pci_dev_trylock() internally.
> This acquires both the device lock and the PCI config access lock
> without blocking - if either lock is contended, it returns -EAGAIN
> immediately. This avoids the deadlock while also ensuring proper
> config space access serialization during the reset.
>
> The pci_dev_get/put calls are also removed as they were unnecessary -
> the driver-owned workqueue is destroyed in pdsc_remove(), guaranteeing
> the work completes before remove returns. The PCI core holds its
> reference to pci_dev throughout the entire unbind sequence.
[Severity: High]
This is a pre-existing issue, but since we rely on destroy_workqueue()
during pdsc_remove(), does this leave a dangling pointer that can be
accessed during teardown?
In pdsc_remove(), destroy_workqueue(pdsc->wq) is called but pdsc->wq is
not set to NULL. Immediately after, pdsc_remove() calls pdsc_teardown()
which calls pdsc_devcmd_reset(). If the firmware is unresponsive,
pdsc_devcmd_wait() times out and pdsc_devcmd_locked() will unconditionally
evaluate if (pdsc->wq), which remains true, and attempt to queue health work.
Additionally, hardware interrupts are not fully masked until pdsc_stop()
is called after destroy_workqueue(). Could an interrupt arriving during this
narrow window cause pdsc_adminq_isr() to race and call
queue_work(pdsc->wq, &qcq->work) on the destroyed workqueue?
> diff --git a/drivers/net/ethernet/amd/pds_core/core.c b/drivers/net/ethernet/amd/pds_core/core.c
> index 38a2446571afa..1074a022a52fb 100644
> --- a/drivers/net/ethernet/amd/pds_core/core.c
> +++ b/drivers/net/ethernet/amd/pds_core/core.c
> @@ -606,9 +606,10 @@ void pdsc_pci_reset_thread(struct work_struct *work)
> struct pdsc *pdsc = container_of(work, struct pdsc, pci_reset_work);
> struct pci_dev *pdev = pdsc->pdev;
>
> - pci_dev_get(pdev);
> - pci_reset_function(pdev);
> - pci_dev_put(pdev);
> + /* Use try variant to avoid deadlock with pdsc_remove().
> + * If lock is contended, the watchdog timer will retry.
> + */
> + pci_try_reset_function(pdev);
[Severity: High]
This is a pre-existing issue, but could this uncancelled work item perform
an uncoordinated PCI reset if it executes after an AER recovery?
When a PCI error is detected, pdsc_health_thread() queues pci_reset_work.
If the PCI core independently initiates AER recovery before this work executes,
it calls pdsc_reset_prepare(), which then calls pdsc_stop_health_thread().
While pdsc_stop_health_thread() cancels health_work, it does not appear to
cancel this already-queued pci_reset_work.
Because the AER thread holds the device lock during recovery, if this work
is delayed and executes after AER recovery completes and releases the lock,
will pci_try_reset_function() successfully acquire the lock and perform a
hardware reset while the driver thinks the device is actively running?
^ permalink raw reply
* Re: [PATCH net-next] net: stmmac: Simplify ioctl handling
From: Maxime Chevallier @ 2026-07-21 16:56 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Andrew Lunn, davem, Eric Dumazet, Paolo Abeni, Simon Horman,
Maxime Coquelin, Alexandre Torgue, Russell King, thomas.petazzoni,
Alexis Lothoré, netdev, linux-kernel, linux-arm-kernel,
linux-stm32
In-Reply-To: <20260721094245.1b6aab2d@kernel.org>
Hi Jakub,
On 7/21/26 18:42, Jakub Kicinski wrote:
> On Sat, 18 Jul 2026 16:38:47 +0200 Maxime Chevallier wrote:
>> Now that timestamping is controlled through an NDO, we can simply
>> call phylink_mii_ioctl() to handle ioctls.
>>
>> The only functional difference is that phylink_mii_ioctl() ->
>> phy_mii_ioctl() can handle SIOCSHWTSTAMP, but this no longer happens
>> as this ioctl is not longer dispatched to the ndo_eth_ioctl().
>
> To double check - the discussion is orthogonal and this patch can be
> applied as is?
Indeed yes, the patch itself doesn't introduce any behaviour change.
That's actually when I noticed that it doesn't introduce behaviour changes
(as the SIOCSHWTSTAMP ioctl is masked and doesn't reach the .ndo_ioctl() in
the first place) that I added the small comment that started this discussion :)
Maxime
^ permalink raw reply
* Re: [PATCH bpf v2] veth: convert frag_list skbs before running XDP
From: patchwork-bot+netdevbpf @ 2026-07-21 16:50 UTC (permalink / raw)
To: Matt Fleming
Cc: ast, daniel, andrew+netdev, davem, edumazet, kuba, pabeni, horms,
hawk, john.fastabend, sdf, lorenzo, toke, bpf, netdev, stable,
kernel-team, mfleming
In-Reply-To: <20260720140545.461747-1-matt@readmodwrite.com>
Hello:
This patch was applied to bpf/bpf.git (master)
by Kumar Kartikeya Dwivedi <memxor@gmail.com>:
On Mon, 20 Jul 2026 15:05:45 +0100 you wrote:
> From: Matt Fleming <mfleming@cloudflare.com>
>
> A frag_list skb can reach veth with data_len set but nr_frags zero.
> veth_convert_skb_to_xdp_buff() only converts skbs that are shared,
> locked, have frags[], or do not have enough headroom. It later uses
> skb_is_nonlinear() to decide whether to set XDP_FLAGS_HAS_FRAGS and
> xdp_frags_size.
>
> [...]
Here is the summary with links:
- [bpf,v2] veth: convert frag_list skbs before running XDP
https://git.kernel.org/bpf/bpf/c/c3e0e81eec96
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next] net: stmmac: Simplify ioctl handling
From: Vadim Fedorenko @ 2026-07-21 16:46 UTC (permalink / raw)
To: Richard Cochran
Cc: Maxime Chevallier, Andrew Lunn, Jakub Kicinski, davem,
Eric Dumazet, Paolo Abeni, Simon Horman, Maxime Coquelin,
Alexandre Torgue, Russell King, thomas.petazzoni,
Alexis Lothoré, netdev, linux-kernel, linux-arm-kernel,
linux-stm32, Andrew Lunn
In-Reply-To: <1e640dcb-43ce-4a3b-a74a-ed8e48706b86@lunn.ch>
On 20/07/2026 19:12, Andrew Lunn wrote:
> On Mon, Jul 20, 2026 at 04:17:32PM +0100, Vadim Fedorenko wrote:
>> On 19.07.2026 17:13, Andrew Lunn wrote:
>>>> Looking at this, I'm wondering if we can't just get rid of SIOCSHWTSTAMP
>>>> handling in phy_mii_ioctl(). Looks like we can ?
>>>
>>> I'm not sure about that. We need Richards input.
>>>
>>> The code in phy_mii_ioctl() allows the MAC to be bypassed, it goes
>>> straight to a PHY based stamper. It could be the MAC has no idea the
>>> PHY has this capability, so it has not implemented the .ndo?
>>>
>>> It might be we need to hoist the code from phy_mii_ioctl() into
>>> dev_{sg}et_hwtstamp()?
>>
>> Hi Andrew!
>>
>> I think I've converted all phy drivers while removing support for
>> SIOCSHWTSTAMP/SIOCGHWTSTAMP from netdev ioctl. I believe it's impossible right
>> now to reach SIOCSHWTSTAMP path of phy_mii_ioctl via ioctl on net device.
>
> Lets look at this, using a random example:
>
> drivers/net/ethernet/marvell/mv643xx_eth.c
>
> mv643xx_eth_netdev_ops has nothing about time stamping. However it
> does have a mv643xx_eth_ioctl. Which calls phy_mii_ioctl().
>
> Lets say this Marvell MAC driver was paired with a
> nxp-c45-tja11xx. nxp_c45_probe() does:
>
> priv->mii_ts.rxtstamp = nxp_c45_rxtstamp;
> priv->mii_ts.txtstamp = nxp_c45_txtstamp;
> priv->mii_ts.hwtstamp_set = nxp_c45_hwtstamp_set;
> priv->mii_ts.hwtstamp_get = nxp_c45_hwtstamp_get;
> priv->mii_ts.ts_info = nxp_c45_ts_info;
> phydev->mii_ts = &priv->mii_ts;
>
> So it looks like in phy_mii_ioctl(), the conditions:
>
> case SIOCSHWTSTAMP:
> if (phydev->mii_ts && phydev->mii_ts->hwtstamp_set) {
>
> are fulfilled, and
>
> ret = phydev->mii_ts->hwtstamp_set(phydev->mii_ts,
> &kernel_cfg,
> &extack);
>
> will happen.
>
> Now, this combination of MAC and PHY is very unlikely but it proves
> the point. As far as i remember, Richard added this code for the
> dp83640 PHY device, but i don't remember what MAC driver it was paired
> with. He wanted to make PHY support just work without the MAC driver
> even caring.
Richard,
is it still a case? do you have a HW to test patches that I'm going to
write to restore the functionality?
^ permalink raw reply
* Re: [PATCH net-next] net: stmmac: Simplify ioctl handling
From: Jakub Kicinski @ 2026-07-21 16:42 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Andrew Lunn, davem, Eric Dumazet, Paolo Abeni, Simon Horman,
Maxime Coquelin, Alexandre Torgue, Russell King, thomas.petazzoni,
Alexis Lothoré, netdev, linux-kernel, linux-arm-kernel,
linux-stm32
In-Reply-To: <20260718143848.677531-1-maxime.chevallier@bootlin.com>
On Sat, 18 Jul 2026 16:38:47 +0200 Maxime Chevallier wrote:
> Now that timestamping is controlled through an NDO, we can simply
> call phylink_mii_ioctl() to handle ioctls.
>
> The only functional difference is that phylink_mii_ioctl() ->
> phy_mii_ioctl() can handle SIOCSHWTSTAMP, but this no longer happens
> as this ioctl is not longer dispatched to the ndo_eth_ioctl().
To double check - the discussion is orthogonal and this patch can be
applied as is?
^ permalink raw reply
* [PATCH net-next] geneve: fix geneve_config leak on register_netdevice() failure
From: Eric Dumazet @ 2026-07-21 16:39 UTC (permalink / raw)
To: David S . Miller, Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, netdev, eric.dumazet, Eric Dumazet
When geneve_configure() allocates a new geneve_config structure via
geneve_config_alloc() and assigns it to geneve->cfg before calling
register_netdevice(), if register_netdevice() fails early (for example,
in dev_get_valid_name() due to an invalid or duplicate interface name),
register_netdevice() exits without calling dev->priv_destructor.
The caller (e.g. rtnl_newlink()) subsequently calls free_netdev(), which
frees the net_device structure directly via kvfree() because reg_state is
NETREG_UNINITIALIZED, bypassing dev->priv_destructor (geneve_free_dev()).
As a result, the newly allocated geneve_config and its per-CPU dst_cache
are leaked.
Fix this by invoking geneve_free_dev(dev) directly on the error path of
register_netdevice(). Since geneve_free_dev() sets geneve->cfg to NULL,
this call is fully idempotent and safe even if register_netdevice()
failed on a later error path that already ran dev->priv_destructor.
Fixes: 0ba269933f73 ("geneve: convert config to RCU-protected pointer")
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
drivers/net/geneve.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 17bd3543d587a9e941737109df82b83023d23711..eb156f33b62751b655178ad4f37d2c66f909ffc7 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -2043,8 +2043,10 @@ static int geneve_configure(struct net *net, struct net_device *dev,
}
err = register_netdevice(dev);
- if (err)
+ if (err) {
+ geneve_free_dev(dev);
return err;
+ }
list_add(&geneve->next, &gn->geneve_list);
return 0;
--
2.55.0.229.g6434b31f56-goog
^ permalink raw reply related
* [PATCH net-next] nfc: digital: fix use-after-free in nfc_digital_unregister_device()
From: Weiming Shi @ 2026-07-21 16:36 UTC (permalink / raw)
To: David Heidelberg, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: oe-linux-nfc, netdev, linux-kernel, Xiang Mei, Weiming Shi
nfc_digital_unregister_device() cancels cmd_work and cmd_complete_work
once each and then frees the command queue. The two works re-arm each
other: digital_wq_cmd_complete() ends with schedule_work(&ddev->cmd_work),
and digital_wq_cmd() hands a command to the driver whose asynchronous
completion schedules cmd_complete_work. cancel_work_sync() only waits for
the instance it cancels; it does not stop the work from being queued again.
A work re-armed after its cancel_work_sync() therefore runs concurrently
with the cmd_queue cleanup and dereferences a digital_cmd the cleanup has
already freed. digital_wq_cmd() widens the window by dropping cmd_lock
before using the command it took from the queue, while the cleanup loop
frees the commands without holding cmd_lock.
It is reproducible with the software NFC simulator (CONFIG_NFC_SIM): start
an NFC-DEP exchange between the two nfcsim devices and unload the module
while it is running.
BUG: KASAN: slab-use-after-free in digital_wq_cmd (net/nfc/digital_core.c:174)
Read of size 1 by task kworker/1:5
Workqueue: events digital_wq_cmd
digital_wq_cmd (net/nfc/digital_core.c:174)
process_one_work
worker_thread
kthread
Allocated by task 5124:
digital_send_cmd (net/nfc/digital_core.c:234)
digital_in_send_sdd_req
digital_in_recv_sens_res
digital_wq_cmd_complete (net/nfc/digital_core.c:134)
Freed by task 4994:
kfree
nfc_digital_unregister_device (net/nfc/digital_core.c:859)
nfcsim_device_free [nfcsim]
nfcsim_exit [nfcsim]
__do_sys_delete_module
Use disable_work_sync() instead of cancel_work_sync() for the two command
works. disable_work_sync() cancels the work and disables it, so any later
schedule_work() -- whether from the sibling work re-arming it or from the
driver's completion callback -- becomes a no-op. Once both works are
disabled no work can run, and the cleanup loop frees the queue with no work
able to reach a freed command.
Fixes: 59ee2361c924 ("NFC Digital: Implement driver commands mechanism")
Reported-by: Xiang Mei <xmei5@asu.edu>
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
---
net/nfc/digital_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/nfc/digital_core.c b/net/nfc/digital_core.c
index 7cb1e6aaae90..6def5132a4a6 100644
--- a/net/nfc/digital_core.c
+++ b/net/nfc/digital_core.c
@@ -843,8 +843,8 @@ void nfc_digital_unregister_device(struct nfc_digital_dev *ddev)
mutex_unlock(&ddev->poll_lock);
cancel_delayed_work_sync(&ddev->poll_work);
- cancel_work_sync(&ddev->cmd_work);
- cancel_work_sync(&ddev->cmd_complete_work);
+ disable_work_sync(&ddev->cmd_work);
+ disable_work_sync(&ddev->cmd_complete_work);
list_for_each_entry_safe(cmd, n, &ddev->cmd_queue, queue) {
list_del(&cmd->queue);
base-commit: d4932951a19a5f1ec93200260b85e1a4c080ff77
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net v3] tipc: clear sock->sk on the failed-insert path in tipc_sk_create()
From: Simon Horman @ 2026-07-21 16:37 UTC (permalink / raw)
To: Daehyeon Ko
Cc: netdev, Jon Maloy, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Tung Quang Nguyen, Breno Leitao, tipc-discussion,
linux-kernel, stable
In-Reply-To: <20260714131939.1255974-1-4ncienth@gmail.com>
On Tue, Jul 14, 2026 at 10:19:39PM +0900, Daehyeon Ko wrote:
> When tipc_sk_create() fails to insert the new socket (tipc_sk_insert()
> returns non-zero), its error path frees the sk with sk_free() but leaves
> sock->sk pointing at the freed object:
>
> if (tipc_sk_insert(tsk)) {
> sk_free(sk);
> pr_warn("Socket create failed; port number exhausted\n");
> return -EINVAL;
> }
>
> This is harmless for plain socket(): the syscall layer clears sock->ops
> before releasing, so tipc_release() is never called. It is not harmless
> on the accept() path. tipc_accept() creates the pre-allocated child
> socket with tipc_sk_create(net, new_sock, 0, kern); on failure it leaves
> new_sock->sk dangling and new_sock->ops non-NULL, and do_accept() then
> fput()s the new file, so __sock_release() -> tipc_release() runs
> lock_sock(new_sock->sk) on the freed sk -- a use-after-free write of the
> sk_lock spinlock.
>
> tipc_release() already guards this exact "failed accept() releases a
> pre-allocated child" case with "if (sk == NULL) return 0;", but the
> guard is bypassed because tipc_sk_create() left sock->sk non-NULL
> (dangling) rather than NULL.
>
> Clear sock->sk on the failed-insert path so the existing tipc_release()
> NULL check fires and the use-after-free is avoided.
>
> The tipc_sk_insert() failure is reached when the per-netns socket
> rhashtable hits its max_size (tsk_rht_params.max_size = 1048576, ~2M
> elements) -- i.e. once a netns holds ~2M TIPC sockets every insert
> returns -E2BIG.
>
> BUG: KASAN: slab-use-after-free in lock_sock_nested (net/core/sock.c:3839)
> Write of size 8 at addr ffff8880047cdc38 by task init/1
> lock_sock_nested (net/core/sock.c:3839)
> tipc_release (net/tipc/socket.c:638)
> __sock_release (net/socket.c:710)
> sock_close (net/socket.c:1501)
> __fput (fs/file_table.c:512)
> Allocated by task 1:
> sk_alloc (net/core/sock.c:2308)
> tipc_sk_create (net/tipc/socket.c:487)
> tipc_accept (net/tipc/socket.c:2744)
> do_accept (net/socket.c:2034)
> Freed by task 1:
> __sk_destruct (net/core/sock.c:2391)
> tipc_sk_create (net/tipc/socket.c:504)
> tipc_accept (net/tipc/socket.c:2744)
> do_accept (net/socket.c:2034)
>
> Fixes: 00aff3590fc0 ("net: tipc: fix possible refcount leak in tipc_sk_create()")
> Cc: stable@vger.kernel.org
> Reviewed-by: Tung Nguyen <tung.quang.nguyen@est.tech>
> Reviewed-by: Breno Leitao <leitao@debian.org>
> Signed-off-by: Daehyeon Ko <4ncienth@gmail.com>
> ---
> v3: correct the Fixes: tag to 00aff3590fc0 ("net: tipc: fix possible
> refcount leak in tipc_sk_create()") -- that commit added the sk_free()
> on the insert-failure path; before it the path leaked sk rather than
> freeing it, so the use-after-free only exists since then (v5.19+).
> Thanks Breno. Collect Reviewed-by from Tung and Breno. No code change.
> v2: https://lore.kernel.org/netdev/20260713082342.3803379-1-4ncienth@gmail.com/
> v1: https://lore.kernel.org/netdev/20260710014440.2055584-1-4ncienth@gmail.com/
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [RFC PATCH net-next 08/13] drm/amdkfd: add GPU instruction emitter and disassembler
From: Hoyeon Lee @ 2026-07-21 16:36 UTC (permalink / raw)
To: Andrew Lunn
Cc: Natalie Vock, Taehee Yoo, Alex Deucher, Alexei Starovoitov,
amd-gfx, Andrew Lunn, Andrii Nakryiko, Bill Wendling, bpf,
Christian König, Daniel Borkmann, David Airlie,
David S. Miller, Donald Hunter, dri-devel, Eduard Zingerman,
Emil Tsalapatis, Eric Dumazet, Felix Kuehling, Ilias Apalodimas,
Jakub Kicinski, Jesper Dangaard Brouer, Jiri Olsa, John Fastabend,
Justin Stitt, Kees Cook, Kumar Kartikeya Dwivedi, Leon Romanovsky,
linaro-mm-sig, linux-hardening, linux-kernel, linux-kselftest,
linux-media, linux-rdma, llvm, Mark Bloch, Martin KaFai Lau,
Michael Chan, Nathan Chancellor, netdev, Nick Desaulniers,
Paolo Abeni, Pavan Chebbi, Saeed Mahameed, Shuah Khan,
Simona Vetter, Simon Horman, Song Liu, Stanislav Fomichev,
Sumit Semwal, Tariq Toukan, Yonghong Song
In-Reply-To: <8dfbef48-db20-4642-8f50-e37f46af6627@lunn.ch>
On Tue, Jul 21, 2026 at 5:53 AM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Mon, Jul 20, 2026 at 10:05:33PM +0200, Natalie Vock wrote:
> > On 7/19/26 19:58, Taehee Yoo wrote:
> > > Add the AMD GCN (gfx9/gfx10) instruction encoder used to build the GPU
> > > shaders that knod dispatches, plus a matching disassembler used for
> > > debugging the generated code.
> >
> > Is it really necessary to have a full-on compiler and disassembler in the
> > kernel driver? This patch is massive and I'm wondering how much benefit it
> > really provides. Is there really no way to move GPU compilation out of the
> > kernel, one way or another? Could you get acceptable perf with a static
> > shader that interprets BPF programs at runtime? Such a shader can be
> > compiled beforehand and just embedded into the kernel - there's prior art
> > there with the CWSR trap handler in amdkfd.
> >
> > In case you really, really need to compile the BPF to native ISA, could you
> > still have userspace take care of that in one way or another?
>
> There was a long and painful discussion about P4, and offloading it to
> hardware. The proponents of that wanted to do the compilation stage in
> user space to produce a binary blob, but it was hard to prove that the
> P4 passed to the kernel for software processing, and the binary blob
> passed to the hardware actually where the same. It opened up the path
> for closed source P4 where the kernel never got to see the actual P4
> code. So it was not really offload, but kernel bypass.
>
> So having a compiler in the kernel is probably the correct way to go,
> if you want to be friendly to open source.
>
> The other option is to get the GPU to do the compilation itself, so
> you pass BPF byte codes to the GPU and it generates its own native
> code. I've no idea if that is possible, but clang can target OpenMP,
> so maybe it is possible to move this compiler into the GPU?
>
Hi Natalie and Andrew,
Thank you both for the review and suggestions.
We tried running a BPF interpreter on the GPU using OpenCL in an early
prototype. The interpreter overhead dominated because each BPF
instruction required many native GPU instructions, so the performance
was not practical. Since this was only an early feasibility prototype,
we do not have benchmark data suitable for a meaningful comparison.
Based on that result, we chose to compile BPF directly into native GPU
instructions. Moving compilation to userspace would also raise the
problem Andrew described: the kernel could no longer easily establish
that the verified BPF program and the submitted GPU binary are
equivalent. We have not tried compiling on the GPU itself, but that may
be worth investigating separately.
The disassembler is only used for debugging the generated GPU
instructions and is not required for execution. We can leave it out of
the initial series and submit it separately if needed.
Regards,
Hoyeon Lee
> Andrew
^ permalink raw reply
* Re: [PATCH net-next] rndis_host: add overflow check in rndis_rx_fixup()
From: patchwork-bot+netdevbpf @ 2026-07-21 16:30 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: netdev, linux-usb, linux-kernel, griffin, andrew+netdev, davem,
edumazet, kuba, pabeni, shaoxul
In-Reply-To: <2026070900-denim-brook-52d4@gregkh>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 9 Jul 2026 14:24:01 +0200 you wrote:
> From: Griffin Kroah-Hartman <griffin@kroah.com>
>
> Add an overflow check to ensure that data_offset + data_len + 8 does not
> wrap, which would enable an OOB read of the USB data buffer.
>
> Assisted-by: gkh_clanker_1000
> Cc: Andrew Lunn <andrew+netdev@lunn.ch>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: Paolo Abeni <pabeni@redhat.com>
> Cc: Shaoxu Liu <shaoxul@foxmail.com>
> Signed-off-by: Griffin Kroah-Hartman <griffin@kroah.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> [...]
Here is the summary with links:
- [net-next] rndis_host: add overflow check in rndis_rx_fixup()
https://git.kernel.org/netdev/net-next/c/965a251f23ff
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH net v2 1/1] tipc: avoid use-after-free in poll trace queue dumps
From: Ren Wei @ 2026-07-21 16:24 UTC (permalink / raw)
To: netdev, tipc-discussion
Cc: jmaloy, davem, edumazet, pabeni, horms, tuong.t.lien, ying.xue,
vega, xizh2024, enjou1224z
In-Reply-To: <cover.1784642230.git.xizh2024@lzu.edu.cn>
From: Zihan Xi <xizh2024@lzu.edu.cn>
TIPC socket tracepoints dump queue state through tipc_sk_dump(). Most
queue-dump callsites already serialize that walk under the socket lock or
sk->sk_lock.slock, but tipc_poll() calls trace_tipc_sk_poll(...,
TIPC_DUMP_ALL, ...) without holding either lock.
That lets the poll trace path reach tipc_list_dump() and backlog head/tail
dumping while another context dequeues and frees an skb, leaving the trace
helper dereferencing a stale queue entry.
Keep the existing trace output, but serialize the poll trace snapshot with
the socket lock. Gate the locking on trace_tipc_sk_poll_enabled() so the
hot poll path does not take the lock when the tracepoint is disabled.
Fixes: b4b9771bcbbd ("tipc: enable tracepoints in tipc")
Cc: stable@vger.kernel.org
Reported-by: Vega <vega@nebusec.ai>
Assisted-by: Codex:gpt-5.4
Signed-off-by: Zihan Xi <xizh2024@lzu.edu.cn>
Signed-off-by: Ren Wei <enjou1224z@gmail.com>
---
changes in v2:
- Keep the existing queue and backlog trace output intact.
- Serialize the poll trace snapshot under the socket lock.
- Gate the new locking on trace_tipc_sk_poll_enabled().
- v1 Link: https://lore.kernel.org/all/24f7311aed0c9ff06b8ea982647b82bf543ec369.1784454542.git.xizh2024@lzu.edu.cn/
net/tipc/socket.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index e564341e0216..51692c4a0e47 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -794,8 +794,14 @@ static __poll_t tipc_poll(struct file *file, struct socket *sock,
struct tipc_sock *tsk = tipc_sk(sk);
__poll_t revents = 0;
+ bool slow;
+
sock_poll_wait(file, sock, wait);
- trace_tipc_sk_poll(sk, NULL, TIPC_DUMP_ALL, " ");
+ if (trace_tipc_sk_poll_enabled()) {
+ slow = lock_sock_fast(sk);
+ trace_tipc_sk_poll(sk, NULL, TIPC_DUMP_ALL, " ");
+ unlock_sock_fast(sk, slow);
+ }
if (sk->sk_shutdown & RCV_SHUTDOWN)
revents |= EPOLLRDHUP | EPOLLIN | EPOLLRDNORM;
--
2.43.0
^ permalink raw reply related
* [PATCH net v2 0/1] tipc: avoid use-after-free in poll trace queue dumps
From: Ren Wei @ 2026-07-21 16:24 UTC (permalink / raw)
To: netdev, tipc-discussion
Cc: jmaloy, davem, edumazet, pabeni, horms, tuong.t.lien, ying.xue,
vega, xizh2024, enjou1224z
From: Zihan Xi <xizh2024@lzu.edu.cn>
Hi Linux kernel maintainers,
We found and validated a bug in net/tipc/socket.c. The bug is
reachable by a local process that can create TIPC sockets and enable
TIPC tracepoints. We rebuilt and reran the reproducer with the updated
fix, and it preserves the trace output while removing the crash.
This series contains one patch:
1/1 tipc: avoid use-after-free in poll trace queue dumps
Compared with v1, this revision follows the feedback that the trace path
should keep the queue/backlog information that is useful for debugging.
We also tested the suggested tipc_poll() change to switch this tracepoint
to TIPC_DUMP_NONE. That looks like it can avoid the reported poll stack,
but it only disables queue dumping at this one caller and does not change
the lifetime assumptions in tipc_sk_dump()/tipc_list_dump() themselves.
This v2 therefore tries to preserve the existing trace information while
serializing the poll trace snapshot with the socket lock, gated by
trace_tipc_sk_poll_enabled().
v1 Link: https://lore.kernel.org/all/24f7311aed0c9ff06b8ea982647b82bf543ec369.1784454542.git.xizh2024@lzu.edu.cn/
We provide bug details, reproducer steps, and a crash log below.
---- details below ----
Bug details:
TIPC socket tracepoints dump queue state through tipc_sk_dump(). Most
queue-dump callsites already serialize that walk under the socket lock
or sk->sk_lock.slock, but tipc_poll() calls
trace_tipc_sk_poll(..., TIPC_DUMP_ALL, ...) without holding either
lock.
That lets the poll trace path reach tipc_list_dump() and backlog
head/tail dumping while another context dequeues and frees an skb,
leaving the trace helper dereferencing a stale queue entry.
This v2 keeps the existing queue and backlog trace output, but
serializes the poll trace snapshot with the socket lock. The new
locking is gated on trace_tipc_sk_poll_enabled() so the hot poll path
does not take the lock when the tracepoint is disabled.
Reproducer:
Guest:
gcc -O2 -pthread -Wall /root/tipc_poc.c -o /root/tipc_poc
mount -t tracefs nodev /sys/kernel/tracing 2>/dev/null || true
tipc node set identity 1.1.1
timeout 30s /root/tipc_poc
Host:
make O=/var/cache/linux-patch/tipc-list-dump-build-ext4 olddefconfig
make O=/var/cache/linux-patch/tipc-list-dump-build-ext4 -j$(nproc) bzImage
We run the PoC in a 2 vCPU, 2 GB RAM x86 QEMU environment.
------BEGIN poc.c------
#define _GNU_SOURCE
#include <arpa/inet.h>
#include <errno.h>
#include <fcntl.h>
#include <linux/tipc.h>
#include <poll.h>
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <unistd.h>
#define TRACE "/sys/kernel/tracing"
#define TIPC_TYPE 5555
static volatile int stop_flag;
static int srv_fd, cli_fd;
static void write_file(const char *path, const char *s)
{
int fd = open(path, O_WRONLY | O_TRUNC);
if (fd < 0) { perror(path); exit(1); }
if (write(fd, s, strlen(s)) < 0) { perror("write"); exit(1); }
close(fd);
}
static void enable_trace(void)
{
char path[256];
write_file(TRACE "/tracing_on", "0\n");
write_file(TRACE "/trace", "");
const char *evs[] = {"tipc_sk_poll", "tipc_sk_filter_rcv", "tipc_sk_overlimit1", "tipc_sk_overlimit2"};
for (int i = 0; i < 4; i++) {
snprintf(path, sizeof(path), TRACE "/events/tipc/%s/enable", evs[i]);
write_file(path, "1\n");
}
write_file(TRACE "/tracing_on", "1\n");
}
static void *sender(void *arg)
{
char payload[4096];
long cnt = 0;
memset(payload, 'A', sizeof(payload));
struct sockaddr_tipc dst = {0};
dst.family = AF_TIPC;
dst.addrtype = TIPC_SERVICE_ADDR;
dst.scope = TIPC_CLUSTER_SCOPE;
dst.addr.name.name.type = TIPC_TYPE;
dst.addr.name.name.instance = 1;
dst.addr.name.domain = 0;
while (!stop_flag) {
if (sendto(cli_fd, payload, sizeof(payload), 0, (struct sockaddr *)&dst, sizeof(dst)) >= 0)
cnt++;
}
printf("sent %ld\n", cnt);
return NULL;
}
static void *poller(void *arg)
{
struct pollfd pfd = {.fd = srv_fd, .events = POLLIN};
long cnt = 0;
while (!stop_flag) {
poll(&pfd, 1, 0);
cnt++;
}
printf("poll %ld\n", cnt);
return NULL;
}
static void *receiver(void *arg)
{
char buf[4096];
long cnt = 0;
fcntl(srv_fd, F_SETFL, fcntl(srv_fd, F_GETFL) | O_NONBLOCK);
while (!stop_flag) {
ssize_t n = recv(srv_fd, buf, sizeof(buf), 0);
if (n > 0) cnt++;
else if (n < 0 && errno != EAGAIN && errno != EWOULDBLOCK) {}
}
printf("recv %ld\n", cnt);
return NULL;
}
int main(void)
{
enable_trace();
srv_fd = socket(AF_TIPC, SOCK_RDM, 0);
if (srv_fd < 0) { perror("socket srv"); return 1; }
int rcvbuf = 1 << 20;
setsockopt(srv_fd, SOL_SOCKET, SO_RCVBUF, &rcvbuf, sizeof(rcvbuf));
struct sockaddr_tipc srv = {0};
srv.family = AF_TIPC;
srv.addrtype = TIPC_SERVICE_RANGE;
srv.scope = TIPC_CLUSTER_SCOPE;
srv.addr.nameseq.type = TIPC_TYPE;
srv.addr.nameseq.lower = 1;
srv.addr.nameseq.upper = 1;
if (bind(srv_fd, (struct sockaddr *)&srv, sizeof(srv)) < 0) { perror("bind"); return 1; }
struct sockaddr_tipc name = {0};
socklen_t namelen = sizeof(name);
if (getsockname(srv_fd, (struct sockaddr *)&name, &namelen) < 0) { perror("getsockname"); return 1; }
unsigned int portid = name.addr.id.ref;
printf("server portid %u\n", portid);
char filter[128];
snprintf(filter, sizeof(filter), "%u 0 0 0 0\n", portid);
write_file("/proc/sys/net/tipc/sk_filter", filter);
cli_fd = socket(AF_TIPC, SOCK_RDM, 0);
if (cli_fd < 0) { perror("socket cli"); return 1; }
int imp = TIPC_CRITICAL_IMPORTANCE;
setsockopt(cli_fd, SOL_TIPC, TIPC_IMPORTANCE, &imp, sizeof(imp));
pthread_t th[3];
pthread_create(&th[0], NULL, sender, NULL);
pthread_create(&th[1], NULL, poller, NULL);
pthread_create(&th[2], NULL, receiver, NULL);
sleep(5);
stop_flag = 1;
for (int i = 0; i < 3; i++) pthread_join(th[i], NULL);
system("tail -80 /sys/kernel/tracing/trace");
return 0;
}
------END poc.c--------
----BEGIN crash log----
[ 282.625215][ T9764] page_owner tracks the page as allocated
[ 282.626124][ T9764] page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd2cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 9763, tgid 9760 (python3), ts 282622559122, free_ts 280322580853
[ 282.628916][ T9764] page last free pid 9750 tgid 9750 stack trace:
[ 282.630090][ T9764] Kernel panic - not syncing: KASAN: panic_on_warn set ...
[ 282.631030][ T9764] CPU: 1 UID: 0 PID: 9764 Comm: python3 Not tainted 7.1.0-rc2 #10 PREEMPT(full)
[ 282.632219][ T9764] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 282.633618][ T9764] Call Trace:
[ 282.634056][ T9764] <TASK>
[ 282.634440][ T9764] vpanic+0x6c3/0x790
[ 282.634974][ T9764] ? __pfx_vpanic+0x10/0x10
[ 282.635573][ T9764] ? srso_alias_return_thunk+0x5/0xfbef5
[ 282.636323][ T9764] ? srso_alias_return_thunk+0x5/0xfbef5
[ 282.637064][ T9764] ? irqentry_exit+0x24d/0x830
[ 282.637683][ T9764] ? srso_alias_return_thunk+0x5/0xfbef5
[ 282.638419][ T9764] ? lockdep_hardirqs_on+0x7b/0x110
[ 282.639112][ T9764] ? tipc_skb_dump+0x14a4/0x14d0
[ 282.639756][ T9764] panic+0xca/0xd0
[ 282.640261][ T9764] ? __pfx_panic+0x10/0x10
[ 282.640855][ T9764] check_panic_on_warn+0x61/0x80
[ 282.641542][ T9764] end_report+0x13e/0x180
[ 282.642133][ T9764] kasan_report+0xf4/0x120
[ 282.642764][ T9764] ? tipc_skb_dump+0x14a4/0x14d0
[ 282.643600][ T9764] tipc_skb_dump+0x14a4/0x14d0
[ 282.644400][ T9764] tipc_list_dump+0x1b6/0x2a0
[ 282.645093][ T9764] tipc_sk_dump+0xa92/0xcc0
[ 282.645700][ T9764] ? trace_event_buffer_reserve+0x150/0x300
[ 282.646510][ T9764] trace_event_raw_event_tipc_sk_class+0x2c1/0x490
[ 282.647402][ T9764] ? __pfx_trace_event_raw_event_tipc_sk_class+0x10/0x10
[ 282.648345][ T9764] ? srso_alias_return_thunk+0x5/0xfbef5
[ 282.649114][ T9764] ? srso_alias_return_thunk+0x5/0xfbef5
[ 282.649884][ T9764] ? srso_alias_return_thunk+0x5/0xfbef5
[ 282.650654][ T9764] ? __pfx_tipc_poll+0x10/0x10
[ 282.651310][ T9764] tipc_poll+0x290/0x590
[ 282.651895][ T9764] sock_poll+0x134/0x490
[ 282.652492][ T9764] do_sys_poll+0x507/0xbf0
[ 282.653113][ T9764] ? __pfx_do_sys_poll+0x10/0x10
[ 282.653829][ T9764] ? do_raw_spin_lock+0x12d/0x270
[ 282.654597][ T9764] ? srso_alias_return_thunk+0x5/0xfbef5
[ 282.655369][ T9764] ? do_futex+0x1cd/0x230
[ 282.655977][ T9764] ? __pfx_do_futex+0x10/0x10
[ 282.656614][ T9764] ? srso_alias_return_thunk+0x5/0xfbef5
[ 282.657381][ T9764] __x64_sys_poll+0x181/0x3e0
[ 282.658035][ T9764] ? __pfx___x64_sys_poll+0x10/0x10
[ 282.658745][ T9764] ? srso_alias_return_thunk+0x5/0xfbef5
[ 282.659515][ T9764] ? rcu_is_watching+0x12/0xc0
[ 282.660208][ T9764] do_syscall_64+0x116/0xf80
[ 282.660823][ T9764] ? irqentry_exit+0x117/0x830
[ 282.661476][ T9764] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 282.662266][ T9764] RIP: 0033:0x7f332e77d9ee
[ 282.662861][ T9764] Code: 08 0f 85 f5 4b ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 80 00 00 00 00 48 83 ec 08
[ 282.664714][ T9764] RSP: 002b:00007f332d6fdb58 EFLAGS: 00000246 ORIG_RAX: 0000000000000007
[ 282.665298][ T9764] RAX: ffffffffffffffda RBX: 00007f332d6fe6c0 RCX: 00007f332e77d9ee
[ 282.665838][ T9764] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 00007f332e604450
[ 282.666442][ T9764] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[ 282.666986][ T9764] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f332e1834c0
[ 282.667563][ T9764] R13: 000000000c939210 R14: 00007f332d6fe640 R15: 00007f332e19af10
[ 282.668176][ T9764] </TASK>
[ 282.669068][ T9764] Kernel Offset: disabled
[ 282.669366][ T9764] Rebooting in 86400 seconds..
-----END crash log-----
Best regards,
Zihan Xi
Zihan Xi (1):
tipc: avoid use-after-free in poll trace queue dumps
net/tipc/socket.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCHv3 net-next 6/9] net: usb: move exported symbols from cdc_ether to usbnet
From: Jakub Kicinski @ 2026-07-21 16:24 UTC (permalink / raw)
To: Oliver Neukum
Cc: andrew+netdev, davem, edumazet, pabeni, manuelebner, netdev,
linux-kernel
In-Reply-To: <20260714114429.1073434-6-oneukum@suse.com>
On Tue, 14 Jul 2026 13:44:26 +0200 Oliver Neukum wrote:
> --- a/include/linux/usb/usbnet.h
> +++ b/include/linux/usb/usbnet.h
> @@ -16,6 +16,11 @@
> #include <linux/usb.h>
> #include <linux/spinlock.h>
>
> +static const u8 mbm_guid[16] = {
> + 0xa3, 0x17, 0xa8, 0x8b, 0x04, 0x5e, 0x4f, 0x01,
> + 0xa6, 0x07, 0xc0, 0xff, 0xcb, 0x7e, 0x39, 0x2a,
> +};
> +
> struct cdc_state {
> struct usb_cdc_header_desc *header;
> struct usb_cdc_union_desc *u;
> @@ -304,4 +309,16 @@ extern void usbnet_status_stop(struct usbnet *dev);
>
> extern void usbnet_update_max_qlen(struct usbnet *dev);
>
> +/* We need to override usbnet_*_link_ksettings in bind() */
> +static const struct ethtool_ops cdc_ether_ethtool_ops = {
> + .get_link = usbnet_get_link,
> + .nway_reset = usbnet_nway_reset,
> + .get_drvinfo = usbnet_get_drvinfo,
> + .get_msglevel = usbnet_get_msglevel,
> + .set_msglevel = usbnet_set_msglevel,
> + .get_ts_info = ethtool_op_get_ts_info,
> + .get_link_ksettings = usbnet_get_link_ksettings_internal,
> + .set_link_ksettings = NULL,
> +};
spews a ton of defined but not used warnings
^ permalink raw reply
* Re: [PATCHv3 net-next 1/9] net: usb: move updating filter and status from cdc drivers to usbnet
From: Jakub Kicinski @ 2026-07-21 16:23 UTC (permalink / raw)
To: Oliver Neukum
Cc: andrew+netdev, davem, edumazet, pabeni, manuelebner, netdev,
linux-kernel
In-Reply-To: <20260714114429.1073434-1-oneukum@suse.com>
On Tue, 14 Jul 2026 13:44:21 +0200 Oliver Neukum wrote:
> These helpers are used by multiple drivers and do not depend
> on the rest. For example rndis_host will also need cdc_ether.
> Leaving them in a cdc driver means that additional drivers are loaded
> just as a library, not to support hardware by themselves.
checkpatch
ERROR: trailing whitespace
#169: FILE: drivers/net/usb/usbnet.c:2316:
+^I^I/* we cannot assume the device is in sync with us*/ $
^ permalink raw reply
* Re: [PATCHv3 net-next 3/9] net: usb: usbnet: add cdc_state to struct usbnet
From: Jakub Kicinski @ 2026-07-21 16:22 UTC (permalink / raw)
To: Oliver Neukum
Cc: Andrew Lunn, andrew+netdev, davem, edumazet, pabeni, manuelebner,
netdev, linux-kernel
In-Reply-To: <ee6c537e-32e7-48a3-9037-49ef15ca7603@lunn.ch>
On Wed, 15 Jul 2026 03:18:00 +0200 Andrew Lunn wrote:
> On Tue, Jul 14, 2026 at 01:44:23PM +0200, Oliver Neukum wrote:
> > This allows centralisation of code using cdc_state in usbnet, reducing
> > code duplication. No functional change intended.
> >
> > Signed-off-by: Oliver Neukum <oneukum@suse.com>
>
> I gave a Reviewed-by to v2 of this patch. You are supposed to attach
> them here on the next version. b4 collect them and add them for you,
> if you use it.
Yes, please repost this with the missing tags and add a cover letter.
The basics :/
^ permalink raw reply
* [PATCH net] pds_core: keep the health thread stopped during reset
From: Nikhil P. Rao @ 2026-07-21 16:21 UTC (permalink / raw)
To: netdev
Cc: kuba, brett.creeley, eric.joyner, andrew+netdev, davem, edumazet,
pabeni, Nikhil P. Rao
Commit d9407ff11809 ("pds_core: Prevent health thread from running
during reset/remove") stops the health thread with cancel_work_sync()
before a reset, but a devcmd timeout during pdsc_fw_down() re-queues
health_work, so pdsc_health_thread() runs again mid-reset and double
allocates the core DMA queues via pdsc_fw_up().
Only the reset path is affected. On remove, PDSC_S_STOPPING_DRIVER gates
the health thread.
Track the health thread's stopped state so a work item queued after the
cancel bails out.
Fixes: d9407ff11809 ("pds_core: Prevent health thread from running during reset/remove")
Reported-by: sashiko-bot <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260629200358.2626129-1-nikhil.rao%40amd.com?part=2
Signed-off-by: Nikhil P. Rao <nikhil.rao@amd.com>
---
drivers/net/ethernet/amd/pds_core/core.c | 3 +++
drivers/net/ethernet/amd/pds_core/core.h | 1 +
drivers/net/ethernet/amd/pds_core/main.c | 2 ++
3 files changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/amd/pds_core/core.c b/drivers/net/ethernet/amd/pds_core/core.c
index 38a2446571af..c4cba7194da0 100644
--- a/drivers/net/ethernet/amd/pds_core/core.c
+++ b/drivers/net/ethernet/amd/pds_core/core.c
@@ -635,6 +635,9 @@ void pdsc_health_thread(struct work_struct *work)
unsigned long mask;
bool healthy;
+ if (READ_ONCE(pdsc->health_stopped))
+ return;
+
mutex_lock(&pdsc->config_lock);
/* Don't do a check when in a transition state */
diff --git a/drivers/net/ethernet/amd/pds_core/core.h b/drivers/net/ethernet/amd/pds_core/core.h
index b7fe9ad73349..a1d41329209f 100644
--- a/drivers/net/ethernet/amd/pds_core/core.h
+++ b/drivers/net/ethernet/amd/pds_core/core.h
@@ -171,6 +171,7 @@ struct pdsc {
struct timer_list wdtimer;
unsigned int wdtimer_period;
struct work_struct health_work;
+ bool health_stopped;
struct devlink_health_reporter *fw_reporter;
u32 fw_recoveries;
diff --git a/drivers/net/ethernet/amd/pds_core/main.c b/drivers/net/ethernet/amd/pds_core/main.c
index 22db78343eb0..32e1d7069969 100644
--- a/drivers/net/ethernet/amd/pds_core/main.c
+++ b/drivers/net/ethernet/amd/pds_core/main.c
@@ -463,6 +463,7 @@ static void pdsc_stop_health_thread(struct pdsc *pdsc)
if (pdsc->pdev->is_virtfn)
return;
+ WRITE_ONCE(pdsc->health_stopped, true);
timer_shutdown_sync(&pdsc->wdtimer);
if (pdsc->health_work.func)
cancel_work_sync(&pdsc->health_work);
@@ -473,6 +474,7 @@ static void pdsc_restart_health_thread(struct pdsc *pdsc)
if (pdsc->pdev->is_virtfn)
return;
+ WRITE_ONCE(pdsc->health_stopped, false);
timer_setup(&pdsc->wdtimer, pdsc_wdtimer_cb, 0);
mod_timer(&pdsc->wdtimer, jiffies + 1);
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net-next] Revert "gtp: annotate PDP lookups under RTNL"
From: patchwork-bot+netdevbpf @ 2026-07-21 16:20 UTC (permalink / raw)
To: Simon Horman
Cc: pablo, laforge, andrew+netdev, davem, edumazet, kuba, pabeni,
osmocom-net-gprs, netdev
In-Reply-To: <20260708-gtp-rtnl-v1-1-218091f171bc@kernel.org>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 08 Jul 2026 20:02:05 +0100 you wrote:
> This reverts commit 0be5c3f0fbef3679f50f345b9237b8f9ea5de4e9.
>
> Commit 0be5c3f0fbef ("gtp: annotate PDP lookups under RTNL") added a
> lockdep_rtnl_is_held condition to hlist_for_each_rcu() loops to help
> insure that RTNL is held.
>
> Unfortunately, as pointed out by Pablo Neira Ayuso, the PDP context list
> is actually protected by the genetlink mutex. And so the condition
> is incorrect.
>
> [...]
Here is the summary with links:
- [net-next] Revert "gtp: annotate PDP lookups under RTNL"
https://git.kernel.org/netdev/net-next/c/860b693bca59
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next] net: phy: drop duplicated header include in mdio-device
From: patchwork-bot+netdevbpf @ 2026-07-21 16:20 UTC (permalink / raw)
To: Maxime Chevallier
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux, hkallweit1,
netdev, linux-kernel, thomas.petazzoni
In-Reply-To: <20260715201213.206180-1-maxime.chevallier@bootlin.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 15 Jul 2026 22:12:12 +0200 you wrote:
> During a tree-wide gpio include cleanup, the linux/gpio.h include was
> replaced with linux/gpio/consumer.h.
>
> mdio-device.c was already including that header, resulting in a
> duplicated inclusion. Let's drop it.
>
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
>
> [...]
Here is the summary with links:
- [net-next] net: phy: drop duplicated header include in mdio-device
https://git.kernel.org/netdev/net-next/c/7e7bd5158e98
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next] net/tcp: Prevent inlining tcp_syn_ack_timeout()
From: patchwork-bot+netdevbpf @ 2026-07-21 16:20 UTC (permalink / raw)
To: Emil Tsalapatis; +Cc: netdev, edumazet, ncardwell, kuniyu, davem, kuba, pabeni
In-Reply-To: <20260708180837.9507-1-emil@etsalapatis.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 8 Jul 2026 14:08:37 -0400 you wrote:
> The tcp_syn_ack_timeout() function gets inlined by Clang,
> preventing tracing. Since the call is not in the fast
> path, prevent it from being inlined.
>
> Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com>
> ---
> net/ipv4/tcp_timer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Here is the summary with links:
- [net-next] net/tcp: Prevent inlining tcp_syn_ack_timeout()
https://git.kernel.org/netdev/net-next/c/d05338c1290e
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v1 net 0/2] net: Fix two issues in sk_clone() error path.
From: patchwork-bot+netdevbpf @ 2026-07-21 16:20 UTC (permalink / raw)
To: Kuniyuki Iwashima
Cc: davem, edumazet, kuba, pabeni, willemb, horms, tavip, daniel, ast,
martin.lau, kuni1840, netdev
In-Reply-To: <20260709183315.965751-1-kuniyu@google.com>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 9 Jul 2026 18:31:38 +0000 you wrote:
> Sashiko reported issues in the sk_clone() error path.
>
> https://lore.kernel.org/bpf/20260709032007.9E4D61F000E9@smtp.kernel.org/
>
> This series fixes them.
>
> Note that Sashiko may point out the same issue for sk_bpf_storage,
> but the fix was already merged in the bpf tree:
>
> [...]
Here is the summary with links:
- [v1,net,1/2] soreuseport: Clear sk_reuseport_cb before failure in sk_clone().
https://git.kernel.org/netdev/net/c/98da8ce87dd5
- [v1,net,2/2] net: Call net_enable_timestamp() before failure in sk_clone().
https://git.kernel.org/netdev/net/c/d50557779257
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v7] net: gro: fix double aggregation of flush-marked skbs
From: patchwork-bot+netdevbpf @ 2026-07-21 16:20 UTC (permalink / raw)
To: =?utf-8?b?U2hpbWluZyBDaGVuZyAo5oiQ6K+X5piOKSA8c2hpbWluZy5jaGVuZ0BtZWRpYXRl?=,
=?utf-8?b?ay5jb20+?=
Cc: davem, edumazet, kuba, pabeni, horms, matthias.bgg,
angelogioacchino.delregno, willemb, daniel.zahka, alice, sd,
eilaimemedsnaimel, imv4bel, nbd, dsahern, netdev, linux-kernel,
linux-arm-kernel, linux-mediatek, stable, steffen.klassert,
lena.wang
In-Reply-To: <20260709014704.3625-1-shiming.cheng@mediatek.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 9 Jul 2026 09:46:39 +0800 you wrote:
> Commit 0ab03f353d36 ("net-gro: Fix GRO flush when receiving a GSO
> packet.") added a flush check to skb_gro_receive(), but
> skb_gro_receive_list() lacks the same validation.
>
> As a result, packets marked with NAPI_GRO_CB(skb)->flush may still be
> re-aggregated.
>
> [...]
Here is the summary with links:
- [v7] net: gro: fix double aggregation of flush-marked skbs
https://git.kernel.org/netdev/net/c/e751256486d0
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net] amd-xgbe: fix MAC_AUTO_SW handling in CL37 AN
From: patchwork-bot+netdevbpf @ 2026-07-21 16:20 UTC (permalink / raw)
To: Prashanth Kumar KR
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, netdev,
linux-kernel, stable, Shyam-sundar.S-k, patrick.oppenlander,
regressions
In-Reply-To: <20260709095006.3683940-1-prashanthkumar.k.r@amd.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 9 Jul 2026 15:20:06 +0530 you wrote:
> From: Prashanth Kumar KR <PrashanthKumar.K.R@amd.com>
>
> MAC_AUTO_SW (VR_MII_DIG_CTRL1 bit 9) enables automatic XPCS speed
> mode switching after CL37 auto-negotiation and is only meaningful in
> SGMII MAC mode. The original code unconditionally set this bit on
> every call to xgbe_an37_set(), including when called from
> xgbe_an37_disable() with enable=false. This left MAC_AUTO_SW=1 after
> AN was disabled, causing the XPCS to autonomously switch speed from
> stale AN state during subsequent mode changes, breaking SGMII speed
> negotiation on 1G copper SFP modules.
>
> [...]
Here is the summary with links:
- [net] amd-xgbe: fix MAC_AUTO_SW handling in CL37 AN
https://git.kernel.org/netdev/net/c/4bf22afe53a1
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ 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