* Re: [PATCH net v2] net: erspan: set lltx to avoid sch_direct_xmit deadlock
From: Eric Dumazet @ 2026-07-20 8:26 UTC (permalink / raw)
To: Ido Schimmel
Cc: Yun Zhou, dsahern, davem, kuba, pabeni, horms, netdev,
linux-kernel
In-Reply-To: <20260720075352.GA2233846@shredder>
On Mon, Jul 20, 2026 at 9:54 AM Ido Schimmel <idosch@nvidia.com> wrote:
>
> On Mon, Jul 13, 2026 at 11:14:35PM +0800, Yun Zhou wrote:
> > erspan_xmit() re-enters the network stack via ip_tunnel_xmit(), causing
> > nested acquisition of _xmit_lock on the underlay device while already
> > holding the ERSPAN device's _xmit_lock. Both are ARPHRD_ETHER and share
> > the same lockdep class, creating an ABBA deadlock:
> >
> > sch_direct_xmit [lock erspan] -> erspan_xmit -> ip_tunnel_xmit ->
> > ip_output -> __dev_queue_xmit -> sch_direct_xmit [lock underlay]
> >
> > Set dev->lltx = true so HARD_TX_LOCK() skips the spinlock for ERSPAN.
> > This is safe as erspan_xmit() has no shared mutable state: o_seqno is
> > atomic, stats use atomic_long_inc, and dst_cache is per-CPU. GRETAP,
> > the sibling device with identical xmit structure, already sets lltx.
>
> erspan_xmit() (unlike gre_tap_xmit()) is performing non-atomic
> __clear_bit() on shared tunnel flags and KCSAN will probably flag it.
>
> Eric had a patch [1] that changes erspan_xmit() to use a private copy of
> these flags. I think it's better to wait for Eric's patch to be merged
> before setting lltx.
>
> Eric, can you please submit v2 of your patch to net?
Sure, I can work on it today. Thanks!
>
> Also, doesn't ip6erspan suffer from the same problem? Please try to
> reproduce and fix.
>
> [1] https://lore.kernel.org/netdev/20260615140333.3161072-1-edumazet@google.com/
>
> >
> > Closes: https://syzkaller.appspot.com/bug?extid=9bda1b9fbb7fbdf9b62b
> > Reported-by: syzbot+9bda1b9fbb7fbdf9b62b@syzkaller.appspotmail.com
> > Fixes: 84e54fe0a5ea ("gre: introduce native tunnel support for ERSPAN")
> > Signed-off-by: Yun Zhou <yun.zhou@windriver.com>
> > ---
> > v2:
> > - change subject prefix to [PATCH net]
> >
> > net/ipv4/ip_gre.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
> > index 3efdfb4ffa21..9fbff16cda1d 100644
> > --- a/net/ipv4/ip_gre.c
> > +++ b/net/ipv4/ip_gre.c
> > @@ -1363,6 +1363,8 @@ static int erspan_tunnel_init(struct net_device *dev)
> > dev->features |= GRE_FEATURES;
> > dev->hw_features |= GRE_FEATURES;
> > dev->priv_flags |= IFF_LIVE_ADDR_CHANGE;
> > + /* Skip TX lock: xmit re-enters stack, risking ABBA with underlay */
> > + dev->lltx = true;
> > netif_keep_dst(dev);
> >
> > return ip_tunnel_init(dev);
> > --
> > 2.43.0
> >
^ permalink raw reply
* Re: [PATCH net v2] net: erspan: set lltx to avoid sch_direct_xmit deadlock
From: Zhou, Yun @ 2026-07-20 8:24 UTC (permalink / raw)
To: Ido Schimmel, edumazet
Cc: dsahern, davem, kuba, pabeni, horms, netdev, linux-kernel
In-Reply-To: <20260720075352.GA2233846@shredder>
On 7/20/26 15:53, Ido Schimmel wrote:
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
> On Mon, Jul 13, 2026 at 11:14:35PM +0800, Yun Zhou wrote:
>> erspan_xmit() re-enters the network stack via ip_tunnel_xmit(), causing
>> nested acquisition of _xmit_lock on the underlay device while already
>> holding the ERSPAN device's _xmit_lock. Both are ARPHRD_ETHER and share
>> the same lockdep class, creating an ABBA deadlock:
>>
>> sch_direct_xmit [lock erspan] -> erspan_xmit -> ip_tunnel_xmit ->
>> ip_output -> __dev_queue_xmit -> sch_direct_xmit [lock underlay]
>>
>> Set dev->lltx = true so HARD_TX_LOCK() skips the spinlock for ERSPAN.
>> This is safe as erspan_xmit() has no shared mutable state: o_seqno is
>> atomic, stats use atomic_long_inc, and dst_cache is per-CPU. GRETAP,
>> the sibling device with identical xmit structure, already sets lltx.
>
> erspan_xmit() (unlike gre_tap_xmit()) is performing non-atomic
> __clear_bit() on shared tunnel flags and KCSAN will probably flag it.
>
> Eric had a patch [1] that changes erspan_xmit() to use a private copy of
> these flags. I think it's better to wait for Eric's patch to be merged
> before setting lltx.
>
> Eric, can you please submit v2 of your patch to net?
>
> Also, doesn't ip6erspan suffer from the same problem? Please try to
> reproduce and fix.
>
Yes, ip6erspan has the same problem. I will fix it in v3.
Thanks,
Yun
^ permalink raw reply
* [PATCH v5 3/3] drm/xe/xe_ras: Report uncorrectable error events to userspace
From: Riana Tauro @ 2026-07-20 8:22 UTC (permalink / raw)
To: intel-xe, dri-devel, netdev
Cc: 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,
raag.jadav, maarten.lankhorst, mallesh.koujalagi, soham.purkait,
Riana Tauro
In-Reply-To: <20260720082208.2648279-5-riana.tauro@intel.com>
When the firmware reports uncorrectable errors in response to an AER
interrupt, deliver a drm-ras error event to userspace for each affected
component. Multiple errors for the same component within a single firmware
response are collapsed into one event to avoid duplicate notifications.
Signed-off-by: Riana Tauro <riana.tauro@intel.com>
---
drivers/gpu/drm/xe/xe_ras.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/xe/xe_ras.c b/drivers/gpu/drm/xe/xe_ras.c
index b08c664778ff..cd1307539912 100644
--- a/drivers/gpu/drm/xe/xe_ras.c
+++ b/drivers/gpu/drm/xe/xe_ras.c
@@ -449,6 +449,7 @@ enum xe_ras_recovery_action xe_ras_process_errors(struct xe_device *xe)
enum xe_ras_recovery_action final_action;
u32 remaining = XE_SYSCTRL_FLOOD_LIMIT;
struct xe_ras_get_soc_error response;
+ u8 sent = 0;
size_t rlen;
int ret;
@@ -492,6 +493,12 @@ enum xe_ras_recovery_action xe_ras_process_errors(struct xe_device *xe)
xe_info(xe, "[RAS]: %s %s detected\n", comp_to_str(component),
sev_to_str(severity));
+ /* Send event once per component */
+ if (!(sent & BIT(component))) {
+ sent |= BIT(component);
+ ras_send_error_event(xe, severity, component);
+ }
+
switch (component) {
case XE_RAS_COMP_CORE_COMPUTE:
action = handle_core_compute_errors(arr);
--
2.47.1
^ permalink raw reply related
* [PATCH v5 2/3] drm/xe/xe_ras: Report correctable error events to userspace
From: Riana Tauro @ 2026-07-20 8:22 UTC (permalink / raw)
To: intel-xe, dri-devel, netdev
Cc: 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,
raag.jadav, maarten.lankhorst, mallesh.koujalagi, soham.purkait,
Riana Tauro, Michal Wajdeczko
In-Reply-To: <20260720082208.2648279-5-riana.tauro@intel.com>
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.
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Riana Tauro <riana.tauro@intel.com>
---
v2: add warns for unexpected values from system controller (Michal)
send an event at most once per component for each interrupt (Raag)
use correct parameters for get_counter (Sashiko)
v3: move unsupported logs to drm_ras layer
use get_counter directly
use BITS_PER_TYPE
move the checks before detected log (Raag)
---
drivers/gpu/drm/xe/xe_drm_ras.c | 42 +++++++++++++++++++++
drivers/gpu/drm/xe/xe_drm_ras.h | 3 ++
drivers/gpu/drm/xe/xe_ras.c | 67 +++++++++++++++++++++++++++++++++
3 files changed, 112 insertions(+)
diff --git a/drivers/gpu/drm/xe/xe_drm_ras.c b/drivers/gpu/drm/xe/xe_drm_ras.c
index 7937d8ba0ed9..0287594e1026 100644
--- a/drivers/gpu/drm/xe/xe_drm_ras.c
+++ b/drivers/gpu/drm/xe/xe_drm_ras.c
@@ -185,6 +185,48 @@ static int register_nodes(struct xe_device *xe)
return ret;
}
+/**
+ * xe_drm_ras_event() - Report drm_ras error event to userspace
+ * @xe: xe device structure
+ * @component: error component (see &enum drm_xe_ras_error_component)
+ * @severity: error severity (see &enum drm_xe_ras_error_severity)
+ * @value: value of error counter
+ *
+ * Report an error-event to userspace.
+ */
+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) {
+ 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]);
+}
+
/**
* xe_drm_ras_init() - Initialize DRM RAS
* @xe: xe device instance
diff --git a/drivers/gpu/drm/xe/xe_drm_ras.h b/drivers/gpu/drm/xe/xe_drm_ras.h
index 365c70e93e82..add96bf1a7ab 100644
--- a/drivers/gpu/drm/xe/xe_drm_ras.h
+++ b/drivers/gpu/drm/xe/xe_drm_ras.h
@@ -5,11 +5,14 @@
#ifndef _XE_DRM_RAS_H_
#define _XE_DRM_RAS_H_
+#include <linux/types.h>
+
struct xe_device;
#define for_each_error_severity(i) \
for (i = 0; i < DRM_XE_RAS_ERR_SEV_MAX; i++)
int xe_drm_ras_init(struct xe_device *xe);
+void xe_drm_ras_event(struct xe_device *xe, u8 component, u8 severity, u32 value);
#endif
diff --git a/drivers/gpu/drm/xe/xe_ras.c b/drivers/gpu/drm/xe/xe_ras.c
index a31e06b8aa67..b08c664778ff 100644
--- a/drivers/gpu/drm/xe/xe_ras.c
+++ b/drivers/gpu/drm/xe/xe_ras.c
@@ -90,6 +90,8 @@ static const char * const gpu_health_states[] = {
};
static_assert(ARRAY_SIZE(gpu_health_states) == XE_RAS_HEALTH_MAX);
+static int get_counter(struct xe_device *xe, struct xe_ras_error_class *counter, u32 *value);
+
static u8 drm_to_xe_ras_severity(u8 severity)
{
switch (severity) {
@@ -102,6 +104,18 @@ static u8 drm_to_xe_ras_severity(u8 severity)
}
}
+static u8 xe_to_drm_ras_severity(u8 severity)
+{
+ switch (severity) {
+ case XE_RAS_SEV_CORRECTABLE:
+ return DRM_XE_RAS_ERR_SEV_CORRECTABLE;
+ case XE_RAS_SEV_UNCORRECTABLE:
+ return DRM_XE_RAS_ERR_SEV_UNCORRECTABLE;
+ default:
+ return DRM_XE_RAS_ERR_SEV_MAX;
+ }
+}
+
static u8 drm_to_xe_ras_component(u8 component)
{
switch (component) {
@@ -120,6 +134,24 @@ static u8 drm_to_xe_ras_component(u8 component)
}
}
+static u8 xe_to_drm_ras_component(u8 component)
+{
+ switch (component) {
+ case XE_RAS_COMP_DEVICE_MEMORY:
+ return DRM_XE_RAS_ERR_COMP_DEVICE_MEMORY;
+ case XE_RAS_COMP_CORE_COMPUTE:
+ return DRM_XE_RAS_ERR_COMP_CORE_COMPUTE;
+ case XE_RAS_COMP_PCIE:
+ return DRM_XE_RAS_ERR_COMP_PCIE;
+ case XE_RAS_COMP_FABRIC:
+ return DRM_XE_RAS_ERR_COMP_FABRIC;
+ case XE_RAS_COMP_SOC_INTERNAL:
+ return DRM_XE_RAS_ERR_COMP_SOC_INTERNAL;
+ default:
+ return DRM_XE_RAS_ERR_COMP_MAX;
+ }
+}
+
static int ras_status_to_errno(u32 status)
{
switch (status) {
@@ -218,6 +250,26 @@ static void ras_usp_aer_init(struct xe_device *xe)
dev_dbg(&usp->dev, "Uncorrectable Internal Errors downgraded and unmasked\n");
}
+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);
+}
+
static u8 handle_core_compute_errors(struct xe_ras_error_array *arr)
{
struct xe_ras_compute_error *error_info = (void *)arr->details;
@@ -312,8 +364,10 @@ void xe_ras_counter_threshold_crossed(struct xe_device *xe,
struct xe_ras_threshold_crossed *pending = (void *)&response->data;
struct xe_ras_error_class *errors = pending->counters;
u32 id, ncounters = pending->ncounters;
+ u8 sent = 0;
BUILD_BUG_ON(sizeof(response->data) < sizeof(*pending));
+ BUILD_BUG_ON(BITS_PER_TYPE(sent) < XE_RAS_COMP_MAX);
xe_device_assert_mem_access(xe);
if (!ncounters || ncounters > XE_RAS_NUM_COUNTERS)
@@ -327,8 +381,21 @@ void xe_ras_counter_threshold_crossed(struct xe_device *xe,
severity = errors[id].common.severity;
component = errors[id].common.component;
+ if (severity != XE_RAS_SEV_CORRECTABLE) {
+ xe_warn(xe, "sysctrl: unexpected severity %s (%u)\n", sev_to_str(severity),
+ severity);
+ continue;
+ }
+
xe_warn(xe, "[RAS]: %s %s detected\n",
comp_to_str(component), sev_to_str(severity));
+
+ /* Send event once per component */
+ if (sent & BIT(component))
+ continue;
+ sent |= BIT(component);
+
+ ras_send_error_event(xe, severity, component);
}
}
--
2.47.1
^ permalink raw reply related
* [PATCH v5 1/3] drm/drm_ras: Add drm_ras netlink error event
From: Riana Tauro @ 2026-07-20 8:22 UTC (permalink / raw)
To: intel-xe, dri-devel, netdev
Cc: 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,
raag.jadav, maarten.lankhorst, mallesh.koujalagi, soham.purkait,
Riana Tauro, Zack McKevitt, Lijo Lazar, Hawking Zhang,
David S. Miller, Paolo Abeni, Eric Dumazet
In-Reply-To: <20260720082208.2648279-5-riana.tauro@intel.com>
Define a new netlink event 'error-event' and a new multicast group
'error-report' in drm_ras. Each event contains device name, node and
error information to identify the error triggering the event.
Add drm_ras_nl_error_event() to trigger an event from the driver.
Userspace must subscribe to 'error-report' to receive 'error-event'
notifications.
Usage:
$ sudo ynl --family drm_ras --subscribe error-report
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Zack McKevitt <zachary.mckevitt@oss.qualcomm.com>
Cc: Lijo Lazar <lijo.lazar@amd.com>
Cc: Hawking Zhang <Hawking.Zhang@amd.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Eric Dumazet <edumazet@google.com>
Signed-off-by: Riana Tauro <riana.tauro@intel.com>
Reviewed-by: Raag Jadav <raag.jadav@intel.com>
---
v2: remove redundant initialization
remove unnecessary space
use ynl in commit message and doc (Raag)
simplify doc for error-event attrs
v3: rename error-notify to error-report
Replace notify with report across the file (Raag)
v4: send event to all network namespaces (Sashiko)
remove has_listeners check
---
Documentation/gpu/drm-ras.rst | 21 ++++++
Documentation/netlink/specs/drm_ras.yaml | 48 ++++++++++++++
drivers/gpu/drm/drm_ras.c | 84 ++++++++++++++++++++++++
drivers/gpu/drm/drm_ras_nl.c | 6 ++
drivers/gpu/drm/drm_ras_nl.h | 4 ++
include/drm/drm_ras.h | 5 ++
include/uapi/drm/drm_ras.h | 15 +++++
7 files changed, 183 insertions(+)
diff --git a/Documentation/gpu/drm-ras.rst b/Documentation/gpu/drm-ras.rst
index 83c21853b74b..406e4c49bac1 100644
--- a/Documentation/gpu/drm-ras.rst
+++ b/Documentation/gpu/drm-ras.rst
@@ -56,6 +56,7 @@ User space tools can:
``node-id`` and ``error-id`` as parameters.
* Clear specific error counters with the ``clear-error-counter`` command, using both
``node-id`` and ``error-id`` as parameters.
+* Subscribe to the ``error-report`` multicast group to receive ``error-event``.
YAML-based Interface
--------------------
@@ -111,3 +112,23 @@ Example: Clear an error counter for a given node
sudo ynl --family drm_ras --do clear-error-counter --json '{"node-id":0, "error-id":1}'
None
+
+Example: Subscribe to ``error-report`` multicast group
+
+.. code-block:: bash
+
+ sudo ynl --family drm_ras --output-json --subscribe error-report
+
+.. code-block:: json
+
+ {
+ "name": "error-event",
+ "msg": {
+ "device-name": "0000:03:00.0",
+ "node-id": 1,
+ "node-name": "uncorrectable-errors",
+ "error-id": 1,
+ "error-name": "error_name1",
+ "error-value": 1
+ }
+ }
diff --git a/Documentation/netlink/specs/drm_ras.yaml b/Documentation/netlink/specs/drm_ras.yaml
index e113056f8c01..8aed3d4515e5 100644
--- a/Documentation/netlink/specs/drm_ras.yaml
+++ b/Documentation/netlink/specs/drm_ras.yaml
@@ -69,6 +69,33 @@ attribute-sets:
name: error-value
type: u32
doc: Current value of the requested error counter.
+ -
+ name: error-event-attrs
+ attributes:
+ -
+ name: device-name
+ type: string
+ doc: Device (PCI BDF, UUID) that reported the error.
+ -
+ name: node-id
+ type: u32
+ doc: ID of the node that reported the error.
+ -
+ name: node-name
+ type: string
+ doc: Name of the node that reported the error.
+ -
+ name: error-id
+ type: u32
+ doc: ID of the error counter.
+ -
+ name: error-name
+ type: string
+ doc: Name of the error.
+ -
+ name: error-value
+ type: u32
+ doc: Current value of the error counter.
operations:
list:
@@ -124,3 +151,24 @@ operations:
do:
request:
attributes: *id-attrs
+ -
+ name: error-event
+ doc: >-
+ Report an error event to userspace.
+ The event includes the device, node and error information
+ of the error that triggered the event.
+ attribute-set: error-event-attrs
+ mcgrp: error-report
+ event:
+ attributes:
+ - device-name
+ - node-id
+ - node-name
+ - error-id
+ - error-name
+ - error-value
+
+mcast-groups:
+ list:
+ -
+ name: error-report
diff --git a/drivers/gpu/drm/drm_ras.c b/drivers/gpu/drm/drm_ras.c
index d6eab29a1394..0b77e4358ea8 100644
--- a/drivers/gpu/drm/drm_ras.c
+++ b/drivers/gpu/drm/drm_ras.c
@@ -41,6 +41,11 @@
* Userspace must provide Node ID, Error ID.
* Clears specific error counter of a node if supported.
*
+ * 4. ERROR_REPORT: Subscribe to this multicast group to receive error events
+ *
+ * 5. ERROR_EVENT: Report an error event to userspace. The event contains device, node
+ * and error information that triggered the event.
+ *
* Node registration:
*
* - drm_ras_node_register(): Registers a new node and assigns
@@ -186,6 +191,34 @@ static int msg_reply_value(struct sk_buff *msg, u32 error_id,
value);
}
+static int msg_put_error_event_attrs(struct sk_buff *msg, struct drm_ras_node *node,
+ u32 error_id, const char *error_name, u32 value)
+{
+ int ret;
+
+ ret = nla_put_string(msg, DRM_RAS_A_ERROR_EVENT_ATTRS_DEVICE_NAME, node->device_name);
+ if (ret)
+ return ret;
+
+ ret = nla_put_u32(msg, DRM_RAS_A_ERROR_EVENT_ATTRS_NODE_ID, node->id);
+ if (ret)
+ return ret;
+
+ ret = nla_put_string(msg, DRM_RAS_A_ERROR_EVENT_ATTRS_NODE_NAME, node->node_name);
+ if (ret)
+ return ret;
+
+ ret = nla_put_u32(msg, DRM_RAS_A_ERROR_EVENT_ATTRS_ERROR_ID, error_id);
+ if (ret)
+ return ret;
+
+ ret = nla_put_string(msg, DRM_RAS_A_ERROR_EVENT_ATTRS_ERROR_NAME, error_name);
+ if (ret)
+ return ret;
+
+ return nla_put_u32(msg, DRM_RAS_A_ERROR_EVENT_ATTRS_ERROR_VALUE, value);
+}
+
static int doit_reply_value(struct genl_info *info, u32 node_id,
u32 error_id)
{
@@ -222,6 +255,57 @@ static int doit_reply_value(struct genl_info *info, u32 node_id,
return genlmsg_reply(msg, info);
}
+/**
+ * drm_ras_nl_error_event() - Report an error event
+ * @node: Node structure
+ * @error_id: ID of the error
+ * @error_name: Name of the error
+ * @value: Value associated with the error
+ *
+ * Report an error-event to userspace using the error-report multicast group.
+ *
+ * Return: 0 on success, or negative errno on failure.
+ */
+int drm_ras_nl_error_event(struct drm_ras_node *node, u32 error_id, const char *error_name,
+ u32 value)
+{
+ struct genl_info info;
+ struct sk_buff *msg;
+ struct nlattr *hdr;
+ int ret;
+
+ if (!error_name)
+ return -EINVAL;
+
+ genl_info_init_ntf(&info, &drm_ras_nl_family, DRM_RAS_CMD_ERROR_EVENT);
+
+ msg = genlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
+ if (!msg)
+ return -ENOMEM;
+
+ hdr = genlmsg_iput(msg, &info);
+ if (!hdr) {
+ ret = -EMSGSIZE;
+ goto free_msg;
+ }
+
+ ret = msg_put_error_event_attrs(msg, node, error_id, error_name, value);
+ if (ret)
+ goto cancel_msg;
+
+ genlmsg_end(msg, hdr);
+ genlmsg_multicast_allns(&drm_ras_nl_family, msg, 0, DRM_RAS_NLGRP_ERROR_REPORT);
+
+ return 0;
+
+cancel_msg:
+ genlmsg_cancel(msg, hdr);
+free_msg:
+ nlmsg_free(msg);
+ return ret;
+}
+EXPORT_SYMBOL(drm_ras_nl_error_event);
+
/**
* drm_ras_nl_get_error_counter_dumpit() - Dump all Error Counters
* @skb: Netlink message buffer
diff --git a/drivers/gpu/drm/drm_ras_nl.c b/drivers/gpu/drm/drm_ras_nl.c
index dea1c1b2494e..9d3123cc9f9c 100644
--- a/drivers/gpu/drm/drm_ras_nl.c
+++ b/drivers/gpu/drm/drm_ras_nl.c
@@ -58,6 +58,10 @@ static const struct genl_split_ops drm_ras_nl_ops[] = {
},
};
+static const struct genl_multicast_group drm_ras_nl_mcgrps[] = {
+ [DRM_RAS_NLGRP_ERROR_REPORT] = { "error-report", },
+};
+
struct genl_family drm_ras_nl_family __ro_after_init = {
.name = DRM_RAS_FAMILY_NAME,
.version = DRM_RAS_FAMILY_VERSION,
@@ -66,4 +70,6 @@ struct genl_family drm_ras_nl_family __ro_after_init = {
.module = THIS_MODULE,
.split_ops = drm_ras_nl_ops,
.n_split_ops = ARRAY_SIZE(drm_ras_nl_ops),
+ .mcgrps = drm_ras_nl_mcgrps,
+ .n_mcgrps = ARRAY_SIZE(drm_ras_nl_mcgrps),
};
diff --git a/drivers/gpu/drm/drm_ras_nl.h b/drivers/gpu/drm/drm_ras_nl.h
index a398643572a5..03ec275aca92 100644
--- a/drivers/gpu/drm/drm_ras_nl.h
+++ b/drivers/gpu/drm/drm_ras_nl.h
@@ -21,6 +21,10 @@ int drm_ras_nl_get_error_counter_dumpit(struct sk_buff *skb,
int drm_ras_nl_clear_error_counter_doit(struct sk_buff *skb,
struct genl_info *info);
+enum {
+ DRM_RAS_NLGRP_ERROR_REPORT,
+};
+
extern struct genl_family drm_ras_nl_family;
#endif /* _LINUX_DRM_RAS_GEN_H */
diff --git a/include/drm/drm_ras.h b/include/drm/drm_ras.h
index 0beede3ddc4e..ee2caa0edc6f 100644
--- a/include/drm/drm_ras.h
+++ b/include/drm/drm_ras.h
@@ -80,9 +80,14 @@ struct drm_device;
#if IS_ENABLED(CONFIG_DRM_RAS)
int drm_ras_node_register(struct drm_ras_node *node);
void drm_ras_node_unregister(struct drm_ras_node *node);
+int drm_ras_nl_error_event(struct drm_ras_node *node, u32 error_id, const char *error_name,
+ u32 value);
#else
static inline int drm_ras_node_register(struct drm_ras_node *node) { return 0; }
static inline void drm_ras_node_unregister(struct drm_ras_node *node) { }
+static inline int drm_ras_nl_error_event(struct drm_ras_node *node, u32 error_id,
+ const char *error_name, u32 value)
+{ return 0; }
#endif
#endif
diff --git a/include/uapi/drm/drm_ras.h b/include/uapi/drm/drm_ras.h
index 218a3ee86805..eab8231aa87c 100644
--- a/include/uapi/drm/drm_ras.h
+++ b/include/uapi/drm/drm_ras.h
@@ -38,13 +38,28 @@ enum {
DRM_RAS_A_ERROR_COUNTER_ATTRS_MAX = (__DRM_RAS_A_ERROR_COUNTER_ATTRS_MAX - 1)
};
+enum {
+ DRM_RAS_A_ERROR_EVENT_ATTRS_DEVICE_NAME = 1,
+ DRM_RAS_A_ERROR_EVENT_ATTRS_NODE_ID,
+ DRM_RAS_A_ERROR_EVENT_ATTRS_NODE_NAME,
+ DRM_RAS_A_ERROR_EVENT_ATTRS_ERROR_ID,
+ DRM_RAS_A_ERROR_EVENT_ATTRS_ERROR_NAME,
+ DRM_RAS_A_ERROR_EVENT_ATTRS_ERROR_VALUE,
+
+ __DRM_RAS_A_ERROR_EVENT_ATTRS_MAX,
+ DRM_RAS_A_ERROR_EVENT_ATTRS_MAX = (__DRM_RAS_A_ERROR_EVENT_ATTRS_MAX - 1)
+};
+
enum {
DRM_RAS_CMD_LIST_NODES = 1,
DRM_RAS_CMD_GET_ERROR_COUNTER,
DRM_RAS_CMD_CLEAR_ERROR_COUNTER,
+ DRM_RAS_CMD_ERROR_EVENT,
__DRM_RAS_CMD_MAX,
DRM_RAS_CMD_MAX = (__DRM_RAS_CMD_MAX - 1)
};
+#define DRM_RAS_MCGRP_ERROR_REPORT "error-report"
+
#endif /* _UAPI_LINUX_DRM_RAS_H */
--
2.47.1
^ permalink raw reply related
* [PATCH v5 0/3] Add drm_ras netlink error event support
From: Riana Tauro @ 2026-07-20 8:22 UTC (permalink / raw)
To: intel-xe, dri-devel, netdev
Cc: 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,
raag.jadav, maarten.lankhorst, mallesh.koujalagi, soham.purkait,
Riana Tauro
Define a new netlink event 'error-event' and a new multicast group
'error-report' in drm_-as. Each event contains device name, node and
error information to identify the error triggering the event.
Add drm_ras_nl_error_event() to trigger an event from the driver.
Wire this support to xe_drm_ras to report to userspace whenever a
correctable/uncorrectable error occurs on CRI.
$ sudo ynl --family drm_ras --output-json --subscribe error-report
{
"name": "error-event",
"msg": {
"device-name": "0000:03:00.0",
"node-id": 1,
"node-name": "uncorrectable-errors",
"error-id": 1,
"error-name": "core-compute",
"error-value": 1
}
}
Rev2: use ynl in document and commit message
fix cosmetic review comments
simplify caller
Rev3: replace error-event with error-report
had has_drm_ras check
add support for correctable errors in CRI
Rev4: send an event at most once per component for each interrupt
add xe_warn for unexpected values from firmware
fix sashiko reported issues
Rev5: Remove has_listeners
send netlink event to all network namespaces
Riana Tauro (3):
drm/drm_ras: Add drm_ras netlink error event
drm/xe/xe_ras: Report correctable error events to userspace
drm/xe/xe_ras: Report uncorrectable error events to userspace
Documentation/gpu/drm-ras.rst | 21 ++++++
Documentation/netlink/specs/drm_ras.yaml | 48 ++++++++++++++
drivers/gpu/drm/drm_ras.c | 84 ++++++++++++++++++++++++
drivers/gpu/drm/drm_ras_nl.c | 6 ++
drivers/gpu/drm/drm_ras_nl.h | 4 ++
drivers/gpu/drm/xe/xe_drm_ras.c | 42 ++++++++++++
drivers/gpu/drm/xe/xe_drm_ras.h | 3 +
drivers/gpu/drm/xe/xe_ras.c | 74 +++++++++++++++++++++
include/drm/drm_ras.h | 5 ++
include/uapi/drm/drm_ras.h | 15 +++++
10 files changed, 302 insertions(+)
--
2.47.1
^ permalink raw reply
* [PATCH net v4] sctp: socket: refactor sctp_skb_recv_datagram to use ERR_PTR
From: luoqing @ 2026-07-20 8:21 UTC (permalink / raw)
To: marcelo.leitner, lucien.xin, davem, edumazet, kuba, pabeni
Cc: horms, linux-sctp, netdev, linux-kernel
From: Qing Luo <luoqing@kylinos.cn>
The err output parameter in sctp_skb_recv_datagram() is passed to
callers but never validated, making error reporting unreliable.
Remove it and use ERR_PTR to encode errors directly in the return
value, which is the standard kernel pattern for this case.
Signed-off-by: Qing Luo <luoqing@kylinos.cn>
---
include/net/sctp/sctp.h | 2 +-
net/sctp/socket.c | 20 ++++++++++----------
net/sctp/ulpevent.c | 5 ++---
3 files changed, 13 insertions(+), 14 deletions(-)
diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
index d50c27812504..b86d50d6b146 100644
--- a/include/net/sctp/sctp.h
+++ b/include/net/sctp/sctp.h
@@ -97,7 +97,7 @@ void sctp_sock_rfree(struct sk_buff *skb);
extern struct percpu_counter sctp_sockets_allocated;
int sctp_asconf_mgmt(struct sctp_sock *, struct sctp_sockaddr_entry *);
-struct sk_buff *sctp_skb_recv_datagram(struct sock *, int, int *);
+struct sk_buff *sctp_skb_recv_datagram(struct sock *sk, int flags);
typedef int (*sctp_callback_t)(struct sctp_endpoint *, struct sctp_transport *, void *);
void sctp_transport_walk_start(struct rhashtable_iter *iter);
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index c7b9e325ec1c..2deaa498e6cf 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -2123,9 +2123,11 @@ static int sctp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
goto out;
}
- skb = sctp_skb_recv_datagram(sk, flags, &err);
- if (!skb)
+ skb = sctp_skb_recv_datagram(sk, flags);
+ if (IS_ERR(skb)) {
+ err = PTR_ERR(skb);
goto out;
+ }
/* Get the total length of the skb including any skb's in the
* frag_list.
@@ -9082,7 +9084,7 @@ static int sctp_wait_for_packet(struct sock *sk, int *err, long *timeo_p)
* Note: This is pretty much the same routine as in core/datagram.c
* with a few changes to make lksctp work.
*/
-struct sk_buff *sctp_skb_recv_datagram(struct sock *sk, int flags, int *err)
+struct sk_buff *sctp_skb_recv_datagram(struct sock *sk, int flags)
{
int error;
struct sk_buff *skb;
@@ -9117,21 +9119,19 @@ struct sk_buff *sctp_skb_recv_datagram(struct sock *sk, int flags, int *err)
if (error)
goto no_packet;
- if (sk->sk_shutdown & RCV_SHUTDOWN)
+ if (sk->sk_shutdown & RCV_SHUTDOWN) {
+ error = 0;
break;
-
+ }
/* User doesn't want to wait. */
error = -EAGAIN;
if (!timeo)
goto no_packet;
- } while (sctp_wait_for_packet(sk, err, &timeo) == 0);
-
- return NULL;
+ } while (sctp_wait_for_packet(sk, &error, &timeo) == 0);
no_packet:
- *err = error;
- return NULL;
+ return ERR_PTR(error);
}
/* If sndbuf has changed, wake up per association sndbuf waiters. */
diff --git a/net/sctp/ulpevent.c b/net/sctp/ulpevent.c
index 8920ca92a011..21ae0adbaeef 100644
--- a/net/sctp/ulpevent.c
+++ b/net/sctp/ulpevent.c
@@ -1061,10 +1061,9 @@ void sctp_ulpevent_read_nxtinfo(const struct sctp_ulpevent *event,
struct sock *sk)
{
struct sk_buff *skb;
- int err;
- skb = sctp_skb_recv_datagram(sk, MSG_PEEK | MSG_DONTWAIT, &err);
- if (skb != NULL) {
+ skb = sctp_skb_recv_datagram(sk, MSG_PEEK | MSG_DONTWAIT);
+ if (!IS_ERR_OR_NULL(skb)) {
__sctp_ulpevent_read_nxtinfo(sctp_skb2event(skb),
msghdr, skb);
/* Just release refcount here. */
--
2.25.1
>> I think it's used at [1] in sctp_recvmsg():
>>
>> skb = sctp_skb_recv_datagram(sk, flags, &err);
>> if (!skb)
>> goto out;
> Would it make more sense to ERR_PTR() etc ?
>
>
> David
Yes, you are right. The current implementation returns a negative error
code directly via err, but it would be cleaner to use ERR_PTR() to
unify the error path with other datagram receivers.
I will refactor this part in v4:
>
>
>> ...
>>
>> out:
>> release_sock(sk);
>> return err; <------ [1]
^ permalink raw reply related
* Re: [PATCH] vsock: use sock_error() to consume sk_err after connect timeout
From: Stefano Garzarella @ 2026-07-20 8:17 UTC (permalink / raw)
To: Nguyen Dinh Phi
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, syzbot+1b2c9c4a0f8708082678, virtualization, netdev,
linux-kernel
In-Reply-To: <20260719220103.684489-1-phind.uet@gmail.com>
On Mon, Jul 20, 2026 at 05:57:47AM +0800, Nguyen Dinh Phi wrote:
>After vsock_connect() exits the wait loop due to sk->sk_err being
>set, the error was read but not cleared. This left sk->sk_err set
>for subsequent operations.
So, is this a fix? If yes, we should put a Fixes tag.
Also, can you describe how to trigger the issue?
Because I see this in vsock_connect(), so I thought it was in some way
already handled:
/* sk_err might have been set as a result of an earlier
* (failed) connect attempt.
*/
sk->sk_err = 0;
>Switch to sock_error() which atomically reads and clears sk->sk_err,
>so the error is consumed when returned.
>
>Signed-off-by: Nguyen Dinh Phi <phind.uet@gmail.com>
>Reported-by: syzbot+1b2c9c4a0f8708082678@syzkaller.appspotmail.com
Can you explain how this patch fixes that issue?
(this should be the first information to be put in the commit message
IMHO)
I'd like to understand better if this is a fix of real bug or just an
improvement to the code (which is fine by me).
Thanks,
Stefano
>---
> net/vmw_vsock/af_vsock.c | 7 ++-----
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
>diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
>index 622dbd046799..43eddc33ed12 100644
>--- a/net/vmw_vsock/af_vsock.c
>+++ b/net/vmw_vsock/af_vsock.c
>@@ -1847,14 +1847,11 @@ static int vsock_connect(struct socket *sock, struct sockaddr_unsized *addr,
> prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
> }
>
>- if (sk->sk_err) {
>- err = -sk->sk_err;
>+ err = sock_error(sk);
>+ if (err) {
> sk->sk_state = TCP_CLOSE;
> sock->state = SS_UNCONNECTED;
>- } else {
>- err = 0;
> }
>-
> out_wait:
> finish_wait(sk_sleep(sk), &wait);
> out:
>--
>2.53.0
>
^ permalink raw reply
* [PATCH v11] mm/page_alloc: boost watermarks on atomic allocation failure
From: Qiliang Yuan @ 2026-07-20 8:15 UTC (permalink / raw)
To: Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Axel Rasmussen, Yuanchu Xie,
Wei Xu, Brendan Jackman, Johannes Weiner, Zi Yan, Lance Yang,
SeongJae Park, Matthew Wilcox
Cc: netdev, Qiliang Yuan, Jing Wu
Atomic allocations (GFP_ATOMIC) are prone to failure under heavy memory
pressure as they cannot enter direct reclaim.
Handle these failures by introducing a watermark boost mechanism for
atomic requests. Refactor boost_watermark() using an internal helper to
support both fragmentation and atomic paths. Apply zone-proportional
boosts (~0.1% of managed pages) for atomic allocations, while
decoupling it from watermark_boost_factor.
Implement boost_zones_for_atomic() to iterate through and boost all
eligible zones in the zonelist, respecting nodemasks. Use a per-zone
1-second debounce timer via last_boost_jiffies to prevent excessive
boosting. Check and update the debounce timestamp under zone->lock,
alongside the watermark modification, so concurrent callers on other
CPUs cannot all observe a stale timestamp and pile onto the same zone
within the same window. Verify with lockdep. Integrate the mechanism
into the page allocation slowpath specifically for order-0 GFP_ATOMIC
requests.
This approach reuses existing infrastructure and ensures emergency
reserves even if fragmentation boosting is disabled.
The mechanism is bounded by construction. Each zone accepts at most
one boost per second (the debounce timer), and zone->watermark_boost
is clamped to zone->_watermark[WMARK_HIGH] / 10 regardless of how
long the atomic pressure lasts or how many zones are boosted in a
single slowpath call. Worst case, sustained atomic pressure across
all zones in a zonelist adds at most one extra kswapd wakeup per zone
per second, and the boost on any single zone cannot exceed 10% of
that zone's high watermark. It cannot run away or starve unrelated
allocations beyond that ceiling.
This failure signature keeps recurring in production: a host running
a downstream 4.19 kernel logged 144 order-0 GFP_ATOMIC failures over a
4h15m window, all through the same NIC driver receive softirq path,
across several unrelated network-facing services on the box. This
confirms the underlying problem is real and ongoing. It does not by
itself measure this patch's effect, since the fix has not been
deployed on that fleet yet.
Allocation failure logs:
[38535644.718700] node 0: slabs: 1031, objs: 43328, free: 0
[38535644.725059] node 1: slabs: 339, objs: 17616, free: 317
[38535645.428345] SLUB: Unable to allocate memory on node -1, gfp=0x480020(GFP_ATOMIC)
[38535645.436888] cache: skbuff_head_cache, object size: 232, buffer size: 256, default order: 2, min order: 0
[38535645.447664] node 0: slabs: 940, objs: 40864, free: 144
[38535645.454026] node 1: slabs: 322, objs: 19168, free: 383
[38535645.556122] SLUB: Unable to allocate memory on node -1, gfp=0x480020(GFP_ATOMIC)
[38535645.564576] cache: skbuff_head_cache, object size: 232, buffer size: 256, default order: 2, min order: 0
[38535649.655523] warn_alloc: 59 callbacks suppressed
[38535649.655527] swapper/100: page allocation failure: order:0, mode:0x480020(GFP_ATOMIC), nodemask=(null)
[38535649.671692] swapper/100 cpuset=/ mems_allowed=0-1
Signed-off-by: Qiliang Yuan <realwujing@gmail.com>
Signed-off-by: Jing Wu <realwujing@gmail.com>
Acked-by: SeongJae Park <sj@kernel.org>
---
V10 -> V11:
- Fix a debounce race: last_boost_jiffies was checked and updated
outside zone->lock, so concurrent CPUs handling a multi-queue NIC
RX storm could all pass the once-per-second check for the same
zone before either updated the timestamp. Move the check-and-set
under zone->lock alongside the watermark update.
- Add production evidence of the failure signature recurring (see
commit message) in response to Vlastimil's repeated request (v2,
v6, v10) for real-world data on whether this problem is real and
whether the fix helps.
- Drop Vlastimil's Acked-by: he took it back in review of v10,
noting the v10 changes were not trivial. Not resending solely to
drop the tag, per his request; folding it into this update instead.
- Cc netdev and add Matthew Wilcox, per Andrew Morton's (v1, v5) and
Wilcox's (v1) requests to involve the networking maintainers, which
never actually happened in v1-v10.
V9 -> V10:
- Refactor watermark boosting into mechanism (__boost_watermark) and
policy logic.
- Decouple Atomic boost from watermark_boost_factor to ensure
emergency reserves.
- Simplify Atomic boost calculation to ~0.1% of managed pages with a
10% high-WM cap.
- Boost all eligible zones in the zonelist while respecting
nodemasks.
V8 -> V9:
- Use mult_frac() for boost calculation. (SJ)
- Add !can_direct_reclaim check. (Vlastimil)
- Code cleanup: naming, scope, and line limits. (SJ)
- Update tags: Add Vlastimil's Acked-by.
V7 -> V8:
- Use spin_lock_irqsave() to prevent inconsistent lock state
(softirq-on vs in-softirq) as reported by LKP.
V6 -> V7:
- Use local variable for boost_amount to improve code readability.
- Add zone->lock protection in boost_zones_for_atomic().
- Add lockdep assertion in boost_watermark() to prevent locking
mistakes.
- Remove redundant boost call at fail label due to 1-second
debounce.
V5 -> V6:
- Replace magic number ">> 10" with ATOMIC_BOOST_SCALE_SHIFT define.
- Add documentation explaining 0.1% zone size boost rationale.
V4 -> V5:
- Simplify to use native boost_watermark() instead of custom logic.
V3 -> V4:
- Add watermark_scale_boost and gradual decay via balance_pgdat.
V2 -> V3:
- Move debounce timer to per-zone to avoid cross-node interference.
- Optimize candidate zone selection to reduce global reclaim
pressure.
V1 -> V2:
- Add basic debounce logic and scale boosting strength based on zone
size.
v10: https://lore.kernel.org/r/20260214-wujing-mm-page_alloc-v8-v10-1-bdfea431fd97@gmail.com
v9: https://lore.kernel.org/r/20260213-wujing-mm-page_alloc-v8-v9-1-cd99f3a6cb70@gmail.com
v8: https://lore.kernel.org/r/20260212-wujing-mm-page_alloc-v8-v8-1-daba38990cd3@gmail.com
v7: https://lore.kernel.org/all/20260123064231.250767-1-realwujing@gmail.com/
v5: https://lore.kernel.org/all/20260121065740.35616-1-realwujing@gmail.com/
v4: https://lore.kernel.org/all/tencent_D23BFCB69EA088C55AFAF89F926036743E0A@qq.com/
v3: https://lore.kernel.org/all/tencent_44B556221480D8371FBC534ACCF3CE2C8707@qq.com/
v2: https://lore.kernel.org/all/tencent_6FE67BA7BE8376AB038A71ACAD4FF8A90006@qq.com/
v1: https://lore.kernel.org/all/tencent_9DB6637676D639B4B7AEA09CC6A6F9E49D0A@qq.com/
---
include/linux/mmzone.h | 1 +
mm/page_alloc.c | 80 ++++++++++++++++++++++++++++++++++++++++++++------
2 files changed, 72 insertions(+), 9 deletions(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 75ef7c9f9307f..8e37e4e6765b5 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -882,6 +882,7 @@ struct zone {
/* zone watermarks, access with *_wmark_pages(zone) macros */
unsigned long _watermark[NR_WMARK];
unsigned long watermark_boost;
+ unsigned long last_boost_jiffies;
unsigned long nr_reserved_highatomic;
unsigned long nr_free_highatomic;
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index c380f063e8b7b..4517e2c1310ee 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2158,12 +2158,15 @@ bool pageblock_unisolate_and_move_free_pages(struct zone *zone, struct page *pag
#endif /* CONFIG_MEMORY_ISOLATION */
-static inline bool boost_watermark(struct zone *zone)
+/*
+ * Helper for boosting watermarks. Called with zone->lock held.
+ * Use max_boost to limit the boost to a percentage of the high watermark.
+ */
+static inline bool __boost_watermark(struct zone *zone, unsigned long amount,
+ unsigned long max_boost)
{
- unsigned long max_boost;
+ lockdep_assert_held(&zone->lock);
- if (!watermark_boost_factor)
- return false;
/*
* Don't bother in zones that are unlikely to produce results.
* On small machines, including kdump capture kernels running
@@ -2173,9 +2176,6 @@ static inline bool boost_watermark(struct zone *zone)
if ((pageblock_nr_pages * 4) > zone_managed_pages(zone))
return false;
- max_boost = mult_frac(zone->_watermark[WMARK_HIGH],
- watermark_boost_factor, 10000);
-
/*
* high watermark may be uninitialised if fragmentation occurs
* very early in boot so do not boost. We do not fall
@@ -2189,12 +2189,70 @@ static inline bool boost_watermark(struct zone *zone)
max_boost = max(pageblock_nr_pages, max_boost);
- zone->watermark_boost = min(zone->watermark_boost + pageblock_nr_pages,
- max_boost);
+ zone->watermark_boost = min(zone->watermark_boost + amount,
+ max_boost);
return true;
}
+/*
+ * Boost watermarks to increase reclaim pressure when fragmentation occurs
+ * and we fall back to other migratetypes.
+ */
+static inline bool boost_watermark(struct zone *zone)
+{
+ if (!watermark_boost_factor)
+ return false;
+
+ return __boost_watermark(zone, pageblock_nr_pages,
+ mult_frac(zone->_watermark[WMARK_HIGH],
+ watermark_boost_factor, 10000));
+}
+
+/*
+ * Boost watermarks by ~0.1% of zone size on atomic allocation pressure.
+ * This provides zone-proportional safety buffers: ~1MB per 1GB of zone
+ * size. Max boost ceiling is fixed at ~10% of high watermark.
+ *
+ * This emergency reserve is independent of watermark_boost_factor.
+ */
+static inline bool boost_watermark_atomic(struct zone *zone)
+{
+ return __boost_watermark(zone,
+ max(pageblock_nr_pages, zone_managed_pages(zone) / 1000),
+ zone->_watermark[WMARK_HIGH] / 10);
+}
+
+static void boost_zones_for_atomic(struct alloc_context *ac, gfp_t gfp_mask)
+{
+ struct zoneref *z;
+ struct zone *zone;
+ unsigned long now = jiffies;
+
+ for_each_zone_zonelist_nodemask(zone, z, ac->zonelist,
+ ac->highest_zoneidx, ac->nodemask) {
+ unsigned long flags;
+ bool should_wake = false;
+
+ /*
+ * Check and update the per-zone debounce timestamp under
+ * zone->lock so concurrent callers on other CPUs (e.g. a
+ * multi-queue NIC spreading GFP_ATOMIC allocations across
+ * several softirqs) cannot all observe a stale timestamp
+ * and pile onto the same zone within the same window.
+ */
+ spin_lock_irqsave(&zone->lock, flags);
+ if (time_after(now, zone->last_boost_jiffies + HZ)) {
+ zone->last_boost_jiffies = now;
+ should_wake = boost_watermark_atomic(zone);
+ }
+ spin_unlock_irqrestore(&zone->lock, flags);
+
+ if (should_wake)
+ wakeup_kswapd(zone, gfp_mask, 0, ac->highest_zoneidx);
+ }
+}
+
/*
* When we are falling back to another migratetype during allocation, should we
* try to claim an entire block to satisfy further allocations, instead of
@@ -4742,6 +4800,10 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
if (page)
goto got_pg;
+ /* Boost watermarks for atomic requests entering slowpath */
+ if (((gfp_mask & GFP_ATOMIC) == GFP_ATOMIC) && order == 0 && !can_direct_reclaim)
+ boost_zones_for_atomic(ac, gfp_mask);
+
/*
* For costly allocations, try direct compaction first, as it's likely
* that we have enough base pages and don't need to reclaim. For non-
---
base-commit: b54345928fa1dbde534e32ecaa138678fd5d2135
change-id: 20260720-feat-mm-page_alloc-v11-5f415da4aeb0
Best regards,
--
Jing Wu <realwujing@gmail.com>
^ permalink raw reply related
* Re: [Intel-wired-lan] [PATCH net] igc: remove napi_synchronize() in igc_down()
From: Kadosh, MoriyaX @ 2026-07-20 8:13 UTC (permalink / raw)
To: Ruinskiy, Dima, Maciej Fijalkowski, David Carlier
Cc: intel-wired-lan, netdev, anthony.l.nguyen, przemyslaw.kitszel,
aleksandr.loktionov, advoretsky, stable
In-Reply-To: <c477f099-c365-496a-bb5c-ae8d27d7916f@intel.com>
On 20/07/2026 10:39, Ruinskiy, Dima wrote:
> On 13/07/2026 12:42, Maciej Fijalkowski wrote:
>> On Sun, Jul 12, 2026 at 02:22:42PM +0100, David Carlier wrote:
>>> When an AF_XDP zero-copy application is killed abruptly, the XSK pool is
>>> torn down but NAPI keeps polling. igc_clean_rx_irq_zc() then returns the
>>> full budget on every poll, so napi_complete_done() never clears
>>> NAPI_STATE_SCHED.
>>>
>>> igc_down() calls napi_synchronize() before napi_disable(), so it spins
>>> forever waiting for that bit and the interface never goes down. Drop the
>>> napi_synchronize() and let napi_disable() do the job -- it sets
>>> NAPI_STATE_DISABLE, which forces the stuck poll to complete. Reorder it
>>> ahead of igc_set_queue_napi() so the NAPI mapping is cleared only after
>>> polling has stopped, matching the recent igb fix b1e067240379.
>>>
>>> Fixes: fc9df2a0b520 ("igc: Enable RX via AF_XDP zero-copy")
>>> Suggested-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
>>> Cc: stable@vger.kernel.org
>>> Signed-off-by: David Carlier <devnexen@gmail.com>
>>
>> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
>>
>> This is a mirror of what Alex Dvoretsky did on igb, correct? Did you
>> reproduce the same issue on your side or is it a blind shot at this
>> driver?
>>
>> Regardless, I think it's a correct thing to do, but some clarification
>> would be nice.
>>
>>> ---
>>> drivers/net/ethernet/intel/igc/igc_main.c | 3 +--
>>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/intel/igc/igc_main.c b/drivers/net/
>>> ethernet/intel/igc/igc_main.c
>>> index 2c9e2dfd8499..b3883a5a7d7a 100644
>>> --- a/drivers/net/ethernet/intel/igc/igc_main.c
>>> +++ b/drivers/net/ethernet/intel/igc/igc_main.c
>>> @@ -5352,9 +5352,8 @@ void igc_down(struct igc_adapter *adapter)
>>> for (i = 0; i < adapter->num_q_vectors; i++) {
>>> if (adapter->q_vector[i]) {
>>> - napi_synchronize(&adapter->q_vector[i]->napi);
>>> - igc_set_queue_napi(adapter, i, NULL);
>>> napi_disable(&adapter->q_vector[i]->napi);
>>> + igc_set_queue_napi(adapter, i, NULL);
>>> }
>>> }
>>> --
>>> 2.53.0
>>>
> Reviewed-by: Dima Ruinskiy <dima.ruinskiy@intel.com>
Tested-by: Moriya Kadosh <moriyax.kadosh@intel.com>
^ permalink raw reply
* Re: [PATCH net v2] net: erspan: set lltx to avoid sch_direct_xmit deadlock
From: Ido Schimmel @ 2026-07-20 7:53 UTC (permalink / raw)
To: Yun Zhou, edumazet
Cc: dsahern, davem, edumazet, kuba, pabeni, horms, netdev,
linux-kernel
In-Reply-To: <20260713151435.1815104-1-yun.zhou@windriver.com>
On Mon, Jul 13, 2026 at 11:14:35PM +0800, Yun Zhou wrote:
> erspan_xmit() re-enters the network stack via ip_tunnel_xmit(), causing
> nested acquisition of _xmit_lock on the underlay device while already
> holding the ERSPAN device's _xmit_lock. Both are ARPHRD_ETHER and share
> the same lockdep class, creating an ABBA deadlock:
>
> sch_direct_xmit [lock erspan] -> erspan_xmit -> ip_tunnel_xmit ->
> ip_output -> __dev_queue_xmit -> sch_direct_xmit [lock underlay]
>
> Set dev->lltx = true so HARD_TX_LOCK() skips the spinlock for ERSPAN.
> This is safe as erspan_xmit() has no shared mutable state: o_seqno is
> atomic, stats use atomic_long_inc, and dst_cache is per-CPU. GRETAP,
> the sibling device with identical xmit structure, already sets lltx.
erspan_xmit() (unlike gre_tap_xmit()) is performing non-atomic
__clear_bit() on shared tunnel flags and KCSAN will probably flag it.
Eric had a patch [1] that changes erspan_xmit() to use a private copy of
these flags. I think it's better to wait for Eric's patch to be merged
before setting lltx.
Eric, can you please submit v2 of your patch to net?
Also, doesn't ip6erspan suffer from the same problem? Please try to
reproduce and fix.
[1] https://lore.kernel.org/netdev/20260615140333.3161072-1-edumazet@google.com/
>
> Closes: https://syzkaller.appspot.com/bug?extid=9bda1b9fbb7fbdf9b62b
> Reported-by: syzbot+9bda1b9fbb7fbdf9b62b@syzkaller.appspotmail.com
> Fixes: 84e54fe0a5ea ("gre: introduce native tunnel support for ERSPAN")
> Signed-off-by: Yun Zhou <yun.zhou@windriver.com>
> ---
> v2:
> - change subject prefix to [PATCH net]
>
> net/ipv4/ip_gre.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
> index 3efdfb4ffa21..9fbff16cda1d 100644
> --- a/net/ipv4/ip_gre.c
> +++ b/net/ipv4/ip_gre.c
> @@ -1363,6 +1363,8 @@ static int erspan_tunnel_init(struct net_device *dev)
> dev->features |= GRE_FEATURES;
> dev->hw_features |= GRE_FEATURES;
> dev->priv_flags |= IFF_LIVE_ADDR_CHANGE;
> + /* Skip TX lock: xmit re-enters stack, risking ABBA with underlay */
> + dev->lltx = true;
> netif_keep_dst(dev);
>
> return ip_tunnel_init(dev);
> --
> 2.43.0
>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-net v3] ice: fall back to SBQ when LL PHY timer interface times out
From: Rinitha, SX @ 2026-07-20 7:52 UTC (permalink / raw)
To: Korba, Przemyslaw, intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, Nguyen, Anthony L, Kitszel, Przemyslaw,
Ilichev, Konstantin, Lobakin, Aleksander, Korba, Przemyslaw
In-Reply-To: <20260605120734.1462847-1-przemyslaw.korba@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Przemyslaw Korba
> Sent: 05 June 2026 17:36
> To: intel-wired-lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>; Ilichev, Konstantin <konstantin.ilichev@intel.com>; Lobakin, Aleksander <aleksander.lobakin@intel.com>; Korba, Przemyslaw <przemyslaw.korba@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-net v3] ice: fall back to SBQ when LL PHY timer interface times out
>
> The low-latency (LL) PHY timer interface relies on a tight, atomic poll of the PF_SB_ATQBAL register with a 2ms timeout. After an NVM update / EMPR, FW may need significantly longer than 2ms to start responding to > ATQBAL commands. The first PHY adjust or incval write issued by
> ice_ptp_rebuild_owner() fails with -ETIMEDOUT.
>
>Fix this by falling back to the existing SBQ-based PHY register write path when LL times out. This makes sure PTP is initialized when FW takes longer than expected to come back online.
>
> Steps to reproduce:
> ./nvmupdate64e -if devlink -f
> Update E810 card with nvmupdate64e, and observe dmesg errors:
> Failed to write PHC increment value, status -110
> PTP reset failed, error: -110 (-ETIMEDOUT)
>
Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel)
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] af_unix: Clean up unix_schedule_gc()
From: Nam Cao @ 2026-07-20 7:43 UTC (permalink / raw)
To: sashiko-reviews
Cc: Kuniyuki Iwashima, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, netdev, linux-kernel, linux-rt-devel,
linux-rt-devel, linux-kernel
In-Reply-To: <20260718062736.C97A31F00A3A@smtp.kernel.org>
sashiko-bot@kernel.org writes:
> [Severity: High]
> Does this call trigger the garbage collector for every exiting task in the
> system?
>
> If an unprivileged user creates a live AF_UNIX cyclic reference and leaves
> them open, while queueing a large number of normal inflight sockets up to
> RLIMIT_NOFILE, the live cycle causes unix_graph_state to persistently be
> UNIX_GRAPH_CYCLIC.
>
> Every task exit would then constantly queue unix_gc_work, which executes
> unix_walk_scc_fast() under the unix_gc_lock spinlock, iterating over all
> inflight sockets:
>
> net/unix/garbage.c:unix_walk_scc_fast() {
> ...
> while (!list_empty(&unix_unvisited_vertices)) {
> ...
> }
>
> Could this O(N) loop iterating over all inflight sockets while holding the
> unix_gc_lock cause severe lock contention and a system-wide performance
> degradation for any AF_UNIX operations like sendmsg and recvmsg that block
> on this lock?
Yes. But this is also a pre-existing issue. An unprivileged user can
already create a huge live circle, and then repeatedly create and close
a AF_UNIX socket which constantly schedules the garbage collector.
Perhaps we should think about a GC scheduling policy. Perhaps like other
garbage collector designs which get scheduled when memory runs low, or
maybe periodic? I can put this on my todo list.
Nam
^ permalink raw reply
* Re: [PATCH net-next] net: phy: at803x: Use a helper to check for phy reset existence
From: patchwork-bot+netdevbpf @ 2026-07-20 7:40 UTC (permalink / raw)
To: Maxime Chevallier
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux, hkallweit1,
netdev, linux-kernel, thomas.petazzoni, linux-arm-msm
In-Reply-To: <20260715101355.88536-1-maxime.chevallier@bootlin.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Wed, 15 Jul 2026 12:13:54 +0200 you wrote:
> The at803x family of devices are subjected to an errata that requires
> hard-reseting the PHY upon link change.
>
> That can only work if there's a physical reset line wired to the PHY,
> which the driver checks by looking if there's a reset GPIO configured
> for the MDIO device.
>
> [...]
Here is the summary with links:
- [net-next] net: phy: at803x: Use a helper to check for phy reset existence
https://git.kernel.org/netdev/net-next/c/285fd588859f
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH net] igc: remove napi_synchronize() in igc_down()
From: Ruinskiy, Dima @ 2026-07-20 7:39 UTC (permalink / raw)
To: Maciej Fijalkowski, David Carlier
Cc: intel-wired-lan, netdev, anthony.l.nguyen, przemyslaw.kitszel,
aleksandr.loktionov, advoretsky, stable
In-Reply-To: <alSzCokS7scCoza7@boxer>
On 13/07/2026 12:42, Maciej Fijalkowski wrote:
> On Sun, Jul 12, 2026 at 02:22:42PM +0100, David Carlier wrote:
>> When an AF_XDP zero-copy application is killed abruptly, the XSK pool is
>> torn down but NAPI keeps polling. igc_clean_rx_irq_zc() then returns the
>> full budget on every poll, so napi_complete_done() never clears
>> NAPI_STATE_SCHED.
>>
>> igc_down() calls napi_synchronize() before napi_disable(), so it spins
>> forever waiting for that bit and the interface never goes down. Drop the
>> napi_synchronize() and let napi_disable() do the job -- it sets
>> NAPI_STATE_DISABLE, which forces the stuck poll to complete. Reorder it
>> ahead of igc_set_queue_napi() so the NAPI mapping is cleared only after
>> polling has stopped, matching the recent igb fix b1e067240379.
>>
>> Fixes: fc9df2a0b520 ("igc: Enable RX via AF_XDP zero-copy")
>> Suggested-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
>> Cc: stable@vger.kernel.org
>> Signed-off-by: David Carlier <devnexen@gmail.com>
>
> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
>
> This is a mirror of what Alex Dvoretsky did on igb, correct? Did you
> reproduce the same issue on your side or is it a blind shot at this
> driver?
>
> Regardless, I think it's a correct thing to do, but some clarification
> would be nice.
>
>> ---
>> drivers/net/ethernet/intel/igc/igc_main.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/intel/igc/igc_main.c b/drivers/net/ethernet/intel/igc/igc_main.c
>> index 2c9e2dfd8499..b3883a5a7d7a 100644
>> --- a/drivers/net/ethernet/intel/igc/igc_main.c
>> +++ b/drivers/net/ethernet/intel/igc/igc_main.c
>> @@ -5352,9 +5352,8 @@ void igc_down(struct igc_adapter *adapter)
>>
>> for (i = 0; i < adapter->num_q_vectors; i++) {
>> if (adapter->q_vector[i]) {
>> - napi_synchronize(&adapter->q_vector[i]->napi);
>> - igc_set_queue_napi(adapter, i, NULL);
>> napi_disable(&adapter->q_vector[i]->napi);
>> + igc_set_queue_napi(adapter, i, NULL);
>> }
>> }
>>
>> --
>> 2.53.0
>>
Reviewed-by: Dima Ruinskiy <dima.ruinskiy@intel.com>
^ permalink raw reply
* Re: [BUG] vlan: skb_under_panic when toggling NETIF_F_HW_VLAN_CTAG_TX on lower device
From: Eric Dumazet @ 2026-07-20 7:29 UTC (permalink / raw)
To: xietangxin
Cc: David S . Miller, Jakub Kicinski, Paolo Abeni, Simon Horman,
netdev, linux-kernel, John Fastabend, Jesse Gross, gaoxingwang1,
huyizhen
In-Reply-To: <d6be3b25-3db3-491c-93d8-7e014427f380@h-partners.com>
On Fri, Jul 17, 2026 at 8:42 AM xietangxin <xietangxin@h-partners.com> wrote:
>
>
> Hi Eric,
>
> Thanks for the suggestion. I tested both parts of your patch locally
> and can confirm the skb_under_panic no longer reproduces.
Excellent, thanks for testing.
>
> your diff is against an older tree. After commit
> cd1c188db109 ("vlan: defer real device state propagation to netdev_work"),
> vlan_transfer_features() has been moved to vlan_dev.c.
Yeah, I had this patch in an old branch, I should have rebased it.
>
> Could you post a formal patch?
Sure thing : https://lore.kernel.org/netdev/20260720072622.3541873-1-edumazet@google.com/T/#u
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH net v2] ice: fix memory leak in ice_lbtest_prepare_rings()
From: Rinitha, SX @ 2026-07-20 7:29 UTC (permalink / raw)
To: Dawei Feng, Nguyen, Anthony L
Cc: Kitszel, Przemyslaw, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, intel-wired-lan@lists.osuosl.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
jianhao.xu@seu.edu.cn, stable@vger.kernel.org
In-Reply-To: <20260616155742.4052021-1-dawei.feng@seu.edu.cn>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Dawei Feng
> Sent: 16 June 2026 21:28
> To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>
> Cc: Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>; Andrew Lunn <andrew+netdev@lunn.ch>; David S . Miller <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org; linux-kernel@vger.kernel.org; jianhao.xu@seu.edu.cn; Dawei Feng <dawei.feng@seu.edu.cn>; stable@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH net v2] ice: fix memory leak in ice_lbtest_prepare_rings()
>
> ice_lbtest_prepare_rings() frees Rx rings only when
> ice_vsi_start_all_rx_rings() fails. If ice_vsi_setup_rx_rings() fails after allocating some descriptors, or if ice_vsi_cfg_lan() fails after the Rx rings were prepared, the function reaches the Tx cleanup path without releasing the initialized Rx resources.
>
> Fix this by adding separate unwind paths for Rx setup failure and LAN configuration failure. The Rx setup failure path releases the partially prepared Rx rings before freeing Tx rings, while later failures first undo the LAN Tx configuration and then release the Rx rings in reverse setup order.
>
> The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc7.
>
> An x86_64 allyesconfig build showed no new warnings. As we do not have an Intel E800 Series adapter available to run the ethtool offline loopback selftest, no runtime testing was able to be performed.
>
> Fixes: 0e674aeb0b77 ("ice: Add handler for ethtool selftest")
> Cc: stable@vger.kernel.org
> Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn>
> ---
> Changes in v2:
> - Fix cleanup order
>
> drivers/net/ethernet/intel/ice/ice_ethtool.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel)
^ permalink raw reply
* Re: [PATCH net v3] gtp: parse extension headers before reading inner protocol
From: Zhixing Chen @ 2026-07-20 7:28 UTC (permalink / raw)
To: Pablo Neira Ayuso, Harald Welte
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, osmocom-net-gprs, netdev
In-Reply-To: <20260708042244.120898-1-running910@gmail.com>
Hi Pablo,
Gentle ping on this v3, in case it fell through the cracks.
It refetches the GTP header after pskb_may_pull() before checking the
extension-header flag, as you pointed out on v2.
Thanks,
Zhixing
^ permalink raw reply
* Re: [PATCH net-next v2 2/3] af_unix: Do not wait for garbage collector in sendmsg()
From: Nam Cao @ 2026-07-20 7:26 UTC (permalink / raw)
To: sashiko-reviews
Cc: Kuniyuki Iwashima, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, netdev, linux-kernel, linux-rt-devel,
linux-rt-devel, linux-kernel
In-Reply-To: <20260718062737.8463C1F00A3D@smtp.kernel.org>
sashiko-bot@kernel.org writes:
> [Severity: High]
> Does removing the unix_schedule_gc() call from unix_prepare_fpl() prevent
> proactive garbage collection of cyclic AF_UNIX file descriptors?
>
> If a long-running application creates a cycle of AF_UNIX sockets and closes
> its own file descriptors to them, the cycle maintains a positive f_count.
> Without this call triggering the garbage collector, the uncollected cyclic
> sockets could accumulate until the application reaches its RLIMIT_NOFILE
> quota, causing subsequent socket operations to fail.
Yes. But an application that creates a huge dead circle of AF_UNIX
sockets is already shady.
And keep scheduling the garbage collector can cause CPU consumption for
nothing, as shown in the v1 thread.
> Additionally, does this change leave the user parameter logic in
> unix_schedule_gc() as dead code?
Yes. That is cleaned up by PATCH 3/3.
Nam
^ permalink raw reply
* [PATCH net] vlan: fix skb_under_panic() and races when toggling HW VLAN offload
From: Eric Dumazet @ 2026-07-20 7:26 UTC (permalink / raw)
To: David S . Miller, Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, netdev, eric.dumazet, Eric Dumazet, Tangxin Xie
Toggling hardware VLAN TX offload (NETIF_F_HW_VLAN_CTAG_TX or
NETIF_F_HW_VLAN_STAG_TX) on a lower device invokes vlan_transfer_features(),
which dynamically changes vlandev->hard_header_len.
This causes two issues:
1. Lockless TX paths (e.g. packet_snd in af_packet.c, ip6_finish_output2)
read dev->hard_header_len without holding RTNL lock. Mutating
hard_header_len dynamically under RTNL creates a data race where upper
layers reserve insufficient headroom based on a stale hard_header_len,
resulting in skb_under_panic when vlan_dev_hard_header() is called.
2. In addition, vlan_transfer_features() updated hard_header_len without
updating header_ops, causing a mismatch between allocated headroom
and header creation.
A VLAN interface may require software VLAN header insertion at any point
(e.g., if reorder_hdr is disabled or HW offload is unavailable). Always
setting hard_header_len = real_dev->hard_header_len + VLAN_HLEN and using
vlan_header_ops unconditionally ensures sufficient headroom is reserved
by all upper layers and avoids any data race on hard_header_len during ETHTOOL
feature changes.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: Tangxin Xie <xietangxin@h-partners.com>
Closes: https://lore.kernel.org/netdev/99d678ae-c7b2-4b44-b534-b8320679deb3@h-partners.com/
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/8021q/vlan_dev.c | 34 +++-------------------------------
1 file changed, 3 insertions(+), 31 deletions(-)
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index ec2569b3f8dac629027b4344bc89402decf026d1..acf7f52d1eb2191ec0387dc29e2e9eb34124aa9d 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -502,26 +502,6 @@ static const struct header_ops vlan_header_ops = {
.parse_protocol = vlan_parse_protocol,
};
-static int vlan_passthru_hard_header(struct sk_buff *skb, struct net_device *dev,
- unsigned short type,
- const void *daddr, const void *saddr,
- unsigned int len)
-{
- struct vlan_dev_priv *vlan = vlan_dev_priv(dev);
- struct net_device *real_dev = vlan->real_dev;
-
- if (saddr == NULL)
- saddr = dev->dev_addr;
-
- return dev_hard_header(skb, real_dev, type, daddr, saddr, len);
-}
-
-static const struct header_ops vlan_passthru_header_ops = {
- .create = vlan_passthru_hard_header,
- .parse = eth_header_parse,
- .parse_protocol = vlan_parse_protocol,
-};
-
static const struct device_type vlan_type = {
.name = "vlan",
};
@@ -581,13 +561,8 @@ static int vlan_dev_init(struct net_device *dev)
#endif
dev->needed_headroom = real_dev->needed_headroom;
- if (vlan_hw_offload_capable(real_dev->features, vlan->vlan_proto)) {
- dev->header_ops = &vlan_passthru_header_ops;
- dev->hard_header_len = real_dev->hard_header_len;
- } else {
- dev->header_ops = &vlan_header_ops;
- dev->hard_header_len = real_dev->hard_header_len + VLAN_HLEN;
- }
+ dev->header_ops = &vlan_header_ops;
+ dev->hard_header_len = real_dev->hard_header_len + VLAN_HLEN;
dev->netdev_ops = &vlan_netdev_ops;
@@ -1029,10 +1004,7 @@ static void vlan_transfer_features(struct net_device *dev,
netif_inherit_tso_max(vlandev, dev);
- if (vlan_hw_offload_capable(dev->features, vlan->vlan_proto))
- vlandev->hard_header_len = dev->hard_header_len;
- else
- vlandev->hard_header_len = dev->hard_header_len + VLAN_HLEN;
+ vlandev->hard_header_len = dev->hard_header_len + VLAN_HLEN;
#if IS_ENABLED(CONFIG_FCOE)
vlandev->fcoe_ddp_xid = dev->fcoe_ddp_xid;
--
2.55.0.229.g6434b31f56-goog
^ permalink raw reply related
* [PATCH net v3] mctp: check register_netdevice_notifier() error in mctp_device_init()
From: Minhong He @ 2026-07-20 7:25 UTC (permalink / raw)
To: jk, matt, davem, edumazet, kuba, pabeni, horms, kuniyu; +Cc: heminhong, netdev
mctp_device_init() handles errors from rtnl_af_register() and
rtnl_register_many(), but ignores the return value of
register_netdevice_notifier(). If notifier registration fails, init can
still return success while the module is only partially initialized.
Check the notifier registration error and fail module init early.
Fixes: 583be982d934 ("mctp: Add device handling and netlink interface")
Signed-off-by: Minhong He <heminhong@kylinos.cn>
---
v3:
- Correct Fixes tag to 583be982d934 (bug predates d51705614f66).
- No Cc:stable (unlikely init failure path; stable would also need
d51705614f66 as a prereq on older trees).
v2: https://lore.kernel.org/netdev/20260716063534.116793-1-heminhong@kylinos.cn/
v1: https://lore.kernel.org/netdev/20260713073918.419422-1-heminhong@kylinos.cn/
net/mctp/device.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/mctp/device.c b/net/mctp/device.c
index 2c84df674669..822120e860c8 100644
--- a/net/mctp/device.c
+++ b/net/mctp/device.c
@@ -536,7 +536,9 @@ int __init mctp_device_init(void)
{
int err;
- register_netdevice_notifier(&mctp_dev_nb);
+ err = register_netdevice_notifier(&mctp_dev_nb);
+ if (err)
+ return err;
err = rtnl_af_register(&mctp_af_ops);
if (err)
--
2.25.1
^ permalink raw reply related
* Re: [PATCH net-next v2 1/3] af_unix: Schedule the garbage collector at task exit
From: Nam Cao @ 2026-07-20 7:16 UTC (permalink / raw)
To: sashiko-reviews
Cc: Kuniyuki Iwashima, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, netdev, linux-kernel, linux-rt-devel
In-Reply-To: <20260718062736.199E41F000E9@smtp.kernel.org>
sashiko-bot@kernel.org writes:
> [Severity: Medium]
> Will this race with concurrent task exits and leak cyclic sockets?
>
> In net/unix/garbage.c, unix_schedule_gc() only queues the work if a garbage
> collection is not already running:
>
> void unix_schedule_gc(void)
> {
> if (!READ_ONCE(gc_in_progress))
> queue_work(system_dfl_wq, &unix_gc_work);
> }
>
> If Task A and Task B exit concurrently with dead cyclic sockets:
>
> Task A calls unix_schedule_gc() and triggers the work, which sets
> gc_in_progress to true.
>
> Task B then calls unix_schedule_gc() while the GC is running, observes
> gc_in_progress is true, and silently skips queuing the work.
>
> Task B's newly dead cycles might be missed by the currently running GC pass.
> Since no new GC is queued by Task B, won't those sockets stay behind
> indefinitely until another unrelated task exits, defeating the purpose of
> the patch for concurrent exits?
Yes, this is a pre-existing issue and has been discussed at:
https://lore.kernel.org/lkml/871pde3o54.fsf@yellow.woof/
The solution would be removing gc_in_progress and always calling queue_work().
Since this is not a critical issue, I would fix that after this series
is done.
Nam
^ permalink raw reply
* [PATCH net v3] phonet: check register_netdevice_notifier() error in phonet_device_init()
From: Minhong He @ 2026-07-20 7:00 UTC (permalink / raw)
To: courmisch, davem, edumazet, kuba, pabeni, horms,
remi.denis-courmont
Cc: netdev, linux-kernel, Minhong He
phonet_device_init() registers a netdevice notifier before calling
phonet_netlink_register(), but does not check whether notifier
registration succeeded. On failure, netlink setup still proceeds and
init may return success without the notifier in place.
Also, the existing phonet_netlink_register() failure path called
phonet_device_exit(), which runs rtnl_unregister_all() even though
rtnl_register_many() already unwound any partial registration. Calling
the full exit helper on a partial init is not correct.
Check each registration error and unwind only the steps that have
succeeded so far.
Signed-off-by: Minhong He <heminhong@kylinos.cn>
---
v3:
- Use goto-based unwind; do not call phonet_device_exit() on
phonet_netlink_register() failure (avoids rtnl_unregister_all()
after rtnl_register_many() already unwound).
- Drop Fixes tag (theoretical init failure path; not suitable for
stable autosel).
v2: https://lore.kernel.org/netdev/20260716101504.158387-1-heminhong@kylinos.cn/
- On notifier registration failure, unwind only proc/pernet.
v1: https://lore.kernel.org/netdev/20260713075212.431455-1-heminhong@kylinos.cn/
net/phonet/pn_dev.c | 20 +++++++++++++++++---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/net/phonet/pn_dev.c b/net/phonet/pn_dev.c
index ad44831d6745..f41322a12fb7 100644
--- a/net/phonet/pn_dev.c
+++ b/net/phonet/pn_dev.c
@@ -350,16 +350,30 @@ static struct pernet_operations phonet_net_ops = {
/* Initialize Phonet devices list */
int __init phonet_device_init(void)
{
- int err = register_pernet_subsys(&phonet_net_ops);
+ int err;
+
+ err = register_pernet_subsys(&phonet_net_ops);
if (err)
return err;
proc_create_net("pnresource", 0, init_net.proc_net, &pn_res_seq_ops,
sizeof(struct seq_net_private));
- register_netdevice_notifier(&phonet_device_notifier);
+
+ err = register_netdevice_notifier(&phonet_device_notifier);
+ if (err)
+ goto err_pernet;
+
err = phonet_netlink_register();
if (err)
- phonet_device_exit();
+ goto err_notifier;
+
+ return 0;
+
+err_notifier:
+ unregister_netdevice_notifier(&phonet_device_notifier);
+err_pernet:
+ unregister_pernet_subsys(&phonet_net_ops);
+ remove_proc_entry("pnresource", init_net.proc_net);
return err;
}
--
2.25.1
^ permalink raw reply related
* Re: [PATCH net-next v7 0/2] net: libwx: improve VF ethtool support
From: mengyuanlou @ 2026-07-20 6:59 UTC (permalink / raw)
To: netdev; +Cc: jiawenwu, duanqiangwen, horms, kuba, pabeni
In-Reply-To: <20260710015925.34769-1-mengyuanlou@net-swift.com>
Hi,
Gentle ping.
Any comments on this series would be appreciated.
Thanks.
> 2026年7月10日 09:59，Mengyuan Lou <mengyuanlou@net-swift.com> 写道：
>
> This series improves ethtool support for Wangxun VF drivers
> (ngbevf and txgbevf) in libwx.
>
> This series extends VF support by enabling:
> ring parameter configuration via ethtool -G
> interrupt coalescing configuration via ethtool -C
>
> Patch 1 adds support for set_ringparam in wx_ethtool_ops_vf,
> allowing VF users to adjust TX/RX descriptor ring sizes.
> Patch 2 enables set_coalesce support for VF devices and updates
> EITR programming to use the VF-specific register access helper.
>
> Changelog:
> v7:
> - Remove patch3 and netdev_stat_ops support is deferred to a follow-up patch.
> v6: https://lore.kernel.org/all/20260701100145.23738-1-mengyuanlou@net-swift.com/
> - Patch 1:
> Clarify comments describing wx_set_ring() failure semantics.
> - Patch 2:
> Expand commit message to explain VF ITR encoding changes.
> - Patch 3:
> Protect ring accesses in wx_update_stats().
> v5: https://lore.kernel.org/all/20260615104849.60444-1-mengyuanlou@net-swift.com
> - Patch 3:
> Convert WX_NUM_{RX,TX}_QUEUES macros to take explicit netdev parameter
> as suggested by Simon Horman.
> v4: https://lore.kernel.org/all/20260608103946.25786-1-mengyuanlou@net-swift.com
> sashiko: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260529075147.88398-1-mengyuanlou%40net-swift.com
> - Patch 2:
> PF and VF share the same ITR value range. Update wx_write_eitr_vf() to apply
> identical range clamping as the PF path, ensuring consistent coalesce behavior
> across both device types.
> - Patch 3:
> Remove wx_update_stats in wxvf_down.
> Replace both WX_GLOBAL_STATS_LEN and WX_STATS_LEN macros with type-safe
> static helpers wx_global_stats_len() and wx_stats_len().
> v3: https://lore.kernel.org/all/20260529075147.88398-1-mengyuanlou@net-swift.com
> - Patch 3:
> Drop netdev_stat_ops support from this patch.
> v2: https://lore.kernel.org/all/20260525101115.13151-1-mengyuanlou@net-swift.com
> - Patch 3:
> Remove some stats which can be replaced by standard stats defined in
> include/net/netdev_queues.h.
> - Patch 1:
> Adding a return value to wx_set_ring to make wx_set_ringparam_vf can
> be passed back to userspace.
> Remove freeing and requesting of IRQs. Ring resize only updates descriptor
> resources and does not change MSI-X vector or interrupt configuration,
> so IRQs do not need to be reallocated.
> v1: https://lore.kernel.org/all/20260514103405.42175-1-mengyuanlou@net-swift.com
>
> Mengyuan Lou (2):
> net: libwx: add support for set_ringparam in wx_ethtool_ops_vf
> net: libwx: add support for set_coalesce in wx_ethtool_ops_vf
>
> .../net/ethernet/wangxun/libwx/wx_ethtool.c | 68 ++++++++++++++++++-
> drivers/net/ethernet/wangxun/libwx/wx_lib.c | 9 +--
> drivers/net/ethernet/wangxun/libwx/wx_lib.h | 4 +-
> drivers/net/ethernet/wangxun/libwx/wx_vf.h | 1 -
> .../net/ethernet/wangxun/libwx/wx_vf_common.c | 4 +-
> .../net/ethernet/wangxun/libwx/wx_vf_common.h | 2 +
> .../net/ethernet/wangxun/libwx/wx_vf_lib.c | 13 +++-
> 7 files changed, 90 insertions(+), 11 deletions(-)
>
> --
> 2.30.1
>
^ permalink raw reply
* Re: [PATCH net 1/1] openvswitch: Fix CT limit teardown use-after-free
From: Yuan Tan @ 2026-07-20 6:54 UTC (permalink / raw)
To: Andrew Lunn, Ren Wei, xuyuqiabc
Cc: netdev, dev, aconole, echaudro, i.maximets, davem, edumazet,
pabeni, horms, pshelar, yihung.wei, tonanli66, xuyuqiabc
In-Reply-To: <c357f846-d42c-4b98-acc9-46b751818dca@lunn.ch>
On 7/19/26 19:52, Andrew Lunn wrote:
> On Mon, Jul 20, 2026 at 10:14:16AM +0800, Ren Wei wrote:
>> From: Yuqi Xu <xuyuqiabc@gmail.com>
>>
>> Packet processing uses CT limit state under RCU, while netns teardown
>> frees that state under ovs_mutex. The CT limit pointer was neither removed
>> from readers nor protected by a grace period, allowing packet processing to
>> dereference the freed state.
>>
>> Replace the pointer before freeing the CT limit state. Wait for in-flight
>> RCU readers before freeing its contents. Serialize CT limit netlink
>> operations with teardown for the full lifetime of their state accesses.
>>
>> Fixes: 11efd5cb04a1 ("openvswitch: Support conntrack zone limit")
>> Cc: stable@vger.kernel.org
>> Reported-by: Vega <vega@nebusec.ai>
> Is Vega a person?
Hi Andrew,
Thank you very much for your review!
For context, we had previously understood that using the tool name in
the Reported-by tag was acceptable, based on examples such as
Reported-by: AutonomousCodeSecurity@microsoft.com and Reported-by:
Anthropic.
https://lore.kernel.org/all/20260630171016.11c02dec@kernel.org/
Of course, we’re happy to adjust it if a different format is preferred.
>> Assisted-by: Codex:GPT-5.4
>> Co-developed-by: Nan Li <tonanli66@gmail.com>
>> Signed-off-by: Nan Li <tonanli66@gmail.com>
>> Signed-off-by: Yuqi Xu <xuyuqiabc@gmail.com>
>> Reviewed-by: Ren Wei <enjou1224z@gmail.com>
> Please take a look at
> https://docs.kernel.org/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
> and the sections that follow. What is listed here does not follow the
> rules.
>
>> @@ -932,11 +932,15 @@ static int ovs_ct_check_limit(struct net *net,
>> const struct sk_buff *skb,
>> const struct ovs_conntrack_info *info)
>> {
>> + const struct ovs_ct_limit_info *ct_limit_info;
>> struct ovs_net *ovs_net = net_generic(net, ovs_net_id);
>> - const struct ovs_ct_limit_info *ct_limit_info = ovs_net->ct_limit_info;
>> u32 per_zone_limit, connections;
>> u32 conncount_key;
> Reverse Christmas tree. The lines should be sorted longest to
> shortest. Yes, it was already wrong, but you can actually fix it here.
> Andrew
>
> ---
> pw-bot: cr
^ 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