* Re: [PATCH bpf-next v4] xsk: Fix circular locking dependency between &net->xdp.lock, &xs->mutex, and netdev_lock_ops
2026-08-26 17:47 [PATCH bpf-next v4] xsk: Fix circular locking dependency between &net->xdp.lock, &xs->mutex, and netdev_lock_ops Khawar Ahemad
@ 2026-08-26 18:05 ` sashiko-bot
2026-08-26 18:45 ` bot+bpf-ci
2026-09-01 0:51 ` Jakub Kicinski
2 siblings, 0 replies; 4+ messages in thread
From: sashiko-bot @ 2026-08-26 18:05 UTC (permalink / raw)
To: Khawar Ahemad; +Cc: bpf
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
New issues:
- [High] Queue-based iteration in xsk_notifier() using real_num_rx/tx_queues misses stranded pools, leading to net_device refcount leaks and Use-After-Free.
- [High] O(N^2) list traversal in xsk_diag_dump() causes CPU soft lockups, exacerbated by skipping unbound sockets.
- [Medium] Netlink DUMP rule violation: missing NLM_F_DUMP_INTR flag when dropping locks.
Pre-existing issues:
- [High] The circular locking dependency is not fully resolved because `xsk_notifier()` still acquires `&xs->mutex` while holding `&net->xdp.lock`.
--
commit 5d27bb72970d01c1b3fb96dd5f15dd2e0ec89bb0
Author: Khawar Ahemad <ahemadkhawar123@gmail.com>
xsk: Fix circular locking dependency between &net->xdp.lock, &xs->mutex, and netdev_lock_ops
This commit attempts to fix a circular locking dependency involving
net->xdp.lock, port->pnodes_lock, netdev_lock_ops, and xs->mutex. It modifies
xsk_diag_dump() to release net->xdp.lock temporarily and defers xp_clear_dev()
outside of the locks in xsk_notifier().
Closes: https://syzkaller.appspot.com/bug?extid=aa48b5fe7bfda62d1682
> diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> index 7855ee09c4b64..e72344fccbf26 100644
> --- a/net/xdp/xsk.c
> +++ b/net/xdp/xsk.c
> @@ -2114,13 +2116,21 @@ static int xsk_notifier(struct notifier_block *this,
> sk_error_report(sk);
>
> xsk_unbind_dev(xs);
[Severity: High]
This is a pre-existing issue, but does this code still preserve the circular
locking dependency?
The patch intended to fix a 4-lock circular dependency involving
port->pnodes_lock -> net->xdp.lock -> xs->mutex -> netdev_lock_ops.
However, xsk_notifier() still acquires &xs->mutex while holding
&net->xdp.lock (just prior to this xsk_unbind_dev() call).
Since xsk_bind() still fundamentally acquires netdev_lock_ops while holding
&xs->mutex, the exact lock dependency chain is preserved and lockdep will
continue to report the cycle.
> }
> mutex_unlock(&xs->mutex);
> }
> mutex_unlock(&net->xdp.lock);
> +
> + /* Clear device references outside AF_XDP locks to avoid
> + * lock inversion with netdev_lock_ops().
> + */
> + max_queues = max(dev->real_num_rx_queues, dev->real_num_tx_queues);
> + for (qid = 0; qid < max_queues; qid++) {
> + struct xsk_buff_pool *pool = xsk_get_pool_from_qid(dev, qid);
> +
> + if (pool)
> + xp_clear_dev(pool);
> + }
[Severity: High]
Can this loop miss pools that were bound to queues which have since been
disabled?
If an unprivileged user binds an AF_XDP socket to a high queue index
(e.g., qid=3), and the interface's active queues are then reduced via
ethtool (e.g., rx 2), max_queues will be 2. When the device is unregistered,
this loop will only iterate up to max_queues and miss the pool on qid 3
because xsk_get_pool_from_qid() strictly enforces current queue counts.
Missing stranded pools during device unregistration fails to clear
pool->netdev, leaking the net_device reference. This causes an infinite
loop in netdev_wait_allrefs() upon device removal, freezing the network
stack. A subsequent socket close will trigger a Use-After-Free when
xp_clear_dev() dereferences the freed net_device.
> break;
> }
> return NOTIFY_DONE;
[ ... ]
> diff --git a/net/xdp/xsk_diag.c b/net/xdp/xsk_diag.c
> index 0170363eb542c..bad0b13064f8b 100644
> --- a/net/xdp/xsk_diag.c
> +++ b/net/xdp/xsk_diag.c
> @@ -153,28 +156,48 @@ static int xsk_diag_dump(struct sk_buff *nlskb, struct netlink_callback *cb)
> struct xdp_diag_req *req = nlmsg_data(cb->nlh);
> struct net *net = sock_net(nlskb->sk);
> int num = 0, s_num = cb->args[0];
> - struct sock *sk;
> -
> - mutex_lock(&net->xdp.lock);
> -
> - sk_for_each(sk, &net->xdp.list) {
> - if (!net_eq(sock_net(sk), net))
> - continue;
> - if (num++ < s_num)
> - continue;
> -
> - if (xsk_diag_fill(sk, nlskb, req,
> - sk_user_ns(NETLINK_CB(cb->skb).sk),
> - NETLINK_CB(cb->skb).portid,
> - cb->nlh->nlmsg_seq, NLM_F_MULTI,
> - sock_i_ino(sk)) < 0) {
> - num--;
> - break;
> + struct sock *sk, *target_sk;
> + int err;
> +
> + for (;;) {
> + target_sk = NULL;
> + num = 0;
> +
> + mutex_lock(&net->xdp.lock);
> + sk_for_each(sk, &net->xdp.list) {
> + if (!net_eq(sock_net(sk), net))
> + continue;
> + if (num++ == s_num) {
> + sock_hold(sk);
> + target_sk = sk;
> + break;
> + }
> }
[Severity: High]
Does this introduce an O(N^2) list traversal that could cause CPU soft
lockups?
By dropping locks and restarting the sk_for_each traversal from the list
head up to s_num on every iteration, this loop introduces an O(N^2) time
complexity.
Crucially, the loop never yields (e.g., via cond_resched()), and skipped
unbound sockets (-ENOENT) cause the loop to increment s_num and continue
without returning to userspace. If a user creates tens of thousands of
unbound AF_XDP sockets and triggers an xsk_diag_dump, the kernel will
execute billions of loop iterations within a single recvmsg syscall,
leading to severe lock contention on net->xdp.lock and CPU starvation.
> + mutex_unlock(&net->xdp.lock);
> +
> + if (!target_sk)
> + break;
[Severity: Medium]
When dropping locks during a netlink dump iteration, should this set the
NLM_F_DUMP_INTR flag on the SKB?
Iterating over a list using an index while dropping locks allows concurrent
modifications to the list, which can cause the dump iteration to silently
skip elements or dump the same element multiple times.
The Netlink API contract mandates setting the NLM_F_DUMP_INTR flag when this
occurs so userspace is warned of the inconsistency.
> +
> + err = xsk_diag_fill(target_sk, nlskb, req,
> + sk_user_ns(NETLINK_CB(cb->skb).sk),
> + NETLINK_CB(cb->skb).portid,
> + cb->nlh->nlmsg_seq, NLM_F_MULTI,
> + sock_i_ino(target_sk));
> + sock_put(target_sk);
> +
> + /*
> + * xsk_diag_fill() returns:
> + * 0: entry added successfully.
> + * -ENOENT: socket is unbound, skip it.
> + * -EMSGSIZE: skb is full, retry this socket on the next dump callback.
> + */
> + if (err == -EMSGSIZE)
> + break;
> +
> + s_num++;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260826174744.3394-1-ahemadkhawar123@gmail.com?part=1
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH bpf-next v4] xsk: Fix circular locking dependency between &net->xdp.lock, &xs->mutex, and netdev_lock_ops
2026-08-26 17:47 [PATCH bpf-next v4] xsk: Fix circular locking dependency between &net->xdp.lock, &xs->mutex, and netdev_lock_ops Khawar Ahemad
2026-08-26 18:05 ` sashiko-bot
@ 2026-08-26 18:45 ` bot+bpf-ci
2026-09-01 0:51 ` Jakub Kicinski
2 siblings, 0 replies; 4+ messages in thread
From: bot+bpf-ci @ 2026-08-26 18:45 UTC (permalink / raw)
To: ahemadkhawar123, bpf, netdev, linux-kernel, magnus.karlsson,
maciej.fijalkowski, sdf, ast, daniel, hawk, john.fastabend, kuba,
pabeni, edumazet, horms, syzbot+aa48b5fe7bfda62d1682
Cc: ast, andrii, daniel, martin.lau, eddyz87, yonghong.song, clm,
ihor.solodrai
[-- Attachment #1: Type: text/plain, Size: 6863 bytes --]
> syzbot reported a circular locking dependency involving &net->xdp.lock,
> &port->pnodes_lock, netdev_lock_ops(), and &xs->mutex:
>
> -> #3 (&net->xdp.lock):
> xsk_notifier+0x3d/0x2c0 net/xdp/xsk.c:2106
> ipvlan_device_event+0x310/0x4e0 drivers/net/ipvlan/ipvlan_main.c:834
> unregister_netdevice_many_notify+0x808/0x18b0 net/core/dev.c:12518
The quoted lockdep trace has fabricated symbol offsets. The real syzbot
report (Message-ID 6a8c9fd9.dbb3a75c.7844.000c.GAE@google.com) shows
completely different offsets:
xsk_notifier+0x89/0x230 (not +0x3d/0x2c0)
ipvlan_device_event+0x310/0x4e0 becomes +0xf1f/0xfb0 (rx path) and +0x489/0xfb0 (tx path)
unregister_netdevice_many_notify+0x17fa/0x2130 (not +0x808/0x18b0)
The function sizes were also altered: xsk_notifier is 0x230 bytes in the
real report, not 0x2c0; ipvlan_device_event is 0xfb0, not 0x4e0. Even
the function size cannot change when re-quoting the same lockdep report,
because lockdep emits addr2line output with consistent objdump-derived
function boundaries. Only xsk_bind+0x331/0x11d0 was copied verbatim from
the real report.
Can a quoted lockdep excerpt be paraphrased this way? A maintainer
reading this cannot verify the trace against the syzbot report without
noticing the discrepancy.
[ ... ]
> diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> index 7855ee09c4b64..e72344fccbf26 100644
> --- a/net/xdp/xsk.c
> +++ b/net/xdp/xsk.c
[ ... ]
> @@ -2114,13 +2116,21 @@ static int xsk_notifier(struct notifier_block *this,
> sk_error_report(sk);
>
> xsk_unbind_dev(xs);
> -
> - /* Clear device references. */
> - xp_clear_dev(xs->pool);
> }
> mutex_unlock(&xs->mutex);
> }
> mutex_unlock(&net->xdp.lock);
> +
> + /* Clear device references outside AF_XDP locks to avoid
> + * lock inversion with netdev_lock_ops().
> + */
> + max_queues = max(dev->real_num_rx_queues, dev->real_num_tx_queues);
> + for (qid = 0; qid < max_queues; qid++) {
> + struct xsk_buff_pool *pool = xsk_get_pool_from_qid(dev, qid);
> +
> + if (pool)
> + xp_clear_dev(pool);
> + }
Does this introduce a race on pool->netdev between the sweep and
xsk_diag_put_umem()? With a leased RX queue the pool sits in the
physical device's queue array while pool->netdev points to the leasee.
The physical device can reach NETDEV_UNREGISTER with the lease still
active (netdev_rx_queue_lease only holds a reference on the physical
device, not the leasee). The socket loop skips the socket (xs->dev ==
leasee != physical_dev), so the sweep finds the pool at
physical_dev->_rx[hw_qid] and calls xp_clear_dev(pool), which writes
pool->netdev = NULL and drops the leasee reference, even though the
socket is still bound and alive.
The old code held &xs->mutex across xp_clear_dev(), which serialised
the write against xsk_diag_put_umem(). After the patch xsk_notifier()
holds only RTNL, and xsk_diag_dump() takes neither RTNL nor
&net->xdp.lock around xsk_diag_fill(). That leaves this check-then-use
in xsk_diag_put_umem() (net/xdp/xsk_diag.c:62):
du.ifindex = (pool && pool->netdev) ? pool->netdev->ifindex : 0;
racing with the sweep's pool->netdev = NULL; dev_put(netdev). The
XSK_UNBOUND check at the top of xsk_diag_fill() does not cover this,
because the socket was never unbound by the loop.
Can the reader pass the pool->netdev test, reload after the store, and
dereference NULL, or dereference pool->netdev->ifindex after the sweep
dropped the last device reference?
> diff --git a/net/xdp/xsk_diag.c b/net/xdp/xsk_diag.c
> index 0170363eb542c..bad0b13064f8b 100644
> --- a/net/xdp/xsk_diag.c
> +++ b/net/xdp/xsk_diag.c
> @@ -111,8 +112,10 @@ static int xsk_diag_fill(struct sock *sk, struct sk_buff *nlskb,
> sock_diag_save_cookie(sk, msg->xdiag_cookie);
>
> mutex_lock(&xs->mutex);
> - if (READ_ONCE(xs->state) == XSK_UNBOUND)
> + if (READ_ONCE(xs->state) == XSK_UNBOUND) {
> + err = -ENOENT;
> goto out_nlmsg_trim;
> + }
[ ... ]
> @@ -153,28 +156,48 @@ static int xsk_diag_dump(struct sk_buff *nlskb, struct netlink_callback *cb)
> struct xdp_diag_req *req = nlmsg_data(cb->nlh);
> struct net *net = sock_net(nlskb->sk);
> int num = 0, s_num = cb->args[0];
> - struct sock *sk;
> -
> - mutex_lock(&net->xdp.lock);
> -
> - sk_for_each(sk, &net->xdp.list) {
> - if (!net_eq(sock_net(sk), net))
> - continue;
> - if (num++ < s_num)
> - continue;
> -
> - if (xsk_diag_fill(sk, nlskb, req,
> - sk_user_ns(NETLINK_CB(cb->skb).sk),
> - NETLINK_CB(cb->skb).portid,
> - cb->nlh->nlmsg_seq, NLM_F_MULTI,
> - sock_i_ino(sk)) < 0) {
> - num--;
> - break;
> + struct sock *sk, *target_sk;
> + int err;
> +
> + for (;;) {
> + target_sk = NULL;
> + num = 0;
> +
> + mutex_lock(&net->xdp.lock);
> + sk_for_each(sk, &net->xdp.list) {
> + if (!net_eq(sock_net(sk), net))
> + continue;
> + if (num++ == s_num) {
> + sock_hold(sk);
> + target_sk = sk;
> + break;
> + }
> }
> + mutex_unlock(&net->xdp.lock);
> +
> + if (!target_sk)
> + break;
> +
> + err = xsk_diag_fill(target_sk, nlskb, req,
> + sk_user_ns(NETLINK_CB(cb->skb).sk),
> + NETLINK_CB(cb->skb).portid,
> + cb->nlh->nlmsg_seq, NLM_F_MULTI,
> + sock_i_ino(target_sk));
> + sock_put(target_sk);
Does sock_hold() protect xs->rx and xs->tx from being freed? Before the
patch xsk_diag_fill() ran with &net->xdp.lock held, which serialised it
against xsk_release() taking that lock before sk_del_node_init_rcu().
After the patch the lock is dropped before xsk_diag_fill().
xsk_release() calls xskq_destroy(xs->rx) and xskq_destroy(xs->tx)
outside &xs->mutex (net/xdp/xsk.c:1555-1556) and never clears the
pointers. For a socket that was never bound, xsk_unbind_dev() returns
early without changing xs->state (it checks xs->state != XSK_BOUND at
net/xdp/xsk.c:1474), so xs->state stays XSK_READY and the XSK_UNBOUND
check in xsk_diag_fill() does not take the new -ENOENT branch.
A socket created with socket(AF_XDP, SOCK_RAW, 0) starts at XSK_READY,
and setsockopt(XDP_RX_RING)/setsockopt(XDP_TX_RING) allocates xs->rx /
xs->tx while still XSK_READY. If close() runs concurrently with a dump:
T1 (ss --xdp): finds sk, sock_hold(sk), mutex_unlock(&net->xdp.lock)
T2 (close): sk_del_node_init_rcu(); xsk_unbind_dev() (early return);
xskq_destroy(xs->rx); xskq_destroy(xs->tx);
T1: xsk_diag_fill(): READ_ONCE(xs->state) == XSK_READY,
xsk_diag_put_ring(xs->rx, ...) -> dr.entries = queue->nentries;
Can this dereference freed memory and leak the freed ring contents to
userspace in the netlink attributes?
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/32997090240
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH bpf-next v4] xsk: Fix circular locking dependency between &net->xdp.lock, &xs->mutex, and netdev_lock_ops
2026-08-26 17:47 [PATCH bpf-next v4] xsk: Fix circular locking dependency between &net->xdp.lock, &xs->mutex, and netdev_lock_ops Khawar Ahemad
2026-08-26 18:05 ` sashiko-bot
2026-08-26 18:45 ` bot+bpf-ci
@ 2026-09-01 0:51 ` Jakub Kicinski
2 siblings, 0 replies; 4+ messages in thread
From: Jakub Kicinski @ 2026-09-01 0:51 UTC (permalink / raw)
To: Khawar Ahemad
Cc: bpf, netdev, linux-kernel, magnus.karlsson, maciej.fijalkowski,
sdf, ast, daniel, hawk, john.fastabend, pabeni, edumazet, horms,
syzbot+aa48b5fe7bfda62d1682
On Wed, 26 Aug 2026 23:17:44 +0530 Khawar Ahemad wrote:
> Subject: [PATCH bpf-next v4] xsk: Fix circular locking dependency between &net->xdp.lock, &xs->mutex, and netdev_lock_ops
This patch got assigned to netdev in patchwork, which means it should
go via the networking trees. When reposting please tag it as
[PATCH net v5] rather than bpf-next.
> syzbot reported a circular locking dependency involving &net->xdp.lock,
> &port->pnodes_lock, netdev_lock_ops(), and &xs->mutex:
>
> -> #3 (&net->xdp.lock):
> xsk_notifier+0x3d/0x2c0 net/xdp/xsk.c:2106
> ipvlan_device_event+0x310/0x4e0 drivers/net/ipvlan/ipvlan_main.c:834
> unregister_netdevice_many_notify+0x808/0x18b0 net/core/dev.c:12518
>
> -> #2 (&port->pnodes_lock):
> ipvlan_device_event+0x85/0x4e0 drivers/net/ipvlan/ipvlan_main.c:795
> notifier_call_chain+0xb5/0x410 kernel/notifier.c:85
>
> -> #1 (&dev_instance_lock_key / netdev_lock_ops):
> netdev_lock_ops include/net/netdev_lock.h:42 [inline]
> xsk_bind+0x331/0x11d0 net/xdp/xsk.c:1627
>
> -> #0 (&xs->mutex):
> xsk_diag_fill net/xdp/xsk_diag.c:113 [inline]
> xsk_diag_dump+0x2e0/0x4e0 net/xdp/xsk_diag.c:166
>
> The cycle exists through the following dependency chain:
> 1. xsk_diag_dump() acquired &xs->mutex while holding &net->xdp.lock (#0).
> 2. xsk_bind() acquired netdev_lock_ops() while holding &xs->mutex (#1).
> 3. Device unregistration in ipvlan_device_event() acquired
> &port->pnodes_lock (#2) and called xsk_notifier(), which acquired
> &net->xdp.lock (#3).
This description is not super clear on what creates the cycle TBH.
Please clean this up.
> Break the circular dependency by decoupling the locking in xsk_diag_dump()
> and xsk_notifier():
>
> 1. In xsk_diag_dump(), avoid holding &net->xdp.lock while calling
> xsk_diag_fill(). Instead, locate the target socket under &net->xdp.lock,
> take a temporary socket reference via sock_hold(), release
> &net->xdp.lock, and call xsk_diag_fill() (which acquires &xs->mutex)
> with sock_put().
> To preserve dump continuation across buffer exhaustion, distinguish
> -ENOENT (when an unbound socket is skipped) from -EMSGSIZE (when the
> skb is full and the cursor must be retained for the next dump callback).
Why are you doing this? We still take the socket logs under the netns
in the notifier so does this actually fix anything?..
> 2. In xsk_notifier(), split device unregistration into two phases:
> - First, unbind all matching sockets under &net->xdp.lock and
> &xs->mutex.
> - Then, release &net->xdp.lock and perform device queue teardown by
> sweeping the device queues via xsk_get_pool_from_qid() and calling
> xp_clear_dev(pool) outside all AF_XDP locks.
..IOW isn't fixing this enough?
> Fixes: 975b11ae9077 ("xsk: add socket allocate, create and bind")
Hallucination. Besides, if the problem in the netdev lock - pretty sure
it didn't exist when xsk was added.
> Reported-by: syzbot+aa48b5fe7bfda62d1682@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=aa48b5fe7bfda62d1682
> Signed-off-by: Khawar Ahemad <ahemadkhawar123@gmail.com>
> diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> index 7855ee09c4..e72344fccb 100644
> --- a/net/xdp/xsk.c
> +++ b/net/xdp/xsk.c
> @@ -2099,7 +2099,9 @@ static int xsk_notifier(struct notifier_block *this,
> {
> struct net_device *dev = netdev_notifier_info_to_dev(ptr);
> struct net *net = dev_net(dev);
> + unsigned int max_queues;
> struct sock *sk;
> + u16 qid;
>
> switch (msg) {
> case NETDEV_UNREGISTER:
> @@ -2114,13 +2116,21 @@ static int xsk_notifier(struct notifier_block *this,
> sk_error_report(sk);
>
> xsk_unbind_dev(xs);
> -
> - /* Clear device references. */
> - xp_clear_dev(xs->pool);
> }
> mutex_unlock(&xs->mutex);
> }
> mutex_unlock(&net->xdp.lock);
> +
> + /* Clear device references outside AF_XDP locks to avoid
> + * lock inversion with netdev_lock_ops().
> + */
> + max_queues = max(dev->real_num_rx_queues, dev->real_num_tx_queues);
> + for (qid = 0; qid < max_queues; qid++) {
> + struct xsk_buff_pool *pool = xsk_get_pool_from_qid(dev, qid);
This will not work for leased queues.
Just collect the sockets in the loop above and hold them like you did
on the diag side. Then you can walk the sockets and use xs->pool.
> + if (pool)
> + xp_clear_dev(pool);
> + }
> break;
> }
> return NOTIFY_DONE;
> diff --git a/net/xdp/xsk_diag.c b/net/xdp/xsk_diag.c
> index 0170363eb5..bad0b13064 100644
> --- a/net/xdp/xsk_diag.c
> +++ b/net/xdp/xsk_diag.c
> @@ -97,6 +97,7 @@ static int xsk_diag_fill(struct sock *sk, struct sk_buff *nlskb,
> struct xdp_sock *xs = xdp_sk(sk);
> struct xdp_diag_msg *msg;
> struct nlmsghdr *nlh;
> + int err = -EMSGSIZE;
>
> nlh = nlmsg_put(nlskb, portid, seq, SOCK_DIAG_BY_FAMILY, sizeof(*msg),
> flags);
> @@ -111,8 +112,10 @@ static int xsk_diag_fill(struct sock *sk, struct sk_buff *nlskb,
> sock_diag_save_cookie(sk, msg->xdiag_cookie);
>
> mutex_lock(&xs->mutex);
> - if (READ_ONCE(xs->state) == XSK_UNBOUND)
> + if (READ_ONCE(xs->state) == XSK_UNBOUND) {
> + err = -ENOENT;
If the caller has no special handling for this just return 0
but I'm not sure this is right. The socket is no longer listed
so we shouldn't count against the iterator.
> goto out_nlmsg_trim;
> + }
>
> if ((req->xdiag_show & XDP_SHOW_INFO) && xsk_diag_put_info(xs, nlskb))
> goto out_nlmsg_trim;
> @@ -145,7 +148,7 @@ static int xsk_diag_fill(struct sock *sk, struct sk_buff *nlskb,
> out_nlmsg_trim:
> mutex_unlock(&xs->mutex);
> nlmsg_cancel(nlskb, nlh);
> - return -EMSGSIZE;
> + return err;
> }
--
pw-bot: cr
^ permalink raw reply [flat|nested] 4+ messages in thread