* Re: [PATCH 0/3] vmsplice: make vmsplice a trivial wrapper for preadv2/pwritev2
From: Andrei Vagin @ 2026-06-24 17:52 UTC (permalink / raw)
To: Askar Safin
Cc: akpm, alexander, axboe, bernd, brauner, criu, david, dhowells,
fuse-devel, hch, jack, joannelkoong, linux-api, linux-fsdevel,
linux-kernel, linux-mm, miklos, netdev, patches, pfalcato,
rostedt, torvalds, val, viro, willy
In-Reply-To: <20260624071226.2272209-1-safinaskar@gmail.com>
On Wed, Jun 24, 2026 at 12:12 AM Askar Safin <safinaskar@gmail.com> wrote:
>
> Andrei Vagin <avagin@gmail.com>:
> > The CRIU fifo test fails with this change. The problem is that vmsplice
> > with SPLICE_F_NONBLOCK to a fifo file descriptor fails with -EOPNOTSUPP.
> >
> > It seems we need a fix like this one:
> >
> > diff --git a/fs/pipe.c b/fs/pipe.c
> > index 429b0714ec57..6fc49e933727 100644
> > --- a/fs/pipe.c
> > +++ b/fs/pipe.c
> > @@ -1253,6 +1253,7 @@ static int fifo_open(struct inode *inode, struct
> > file *filp)
> >
> > /* We can only do regular read/write on fifos */
> > stream_open(inode, filp);
> > + filp->f_mode |= FMODE_NOWAIT;
> >
> > switch (filp->f_mode & (FMODE_READ | FMODE_WRITE)) {
> > case FMODE_READ:
>
> Does CRIU actually rely on ability to do SPLICE_F_NONBLOCK vmsplice into
> named fifos? Or this is merely a test?
Yes, it does.
>
> If this is just a test, I think we need not to preserve this behavior.
>
> I did debian code search with regex "vmsplice.*SPLICE_F_NONBLOCK" and I
> found very few packages. And it seems all them use pipes, not named fifos.
In short, this isn't how such cases are handled in the kernel. The fix is
simple and should be applied to avoid breaking random software.
>
> (On speed: I still think that my vmsplice patches are good thing,
> despite performance regressions in CRIU.)
I already explained that this isn't just a perfomance degradation, it
actually breaks the pre-dump mechanism in CRIU. vmsplice is invoked from
our parasite code within the context of a user process, where execution
speed is critical. A heavy performance penalty completely invalidates
the pre-dump logic, making the feature useless.
Under normal circumstances, patches that cause this kind of breakage
would never be merged. However, since there are exceptions to every
rule, we should let the maintainers decide how to proceed here. In CRIU,
we have a backup plan to utilize process_vm_readv to dump process
memory. We already support this mode, but it isn't the default due to
performance concerns. If these patches are merged, it will be the
only option left for CRIU to implement pre-dumping.
However, we need to look at this case in a broader context. This is yet
another example where the change introduces a workflow breakage, meaning
there might be other workloads out there that could be broken by this
change.
At a minimum, we may need to consider a deprecation plan where vmsplice
with SPLICE_F_GIFT triggers a warning for a few releases before these
changes are applied. Alternatively, we could introduce the proposed
behavior alongside a sysctl to fall back to the old behavior and explicitly
state that this fallback path will be completely deprecated in a future kernel
version.
Thanks,
Andrei
^ permalink raw reply
* Re: [PATCH v12 02/12] x86/bhi: Make clear_bhb_loop() effective on newer CPUs
From: Pawan Gupta @ 2026-06-24 17:49 UTC (permalink / raw)
To: Nikolay Borisov
Cc: x86, Jon Kohler, H. Peter Anvin, Josh Poimboeuf, David Kaplan,
Sean Christopherson, Borislav Petkov, Dave Hansen, Peter Zijlstra,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, KP Singh,
Jiri Olsa, David S. Miller, David Laight, Andy Lutomirski,
Thomas Gleixner, Ingo Molnar, David Ahern, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
Stanislav Fomichev, Hao Luo, Paolo Bonzini, Jonathan Corbet,
Jason Baron, Alice Ryhl, Steven Rostedt, Ard Biesheuvel,
Shuah Khan, linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf,
netdev, linux-doc
In-Reply-To: <171efe97-fd87-45c1-9913-ff62eacab400@suse.com>
On Wed, Jun 24, 2026 at 03:12:28PM +0300, Nikolay Borisov wrote:
>
>
> On 23.06.26 г. 20:33 ч., Pawan Gupta wrote:
> > As a mitigation for BHI, clear_bhb_loop() executes branches that overwrite
> > the Branch History Buffer (BHB). On Alder Lake and newer parts this
> > sequence is not sufficient because it doesn't clear enough entries. This
> > was not an issue because these CPUs use the BHI_DIS_S hardware mitigation
> > in the kernel.
> >
> > Now with VMSCAPE (BHI variant) it is also required to isolate branch
> > history between guests and userspace. Since BHI_DIS_S only protects the
> > kernel, the newer CPUs also use IBPB.
> >
> > A cheaper alternative to the current IBPB mitigation is clear_bhb_loop().
> > But it currently does not clear enough BHB entries to be effective on newer
> > CPUs with larger BHB. At boot, dynamically set the loop count of
> > clear_bhb_loop() such that it is effective on newer CPUs too.
> >
> > Introduce global loop counts, initializing them with appropriate value
> > based on the hardware feature X86_FEATURE_BHI_CTRL.
> >
> > Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
> > Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
> > Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
>
> Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>
>
> Although AI brings up a valid argument about whether guests should be
> pessimized and fallback to the longer sequence ?
I don't disagree, but at the same time BHI mitigation for guest migration
is a different beast that should be addressed separately. A series that
adds virtual-SPEC_CTRL support is in the works. Expect the RFC to be posted
in a couple of weeks.
^ permalink raw reply
* Re: [PATCH 0/2] Fix a few memory bugs in RPC-with-TLS
From: Anna Schumaker @ 2026-06-24 17:41 UTC (permalink / raw)
To: Chuck Lever, Trond Myklebust
Cc: linux-nfs, netdev, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Michael Nemanov, Chuck Lever
In-Reply-To: <20260624165228.2920869-1-cel@kernel.org>
Hi Chuck,
On Wed, Jun 24, 2026, at 12:52 PM, Chuck Lever wrote:
> Gentle ping on this series, posted seven weeks ago. Michael
> Nemanov reviewed and tested both patches the following day; he is
> the reporter of the use-after-free that patch 2 addresses on an
> mTLS mount whose client certificate the server rejected.
>
> Could one of you queue these for an upcoming release? I am glad
> to repost against a current base if that is easier to apply.
I don't remember seeing these patches when they came in initially. Sorry
about that! I'll take a look soon, and try to include them in a bugfixes
pull request.
Anna
>
> --
> Chuck Lever
^ permalink raw reply
* Re: [PATCH] ipv6: fib6: fix NULL deref in fib6_walk_continue() on multi-batch dump
From: Eric Dumazet @ 2026-06-24 17:22 UTC (permalink / raw)
To: Pengfei Zhang
Cc: dsahern, idosch, davem, kuba, pabeni, horms, netdev, linux-kernel,
chenzhangqi, baohua, Pengfei Zhang
In-Reply-To: <20260624171156.822055-1-zhangfeionline@gmail.com>
On Wed, Jun 24, 2026 at 10:12 AM Pengfei Zhang <zhangfeionline@gmail.com> wrote:
>
> From: Pengfei Zhang <zhangpengfei16@xiaomi.com>
>
> inet6_dump_fib() saves its progress in cb->args[1] as a positional
> index within the current hash chain. Between batches the RTNL lock
> is released, so a concurrent fib6_new_table() can insert a new table
> at the chain head, shifting all existing entries. The saved index
> then lands on a different table, causing fib6_dump_table() to set
> w->root to the wrong table while w->node still points into the
> previous one. fib6_walk_continue() dereferences w->node->parent
> (NULL) and panics:
>
> BUG: kernel NULL pointer dereference, address: 0000000000000008
> RIP: 0010:fib6_walk_continue+0x6e/0x170
> Call Trace:
> <TASK>
> fib6_dump_table.isra.0+0xc5/0x240
> inet6_dump_fib+0xf6/0x420
> rtnl_dumpit+0x30/0xa0
> netlink_dump+0x15b/0x460
> netlink_recvmsg+0x1d6/0x2a0
> ____sys_recvmsg+0x17a/0x190
>
> Fix by storing tb->tb6_id in cb->args[1] instead of a positional
> index. On resume, skip entries until the id matches; a concurrent
> head-insert can never match the saved id, so the walker always
> resumes on the correct table.
>
> Signed-off-by: Pengfei Zhang <zhangfeionline@gmail.com>
Patch looks good, but you forgot to add a Fixes: tag
Perhaps:
Fixes: 1b43af5480c3 ("[IPV6]: Increase number of possible routing
tables to 2^32")
> ---
> The same crash was independently reported in a production environment
> (kernel 5.15.137, triggered by ovs-vswitchd issuing RTM_GETROUTE):
> https://lkml.iu.edu/hypermail/linux/kernel/2402.3/02068.html
>
> The crash is probabilistic and occurs in fib6_walk_continue() at the
> FWS_U state:
>
> case FWS_U:
> if (fn == w->root)
> return 0;
> pn = rcu_dereference_protected(fn->parent, 1);
> left = rcu_dereference_protected(pn->left, 1); /* crash here */
>
> The crash dump shows fn->parent is NULL. At first glance this looks
> like fn is a leaf node whose parent was freed, but closer inspection of
> the walker state reveals fn->fn_flags has RTN_ROOT set — fn is itself
> a root node of a routing table, not a child node. A root node has no
> parent by definition, so fn->parent == NULL is correct for that node.
>
> The real question is why fn != w->root despite fn being a root. The
> answer is that w->root and fn belong to *different* tables: w->node
> (which became fn during traversal) still references a node from the
> table that was being dumped when the batch suspended, while w->root was
> silently redirected to a different table on resume.
>
> This misdirection happens because inet6_dump_fib() uses a positional
> index to resume across batches. Consider a hash slot containing two
> tables [A(pos=0), B(pos=1)] where B is large enough to require multiple
> batches. On the first batch, B suspends mid-walk and the loop saves:
>
> cb->args[1] = e; /* e=1, position of B in the chain */
>
> The RTNL lock is then released. At this point a concurrent
> fib6_new_table() inserts table C at the chain head via
> hlist_add_head_rcu(), making the chain [C(pos=0), A(pos=1), B(pos=2)].
>
> On the next batch, inet6_dump_fib() resumes with s_e=1 and iterates:
>
> s_e = cb->args[1]; /* s_e = 1 */
> hlist_for_each_entry_rcu(tb, head, tb6_hlist) {
> if (e < s_e) /* skip C at pos=0 */
> goto next;
> /* e=1: tb now points to A, not B */
> fib6_dump_table(tb, skb, cb); /* called with wrong table A */
> }
>
> Inside fib6_dump_table(), w->root is unconditionally overwritten
> before the resume branch is entered:
>
> w->root = &table->tb6_root; /* now A's root */
> /* ... */
> } else {
> int sernum = READ_ONCE(w->root->fn_sernum); /* A's sernum */
> if (cb->args[5] != sernum) {
> /* sernum changed: safe reset, w->node = w->root (A) */
> w->node = w->root;
> } else {
> /* sernum unchanged: w->node untouched, still in B */
> w->skip = 0;
> }
> fib6_walk_continue(w); /* sernum equal: w->root=A, w->node=B */
> }
>
> The sernum guard was intended to detect tree modifications and reset
> the walk, but here the two tables happen to share the same fn_sernum
> value (a global flush had previously unified them), so the guard does
> not fire and w->node is left pointing into B's tree.
>
> From this point w->root and w->node belong to different tables. When
> fib6_walk_continue() traverses upward and reaches B's root node
> (fn->fn_flags & RTN_ROOT), the exit check:
>
> if (fn == w->root) /* B's root != A's root, check fails */
> return 0;
> pn = fn->parent; /* B's root has no parent: pn == NULL */
> left = pn->left; /* NULL deref -> crash */
>
> net/ipv6/ip6_fib.c | 17 ++++++++---------
> 1 file changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c
> index fc95738de..bda492634 100644
> --- a/net/ipv6/ip6_fib.c
> +++ b/net/ipv6/ip6_fib.c
> @@ -636,11 +636,11 @@ static int inet6_dump_fib(struct sk_buff *skb, struct netlink_callback *cb)
> };
> const struct nlmsghdr *nlh = cb->nlh;
> struct net *net = sock_net(skb->sk);
> - unsigned int e = 0, s_e;
> struct hlist_head *head;
> struct fib6_walker *w;
> struct fib6_table *tb;
> unsigned int h, s_h;
> + u32 s_id;
> int err = 0;
>
> rcu_read_lock();
> @@ -701,23 +701,22 @@ static int inet6_dump_fib(struct sk_buff *skb, struct netlink_callback *cb)
> }
>
> s_h = cb->args[0];
> - s_e = cb->args[1];
> + s_id = cb->args[1];
>
> - for (h = s_h; h < FIB6_TABLE_HASHSZ; h++, s_e = 0) {
> - e = 0;
> + for (h = s_h; h < FIB6_TABLE_HASHSZ; h++, s_id = 0) {
> head = &net->ipv6.fib_table_hash[h];
> hlist_for_each_entry_rcu(tb, head, tb6_hlist) {
> - if (e < s_e)
> - goto next;
> + if (s_id && tb->tb6_id != s_id)
> + continue;
> + s_id = 0;
> +
> + cb->args[1] = tb->tb6_id;
> err = fib6_dump_table(tb, skb, cb);
> if (err != 0)
> goto out;
> -next:
> - e++;
> }
> }
> out:
> - cb->args[1] = e;
> cb->args[0] = h;
>
> unlock:
> --
> 2.34.1
>
^ permalink raw reply
* Re: [Bug ?] Packet with End.X segment not correctly forwarded to nexthop
From: Andrea Mayer @ 2026-06-24 17:18 UTC (permalink / raw)
To: Anthony Doeraene
Cc: netdev, Nicolas Dichtel, stefano.salsano, Paolo Lungaroni,
Andrea Mayer
In-Reply-To: <3fe17ca9-25fa-4fb1-ba06-4463e0409a8b@uclouvain.be>
On Fri, 19 Jun 2026 15:25:09 +0200
Anthony Doeraene <anthony.doeraene@uclouvain.be> wrote:
> Hello,
Hi Anthony,
thanks for the description and the reproducer.
>
> I am currently experimenting with SRv6 and VRFs, and I found some weird
> interactions between the two.
>
> For the context, I need routers to have multiple VRFs, with each VRF
> having different routes to reach destinations.
> Our routers not only send packets to a specific nexthop, but also
> specify the VRF that the nexthop
> should use to forward these packets.
> To achieve this goal, routes in these VRFs push two segments: a local
> End.X segment, and a End.DT46 segment.
> Due to some implementation constraints, I want to have a single End.DT46
> segment shared by
> all routers in the network.
>
> Once packets are encapsulated by the VRF, the packet is sent in the main
> table to do a lookup for the nexthop.
> As the End.DT46 segment is shared between routers and can not be used to
> learn the nexthop, I decided to
> use an End.X segment to specify it.
>
> However, what I observe in this scenario is that End.X segment
> processing function is never called, resulting
> in the packet not being sent to the correct nexthop.
As I understand it, you are encapsulating a packet on r1 and you want to
decapsulate it on r2.
The first segment you want to apply on r1 is a local adjacency SID, bound to
the End.X behavior. When applied, it would force the encapsulated packet
onto the r1-r2 link toward your neighbour r2, and advance the segment list to
your next segment, the shared SID bound to End.DT46.
Anyway, as you have noticed, this is not what happens. The reason is that
the packet is generated locally on r1, so it is on the transmit path. An
SRv6 endpoint behavior is triggered by a SID in a packet the node receives,
not in one it originates and transmits. So the End.X behavior is never
triggered: the packet is just encapsulated and routed using the first
segment as its destination address, and not steered.
To steer the packet, you need to control the table in which the post-encap
lookup resolves the first segment. This need already came up for another
use case, originally introduced by Nicolas Dichtel. We referred to it as
'route leaking': the lookup must be done in the underlay table, so the
encapsulated traffic 'leaks' from the VRF to the underlay.
We worked on a patch for the seg6 encap that lets you choose the FIB table
for the post-encap lookup. I will post it when net-next reopens. You then
push only the shared SID and, in a table of your choice, add a route for it
via your next hop. The post-encap lookup resolves it there, and your next
hop receives that SID as the active SID and handles it:
# next hop for the shared decap SID, in the table you pick
ip -6 route add fc00:ffff:: via fc00::1:2 dev r1-r2 table 100
# encap route: segment list is only the shared SID, resolved in table 100
ip -6 route add fc00::2 encap seg6 mode encap segs fc00:ffff:: \
lookup 100 table 10 dev X
- X is used just to determine the IPv6 SA of the encapsulated packet;
- table 10 is the encap route's table; if a VRF is bound to it, you can pass
vrf <name> instead.
The lookup table can also be your VRF table, so the next-hop route sits next
to the encap route.
>
> I am wondering if this is an expected behavior (i.e. a node should never
> push a local segment), or if it is a real bug ?
It is expected, not a bug. A node may push a local segment. The point is
that an SRv6 endpoint behavior is not triggered on traffic the node
originates, as these behaviors run on the receive path.
>
> I am not well versed into the implementation details of SRv6 in the
> kernel, but I'm suspecting that this "bug" comes
> from the fact that seg6_output_core calls dst_output, which does not
> allow an SRv6 segment function to be called.
You understood the mechanism correctly. As explained above, seg6_output_core
ends with dst_output on the output path, so the seg6_local endpoint function
is not called there and this is by design.
>
> A minimal example is given below, which creates two namespaces (r1, r2)
> and allows to reproduce this behavior.
> (tested on a kernel compiled on virtme-ng from commit
> e771677c937da5808f7b6c1f0e4a97ec1a84f8a8)
>
> Thank you in advance for the help and thanks for the SRv6 support on Linux,
> Doeraene Anthony
>
> File setup.sh
> ```
> # Topology under test:
> #
> # fc00::1:1 fc00::1:2
> # fc00::1 [ r1 ] ------------------------- [ r2 ] fc00::2
> #
> # Description:
> # ============
> #
> # Each node has an additional VRF, which it can use to provide different
> # routing decisions based on arbitrary rules (e.g. QoS aware forwarding)
> # Routes in this VRF will encapsulate the packets and push segments to
> # specify the nexthop (End.X) and the VRF the nexthop should use
> # (End.DT46). The same End.DT46 segment is shared by all nodes
> #
> # Problem:
> # ========
> #
> # Once segments are pushed, the End.X segment is never applied. As a
> # result, the segment is not popped from the SL, and the packet is sent
> # on an incorrect interface.
> #
> # Forwarding steps:
> # =================
> #
> # - R1 sends the packet to fc00::2 in its VRF `myvrf`
> # - This VRF encapsulates the packet and add two segments:
> # 1) End.X segment to force the transmission of the packet on r1-r2
> # 2) End.DT46 segment allowing r2 to know which VRF it should use
> # to forward the packet.
> # - After encapsulation, r1 does a lookup in its main table for the
> # End.X segment, but does not pop the segment. The packet is thus
> # sent incorrectly on the dummy interface
> #
> [snip]
>
> ```
>
Ciao,
Andrea
^ permalink raw reply
* [PATCH] ipv6: fib6: fix NULL deref in fib6_walk_continue() on multi-batch dump
From: Pengfei Zhang @ 2026-06-24 17:11 UTC (permalink / raw)
To: dsahern, idosch
Cc: davem, edumazet, kuba, pabeni, horms, netdev, linux-kernel,
chenzhangqi, baohua, Pengfei Zhang, Pengfei Zhang
From: Pengfei Zhang <zhangpengfei16@xiaomi.com>
inet6_dump_fib() saves its progress in cb->args[1] as a positional
index within the current hash chain. Between batches the RTNL lock
is released, so a concurrent fib6_new_table() can insert a new table
at the chain head, shifting all existing entries. The saved index
then lands on a different table, causing fib6_dump_table() to set
w->root to the wrong table while w->node still points into the
previous one. fib6_walk_continue() dereferences w->node->parent
(NULL) and panics:
BUG: kernel NULL pointer dereference, address: 0000000000000008
RIP: 0010:fib6_walk_continue+0x6e/0x170
Call Trace:
<TASK>
fib6_dump_table.isra.0+0xc5/0x240
inet6_dump_fib+0xf6/0x420
rtnl_dumpit+0x30/0xa0
netlink_dump+0x15b/0x460
netlink_recvmsg+0x1d6/0x2a0
____sys_recvmsg+0x17a/0x190
Fix by storing tb->tb6_id in cb->args[1] instead of a positional
index. On resume, skip entries until the id matches; a concurrent
head-insert can never match the saved id, so the walker always
resumes on the correct table.
Signed-off-by: Pengfei Zhang <zhangfeionline@gmail.com>
---
The same crash was independently reported in a production environment
(kernel 5.15.137, triggered by ovs-vswitchd issuing RTM_GETROUTE):
https://lkml.iu.edu/hypermail/linux/kernel/2402.3/02068.html
The crash is probabilistic and occurs in fib6_walk_continue() at the
FWS_U state:
case FWS_U:
if (fn == w->root)
return 0;
pn = rcu_dereference_protected(fn->parent, 1);
left = rcu_dereference_protected(pn->left, 1); /* crash here */
The crash dump shows fn->parent is NULL. At first glance this looks
like fn is a leaf node whose parent was freed, but closer inspection of
the walker state reveals fn->fn_flags has RTN_ROOT set — fn is itself
a root node of a routing table, not a child node. A root node has no
parent by definition, so fn->parent == NULL is correct for that node.
The real question is why fn != w->root despite fn being a root. The
answer is that w->root and fn belong to *different* tables: w->node
(which became fn during traversal) still references a node from the
table that was being dumped when the batch suspended, while w->root was
silently redirected to a different table on resume.
This misdirection happens because inet6_dump_fib() uses a positional
index to resume across batches. Consider a hash slot containing two
tables [A(pos=0), B(pos=1)] where B is large enough to require multiple
batches. On the first batch, B suspends mid-walk and the loop saves:
cb->args[1] = e; /* e=1, position of B in the chain */
The RTNL lock is then released. At this point a concurrent
fib6_new_table() inserts table C at the chain head via
hlist_add_head_rcu(), making the chain [C(pos=0), A(pos=1), B(pos=2)].
On the next batch, inet6_dump_fib() resumes with s_e=1 and iterates:
s_e = cb->args[1]; /* s_e = 1 */
hlist_for_each_entry_rcu(tb, head, tb6_hlist) {
if (e < s_e) /* skip C at pos=0 */
goto next;
/* e=1: tb now points to A, not B */
fib6_dump_table(tb, skb, cb); /* called with wrong table A */
}
Inside fib6_dump_table(), w->root is unconditionally overwritten
before the resume branch is entered:
w->root = &table->tb6_root; /* now A's root */
/* ... */
} else {
int sernum = READ_ONCE(w->root->fn_sernum); /* A's sernum */
if (cb->args[5] != sernum) {
/* sernum changed: safe reset, w->node = w->root (A) */
w->node = w->root;
} else {
/* sernum unchanged: w->node untouched, still in B */
w->skip = 0;
}
fib6_walk_continue(w); /* sernum equal: w->root=A, w->node=B */
}
The sernum guard was intended to detect tree modifications and reset
the walk, but here the two tables happen to share the same fn_sernum
value (a global flush had previously unified them), so the guard does
not fire and w->node is left pointing into B's tree.
From this point w->root and w->node belong to different tables. When
fib6_walk_continue() traverses upward and reaches B's root node
(fn->fn_flags & RTN_ROOT), the exit check:
if (fn == w->root) /* B's root != A's root, check fails */
return 0;
pn = fn->parent; /* B's root has no parent: pn == NULL */
left = pn->left; /* NULL deref -> crash */
net/ipv6/ip6_fib.c | 17 ++++++++---------
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c
index fc95738de..bda492634 100644
--- a/net/ipv6/ip6_fib.c
+++ b/net/ipv6/ip6_fib.c
@@ -636,11 +636,11 @@ static int inet6_dump_fib(struct sk_buff *skb, struct netlink_callback *cb)
};
const struct nlmsghdr *nlh = cb->nlh;
struct net *net = sock_net(skb->sk);
- unsigned int e = 0, s_e;
struct hlist_head *head;
struct fib6_walker *w;
struct fib6_table *tb;
unsigned int h, s_h;
+ u32 s_id;
int err = 0;
rcu_read_lock();
@@ -701,23 +701,22 @@ static int inet6_dump_fib(struct sk_buff *skb, struct netlink_callback *cb)
}
s_h = cb->args[0];
- s_e = cb->args[1];
+ s_id = cb->args[1];
- for (h = s_h; h < FIB6_TABLE_HASHSZ; h++, s_e = 0) {
- e = 0;
+ for (h = s_h; h < FIB6_TABLE_HASHSZ; h++, s_id = 0) {
head = &net->ipv6.fib_table_hash[h];
hlist_for_each_entry_rcu(tb, head, tb6_hlist) {
- if (e < s_e)
- goto next;
+ if (s_id && tb->tb6_id != s_id)
+ continue;
+ s_id = 0;
+
+ cb->args[1] = tb->tb6_id;
err = fib6_dump_table(tb, skb, cb);
if (err != 0)
goto out;
-next:
- e++;
}
}
out:
- cb->args[1] = e;
cb->args[0] = h;
unlock:
--
2.34.1
^ permalink raw reply related
* [PATCH net] net: udp_tunnel: fix use-after-free by refcounting udp_tunnel_nic
From: Eric Dumazet @ 2026-06-24 17:10 UTC (permalink / raw)
To: David S . Miller, Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, Ido Schimmel, David Ahern, netdev, eric.dumazet,
Eric Dumazet, Yue Sun
Yue Sun reported a use-after-free and debugobjects warning in
udp_tunnel_nic_device_sync_work() during concurrent device operations.
The state flags of struct udp_tunnel_nic were originally bitfields
sharing a byte, modified concurrently without locking (RCU vs worker).
Even after converting to atomic bitops, a single WORK_PENDING flag
races: the workqueue core clears the pending bit before running the
worker. A concurrent queueing sets the flag, but the running worker
clears it, leading to premature freeing in unregister() while the
re-queued work is still active.
Fix this introducing reference counting for struct
udp_tunnel_nic. Increment the refcount on successful queue_work(),
and decrement it at the end of the worker. Defer the dev_put() call
for the last device to the free path to ensure the net_device remains
valid as long as the structure is alive.
Additionally, convert concurrent modifications of the 'missed' bitmap
to atomic operations (set_bit, bitmap_zero) to prevent data races there.
Fixes: cc4e3835eff4 ("udp_tunnel: add central NIC RX port offload infrastructure")
Reported-by: Yue Sun <samsun1006219@gmail.com>
Closes: https://lore.kernel.org/netdev/20260624090135.95763-1-samsun1006219@gmail.com/
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv4/udp_tunnel_nic.c | 75 +++++++++++++++++++++++----------------
1 file changed, 45 insertions(+), 30 deletions(-)
diff --git a/net/ipv4/udp_tunnel_nic.c b/net/ipv4/udp_tunnel_nic.c
index 9944ed923ddfd10f9adf6ad788c0740daeaf2adb..884b5d93b7b39f7f20855ff8ca2ec4d7ef5a9ef6 100644
--- a/net/ipv4/udp_tunnel_nic.c
+++ b/net/ipv4/udp_tunnel_nic.c
@@ -30,9 +30,8 @@ struct udp_tunnel_nic_table_entry {
* @work: async work for talking to hardware from process context
* @dev: netdev pointer
* @lock: protects all fields
- * @need_sync: at least one port start changed
- * @need_replay: space was freed, we need a replay of all ports
- * @work_pending: @work is currently scheduled
+ * @flags: sync, replay flags
+ * @refcnt: reference count
* @n_tables: number of tables under @entries
* @missed: bitmap of tables which overflown
* @entries: table of tables of ports currently offloaded
@@ -44,9 +43,11 @@ struct udp_tunnel_nic {
struct mutex lock;
- u8 need_sync:1;
- u8 need_replay:1;
- u8 work_pending:1;
+ unsigned long flags;
+#define UDP_TUNNEL_NIC_NEED_SYNC 0
+#define UDP_TUNNEL_NIC_NEED_REPLAY 1
+
+ refcount_t refcnt;
unsigned int n_tables;
unsigned long missed;
@@ -116,7 +117,7 @@ udp_tunnel_nic_entry_queue(struct udp_tunnel_nic *utn,
unsigned int flag)
{
entry->flags |= flag;
- utn->need_sync = 1;
+ set_bit(UDP_TUNNEL_NIC_NEED_SYNC, &utn->flags);
}
static void
@@ -283,7 +284,7 @@ udp_tunnel_nic_device_sync_by_table(struct net_device *dev,
static void
__udp_tunnel_nic_device_sync(struct net_device *dev, struct udp_tunnel_nic *utn)
{
- if (!utn->need_sync)
+ if (!test_bit(UDP_TUNNEL_NIC_NEED_SYNC, &utn->flags))
return;
if (dev->udp_tunnel_nic_info->sync_table)
@@ -291,21 +292,24 @@ __udp_tunnel_nic_device_sync(struct net_device *dev, struct udp_tunnel_nic *utn)
else
udp_tunnel_nic_device_sync_by_port(dev, utn);
- utn->need_sync = 0;
+ clear_bit(UDP_TUNNEL_NIC_NEED_SYNC, &utn->flags);
/* Can't replay directly here, in case we come from the tunnel driver's
* notification - trying to replay may deadlock inside tunnel driver.
*/
- utn->need_replay = udp_tunnel_nic_should_replay(dev, utn);
+ if (udp_tunnel_nic_should_replay(dev, utn))
+ set_bit(UDP_TUNNEL_NIC_NEED_REPLAY, &utn->flags);
+ else
+ clear_bit(UDP_TUNNEL_NIC_NEED_REPLAY, &utn->flags);
}
static void
udp_tunnel_nic_device_sync(struct net_device *dev, struct udp_tunnel_nic *utn)
{
- if (!utn->need_sync)
+ if (!test_bit(UDP_TUNNEL_NIC_NEED_SYNC, &utn->flags))
return;
- queue_work(udp_tunnel_nic_workqueue, &utn->work);
- utn->work_pending = 1;
+ if (queue_work(udp_tunnel_nic_workqueue, &utn->work))
+ refcount_inc(&utn->refcnt);
}
static bool
@@ -348,7 +352,7 @@ udp_tunnel_nic_has_collision(struct net_device *dev, struct udp_tunnel_nic *utn,
if (!udp_tunnel_nic_entry_is_free(entry) &&
entry->port == ti->port &&
entry->type != ti->type) {
- __set_bit(i, &utn->missed);
+ set_bit(i, &utn->missed);
return true;
}
}
@@ -483,7 +487,7 @@ udp_tunnel_nic_add_new(struct net_device *dev, struct udp_tunnel_nic *utn,
* are no devices currently which have multiple tables accepting
* the same tunnel type, and false positives are okay.
*/
- __set_bit(i, &utn->missed);
+ set_bit(i, &utn->missed);
}
return false;
@@ -552,7 +556,7 @@ static void __udp_tunnel_nic_reset_ntf(struct net_device *dev)
mutex_lock(&utn->lock);
- utn->need_sync = false;
+ clear_bit(UDP_TUNNEL_NIC_NEED_SYNC, &utn->flags);
for (i = 0; i < utn->n_tables; i++)
for (j = 0; j < info->tables[i].n_entries; j++) {
struct udp_tunnel_nic_table_entry *entry;
@@ -696,8 +700,8 @@ udp_tunnel_nic_flush(struct net_device *dev, struct udp_tunnel_nic *utn)
for (i = 0; i < utn->n_tables; i++)
memset(utn->entries[i], 0, array_size(info->tables[i].n_entries,
sizeof(**utn->entries)));
- WARN_ON(utn->need_sync);
- utn->need_replay = 0;
+ WARN_ON(test_bit(UDP_TUNNEL_NIC_NEED_SYNC, &utn->flags));
+ clear_bit(UDP_TUNNEL_NIC_NEED_REPLAY, &utn->flags);
}
static void
@@ -713,8 +717,8 @@ udp_tunnel_nic_replay(struct net_device *dev, struct udp_tunnel_nic *utn)
for (i = 0; i < utn->n_tables; i++)
for (j = 0; j < info->tables[i].n_entries; j++)
udp_tunnel_nic_entry_freeze_used(&utn->entries[i][j]);
- utn->missed = 0;
- utn->need_replay = 0;
+ bitmap_zero(&utn->missed, UDP_TUNNEL_NIC_MAX_TABLES);
+ clear_bit(UDP_TUNNEL_NIC_NEED_REPLAY, &utn->flags);
if (!info->shared) {
udp_tunnel_get_rx_info(dev);
@@ -728,6 +732,8 @@ udp_tunnel_nic_replay(struct net_device *dev, struct udp_tunnel_nic *utn)
udp_tunnel_nic_entry_unfreeze(&utn->entries[i][j]);
}
+static void udp_tunnel_nic_put(struct udp_tunnel_nic *utn);
+
static void udp_tunnel_nic_device_sync_work(struct work_struct *work)
{
struct udp_tunnel_nic *utn =
@@ -736,14 +742,15 @@ static void udp_tunnel_nic_device_sync_work(struct work_struct *work)
rtnl_lock();
mutex_lock(&utn->lock);
- utn->work_pending = 0;
__udp_tunnel_nic_device_sync(utn->dev, utn);
- if (utn->need_replay)
+ if (test_bit(UDP_TUNNEL_NIC_NEED_REPLAY, &utn->flags))
udp_tunnel_nic_replay(utn->dev, utn);
mutex_unlock(&utn->lock);
rtnl_unlock();
+
+ udp_tunnel_nic_put(utn);
}
static struct udp_tunnel_nic *
@@ -759,6 +766,7 @@ udp_tunnel_nic_alloc(const struct udp_tunnel_nic_info *info,
utn->n_tables = n_tables;
INIT_WORK(&utn->work, udp_tunnel_nic_device_sync_work);
mutex_init(&utn->lock);
+ refcount_set(&utn->refcnt, 1);
for (i = 0; i < n_tables; i++) {
utn->entries[i] = kzalloc_objs(*utn->entries[i],
@@ -782,9 +790,19 @@ static void udp_tunnel_nic_free(struct udp_tunnel_nic *utn)
for (i = 0; i < utn->n_tables; i++)
kfree(utn->entries[i]);
+
+ if (utn->dev)
+ dev_put(utn->dev);
+
kfree(utn);
}
+static void udp_tunnel_nic_put(struct udp_tunnel_nic *utn)
+{
+ if (refcount_dec_and_test(&utn->refcnt))
+ udp_tunnel_nic_free(utn);
+}
+
static int udp_tunnel_nic_register(struct net_device *dev)
{
const struct udp_tunnel_nic_info *info = dev->udp_tunnel_nic_info;
@@ -863,6 +881,7 @@ static void
udp_tunnel_nic_unregister(struct net_device *dev, struct udp_tunnel_nic *utn)
{
const struct udp_tunnel_nic_info *info = dev->udp_tunnel_nic_info;
+ bool last = true;
udp_tunnel_nic_lock(dev);
@@ -889,6 +908,7 @@ udp_tunnel_nic_unregister(struct net_device *dev, struct udp_tunnel_nic *utn)
udp_tunnel_drop_rx_info(dev);
utn->dev = first->dev;
udp_tunnel_nic_unlock(dev);
+ last = false;
goto release_dev;
}
@@ -901,16 +921,11 @@ udp_tunnel_nic_unregister(struct net_device *dev, struct udp_tunnel_nic *utn)
udp_tunnel_nic_flush(dev, utn);
udp_tunnel_nic_unlock(dev);
- /* Wait for the work to be done using the state, netdev core will
- * retry unregister until we give up our reference on this device.
- */
- if (utn->work_pending)
- return;
-
- udp_tunnel_nic_free(utn);
+ udp_tunnel_nic_put(utn);
release_dev:
dev->udp_tunnel_nic = NULL;
- dev_put(dev);
+ if (!last)
+ dev_put(dev);
}
static int
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* Re: [PATCH] octeontx2-af: Free BPID bitmap on setup failure
From: Simon Horman @ 2026-06-24 17:09 UTC (permalink / raw)
To: Haoxiang Li
Cc: sgoutham, lcherian, gakula, hkelam, sbhatta, andrew+netdev, davem,
edumazet, kuba, pabeni, netdev, linux-kernel, stable
In-Reply-To: <20260623114316.2182271-1-haoxiang_li2024@163.com>
On Tue, Jun 23, 2026 at 07:43:16PM +0800, Haoxiang Li wrote:
> nix_setup_bpids() allocates bp->bpids with rvu_alloc_bitmap(), which uses
> a plain kcalloc(). If any of the following devm_kcalloc() allocations for
> the BPID mapping arrays fails, the function returns without freeing the
> bitmap. Free the BPID bitmap before returning from those error paths.
>
> Fixes: d6212d2e41a0 ("octeontx2-af: Create BPIDs free pool")
> Cc: stable@vger.kernel.org
> Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
Reviewed-by: Simon Horman <horms@kernel.org>
I am wondering if you did a pass for any other similar problems
with users of rvu_alloc_bitmap.
^ permalink raw reply
* Re: [PATCH v3] nfc: nci: add data_len bound checks to activation parameter extractors
From: David Heidelberg @ 2026-06-24 16:53 UTC (permalink / raw)
To: hexlabsecurity; +Cc: linux-kernel, Simon Horman, netdev, oe-linux-nfc
In-Reply-To: <20260612-b4-disp-6d52d8b0-v3-1-e26221f8826d@proton.me>
On Fri, 12 Jun 2026 12:50:25 -0500, Bryam Vargas wrote:
> nfc: nci: add data_len bound checks to activation parameter extractors
Applied, thanks!
[1/1] nfc: nci: add data_len bound checks to activation parameter extractors
commit: 6f9301aba1ec2f926725c3929a41dd9814231a50
Best regards,
--
David Heidelberg <david@ixit.cz>
^ permalink raw reply
* Re: [PATCH 0/2] Fix a few memory bugs in RPC-with-TLS
From: Chuck Lever @ 2026-06-24 16:52 UTC (permalink / raw)
To: Trond Myklebust, Anna Schumaker
Cc: linux-nfs, netdev, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Michael Nemanov, Chuck Lever
In-Reply-To: <20260504-sunrpc-tls-clnt-pin-v1-0-197f359c6072@oracle.com>
Gentle ping on this series, posted seven weeks ago. Michael
Nemanov reviewed and tested both patches the following day; he is
the reporter of the use-after-free that patch 2 addresses on an
mTLS mount whose client certificate the server rejected.
Could one of you queue these for an upcoming release? I am glad
to repost against a current base if that is easier to apply.
--
Chuck Lever
^ permalink raw reply
* Re: [BUG] KFENCE: use-after-free read in udp_tunnel_nic_device_sync_work
From: Eric Dumazet @ 2026-06-24 16:51 UTC (permalink / raw)
To: Sam Sun
Cc: David S. Miller, Jakub Kicinski, Paolo Abeni, netdev,
linux-kernel, syzkaller
In-Reply-To: <CAEkJfYMZvy1XWuA_y13NfwXef+wUh4jaiQpkzHfr4=HDbr2HAQ@mail.gmail.com>
On Wed, Jun 24, 2026 at 9:36 AM Sam Sun <samsun1006219@gmail.com> wrote:
>
> I tested the refcount version, and I could no longer reproduce the bug with
> the C reproducer. I think this patch fixes the specific lifetime problem
> exposed by the reproducer.
>
Nice, thanks for testing it. I will cook an official patch then.
^ permalink raw reply
* Re: [PATCH net-next v5 1/4] dpll: add DPLL_PIN_TYPE_INT_NCO pin type
From: Ivan Vecera @ 2026-06-24 16:42 UTC (permalink / raw)
To: Vadim Fedorenko, Kubalewski, Arkadiusz, Jiri Pirko,
Jakub Kicinski
Cc: netdev@vger.kernel.org, Jiri Pirko, David S. Miller,
Donald Hunter, Eric Dumazet, Schmidt, Michal, Paolo Abeni,
Vaananen, Pasi, Oros, Petr, Prathosh Satish, Simon Horman,
linux-kernel@vger.kernel.org
In-Reply-To: <0f8fe4e0-72d8-48a6-96ad-d1650919d2df@linux.dev>
On 6/24/26 5:57 PM, Vadim Fedorenko wrote:
> On 19/06/2026 18:07, Ivan Vecera wrote:
>> On 6/17/26 1:59 PM, Kubalewski, Arkadiusz wrote:
>>>> From: Ivan Vecera <ivecera@redhat.com>
>>>> Sent: Monday, June 15, 2026 2:00 PM
>>>>
>>>> On 6/11/26 2:09 PM, Jiri Pirko wrote:
>>>>> Wed, Jun 10, 2026 at 05:45:46PM +0200, ivecera@redhat.com wrote:
>>>>>> On 6/10/26 3:04 PM, Kubalewski, Arkadiusz wrote:
>>>>>>>> From: Ivan Vecera <ivecera@redhat.com>
>>>>>>>> Sent: Tuesday, June 9, 2026 4:59 PM
>>>>>>>>
>>>>>>>> On 6/9/26 4:00 PM, Kubalewski, Arkadiusz wrote:
>>>>>>>>>> From: Jiri Pirko <jiri@resnulli.us>
>>>>>>>>>> Sent: Tuesday, June 9, 2026 10:51 AM
>>>>>>>>>>
>>>>>>>>>> Mon, Jun 08, 2026 at 07:03:46PM +0200,
>>>>>>>>>> arkadiusz.kubalewski@intel.com
>>>>>>>>>> wrote:
>>>>>>>>>>>> From: Ivan Vecera <ivecera@redhat.com>
>>>>>>>>>>>> Sent: Monday, June 8, 2026 5:48 PM
>>>>>>>>>>>>
>>>>>>>>>>>> On 6/8/26 4:43 PM, Kubalewski, Arkadiusz wrote:
>>>>>>>>>>>>>> From: Ivan Vecera <ivecera@redhat.com>
>>>>>>>>>>>>>> Sent: Sunday, May 31, 2026 9:44 PM ...
>>>>>>>>>>>>>> -
>>>>>>>>>>>>>> name: gnss
>>>>>>>>>>>>>> doc: GNSS recovered clock
>>>>>>>>>>>>>> + -
>>>>>>>>>>>>>> + name: int-nco
>>>>>>>>>>>>>> + doc: |
>>>>>>>>>>>>>> + Device internal numerically controlled oscillator.
>>>>>>>>>>>>>> + When connected as a DPLL input, the DPLL enters
>>>>>>>>>>>>>> NCO
>>>>>>>>>>>>>> mode
>>>>>>>>>>>>>> + where the output frequency is adjusted by the host
>>>>>>>>>>>>>> via
>>>>>>>>>>>>>> + the PTP clock interface.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Ivan!
>>>>>>>>>>>>>
>>>>>>>>>>>>> How would you control this in case of automatic mode dpll?
>>>>>>>>>>>>> Automatic mode DPLL shall be controlled on HW level, such pin
>>>>>>>>>>>>> brakes that rule and requires some driver magic to show it is
>>>>>>>>>>>>> higher priority then the rest of the pins?
>>>>>>>>>>>>
>>>>>>>>>>>> The NCO pin can be connected only in manual mode. In other
>>>>>>>>>>>> words
>>>>>>>>>>>> a
>>>>>>>>>>>> DPLL in automatic mode cannot select NCO pin (switch to NCO
>>>>>>>>>>>> mode)
>>>>>>>>>>>> by
>>>>>>>>>>>> its own.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Being picky on DPLL_MODE for enabling feature is not
>>>>>>>>>>> something we
>>>>>>>>>>> can allow if it is not related to HW limitation, is it?
>>>>>>>>>>> Could you please elaborate why it is not possible for AUTOMATIC
>>>>>>>>>>> mode?
>>>>>>>>>>
>>>>>>>>>> In automatic mode, the pin selection logic is defined upon
>>>>>>>>>> prio. I
>>>>>>>>>> can imagine that if NCO pin has the highest prio of the available
>>>>>>>>>> ones, it gets picked. I would be aligned 100% with automatic mode
>>>>>>>>>> behaviour.
>>>>>>>>>> Is there a real usecase for it?
>>>>>>>>>>
>>>>>>>>>> [..]
>>>>>>>>>
>>>>>>>>> This is not true. AUTOMATIC mode is HW solution, SW driver ONLY
>>>>>>>>> configures priorities on the inputs, not manages the active
>>>>>>>>> inputs.
>>>>>>>>> This brakes that behavior, the SW driver would have to manually
>>>>>>>>> override the AUTMATIC mode to be fed from such NCO pin as it
>>>>>>>>> doesn't
>>>>>>>>> exists on it's priority list, HW cannot pick or use it.
>>>>>>>>
>>>>>>>> Correct, AUTO mode is hardware feature and it should not be
>>>>>>>> emulated
>>>>>>>> by a
>>>>>>>> driver. If the hardware does not support it then the switching
>>>>>>>> between
>>>>>>>> input references should be done by userspace (by monitoring ffo,
>>>>>>>> phase_offset, operstate).
>>>>>>>>
>>>>>>>
>>>>>>> Yes, exactly, so for AUTOMATIC mode HW it will not be possible to
>>>>>>> create
>>>>>>> such pin, which means that NCO pin would serve only a MANUAL mode
>>>>>>> implementation.
>>>>>>> Basically this is something we shall not allow to happen. DPLL API
>>>>>>> should be designed to cover the case where AUTO mode is able to
>>>>>>> implement
>>>>>>> all features consistently.
>>>>>>
>>>>>> If you don't like the proposal from Jiri (NCO switch driven by NCO
>>>>>> pin
>>>>>> priority -> highest==enter_nco else leave_nco) then it could be
>>>>>> possible
>>>>>> to handle the switching by allowing the state 'connected' in AUTO
>>>>>> mode
>>>>>> for the NCO pin type. Then the implementation will be the same for
>>>>>> both
>>>>>> selection modes.
>>>>>>
>>>>>> Only difference would be that a user does not need to switch the
>>>>>> device
>>>>> >from the AUTO to MANUAL mode.
>>>>>>
>>>>>>>>> The real use case is that any DPLL can switch the mode to this one
>>>>>>>>> instead of implementing MANUAL mode just to use the feature with a
>>>>>>>>> 'virtual' pin.
>>>>>>>>
>>>>>>>> I don't expect this... but it is up to a driver. I don't plan such
>>>>>>>> functionality in zl3073x as the NCO pin does not expose prio_get()
>>>>>>>> and
>>>>>>>> prio_set() callbacks - so it is clear that this pin cannot be
>>>>>>>> part of
>>>>>>>> the
>>>>>>>> automatic selection.
>>>>>>>>
>>>>>>>> Ivan
>>>>>>>
>>>>>>> There is a difference between particular HW and API capabilities,
>>>>>>> with
>>>>>>> the
>>>>>>> proposed API we would disallow the possibility of such
>>>>>>> implementation
>>>>>>> for
>>>>>>> existing HW variants.
>>>>>>>
>>>>>>> DPLL NCO MODE would allow that but as pointed here by Ivan and by
>>>>>>> Jiri
>>>>>>> in
>>>>>>> the other email it would also require the extra implementation for
>>>>>>> some
>>>>>>> configuration - device level phase/ffo handling.
>>>>>>>
>>>>>>> To summarize it all, I don't have such simple solution for it.
>>>>>>>
>>>>>>> First thing that comes to my mind is to combine both approaches.
>>>>>>> Make it possible for AUTMATIC mode to also set "CONNECTED" state
>>>>>>> on certain kind of "OVERRIDE" pins, where it could be determined by
>>>>>>> the type of PIN and embed that logic into the DPLL subsystem.
>>>>>>
>>>>>> The possible states for particual pins are now handled at a driver
>>>>>> level
>>>>>> so the driver decides if the requested state is correct or not. So it
>>>>>> could be easy to implement this.
>>>>>>
>>>>>> For auto mode allowed states:
>>>>>> - input references: selectable / disconnected
>>>>>> - nco pin: connected / disconnected
>>>>>>
>>>>>>> Basically, if driver registers such NCO pin it would be always
>>>>>>> selected
>>>>>>> manually, and in such case all the other pins are going to
>>>>>>> disconnected
>>>>>>> state while DPLL mode is also a "OVERRIDE" or something like it.
>>>>>>
>>>>>> I would leave this decision on the driver level... Imagine the
>>>>>> potential
>>>>>> HW that would allow to switch NCO mode if there is no valid input
>>>>>> reference.
>>>>>>
>>>>>> Example:
>>>>>>
>>>>>> REF0 (prio 0) -> +------+ -> OUT0
>>>>>> REF1 (prio 1) -> | DPLL | -> ...
>>>>>> NCO (prio 2) -> +------+ -> OUTn
>>>>>>
>>>>>> Such HW would prefer REF0 or REF1 and lock to one of them if they are
>>>>>> qualified. But if they are NOT, then it switches to NCO mode.
>>>
>>> Now you said yourself "NCO mode" ... I agree that it would be a mode in
>>> that case. Where instead of running on regular/built in XO dpll would
>>> run
>>> on NCO and user could select it, and this would be addition to regular
>>> behavior.
>>>
>>> I also agree that the pin approach might be better/easier to use,
>>> assuming
>>> frequency offset for all the outputs given dpll drives, it makes more
>>> sense
>>> to have it configurable on input side.
>>
>> +1
>>
>>>>>>
>>>>>> In this situation the relevant driver would allow to configure
>>>>>> priority
>>>>>> and state 'selectable' for this NCO pin.
>>>>>>
>>>>>>> Perhaps the pin type could include OVERRIDE in it's name to make it
>>>>>>> less
>>>>>>> confusing and needs some extra documentation.
>>>>>>>
>>>>>>> Thoughts?
>>>>>> I think _INT_ is ok. In the case of TYPE_INT_OSCILLATOR it is also
>>>>>> obvious that it is not a standard input reference.
>>>>>>
>>>>>> Jiri, Vadim, Arek, thoughts?
>>>>>
>>>>> I agree with you, the driver should have the flexibility to implement
>>>>> this according to his/hw's needs/capabilities. If it implements prio
>>>>> selection in AUTO mode, let it have it. If it implements manual NCO
>>>>> pin
>>>>> selection in AUTO mode using connected/disconnected override, let it
>>>>> have it.
>>>
>>> I don't know 'current' HW that is capable of using AUTO mode as a
>>> part of
>>> HW-based priority source selection and use such NCO input..
>>> But as already explained above, this is special mode of regular XO,
>>> which
>>> allows DPLL's output frequency offset configuration.
>>
>> Lets keep this available for potential future HW. I can imagine a
>> situation where a user will prefer an automatic switch to NCO mode
>> if there is no qualified input reference - automatic switch means
>> that HW will support this (not emulated by the driver).
>>
>>>>>
>>>>> Moreover, I actually like the "override" capability for pins in AUTO
>>>>> mode in general. It may be handy for other usecases as well.
>>>>>
>>>> Arek? Vadim?
>>>>
>>>> Thanks,
>>>> Ivan
>>>
>>> Agree, 'override' capability of a pin would be the way to go for this
>>> and
>>> other similar further cases.
>>>
>>> I believe a single approach on this would be best, I mean if AUTO mode
>>> needs a capability, to switch from regular behavior to 'OVERRIDE', and
>>> 'OVERRIDE' is only pin capability that allows such behavior for AUTO
>>> mode, then similar approach should be used on MANUAL mode, to make
>>> userspace know that such pin is always available to set "CONNECTED"
>>> and make the userspace implementation consistent on enabling it no
>>> matter
>>> if AUTO or MANUAL mode dpll.
>>
>> Proposal:
>> 1) new pin capability
>> - name: state-connected-override
>> - doc: pin state can be changed to connected in any DPLL mode
>>
>> 2) new NCO pin type to switch the DPLL to NCO mode when connected
>>
>> 3) automatic-only DPLL
>> - should expose NCO pin with state-connected-override capability
>>
>> 4) manual-only DPLL
>> - does not need to expose NCO pin with state-connected-override cap
>>
>> 5) dual-mode DPLL (supporting mode switching)
>> - if it exposes NCO pin with the override cap then it has to support
>> switching to NCO mode directly from AUTO mode
>> - if does not expose NCO pin with the override cap then a user MUST
>> switch the DPLL mode from AUTO to MANUAL to be able to make NCO
>> pin connected to the DPLL
>
> I still don't see good reasoning for the pin. Even this sentence says
> "DPLL mode" which keeps me thinking whether we have to move it to a
> special DPLL mode. All these items look like overcomplication of a
> simple function of the device itself. DPLL can be either in the closed
> loop when one of the pins provides a signal to align to, or in the open
> loop meaning that software can control adjustments to phase/frequency.
> But it's definitely a property of the device, and it's not a pin in any
> kind...
Yes, at first glance, introducing a new DPLL mode would be easier and
simpler. But it depends on how you look at it.
What is NCO mode and how does it differ from other modes?
In other modes, the DPLL loop is controlled by the input signal that the
DPLL is locked to. Changes in frequency (FFO) and phase (phase offset)
affect the output signal(s) that are produced from this DPLL.
In NCO mode, the frequency and, consequently, phase changes are
determined by software (e.g. ptp4l userspace via the PTP API)... these
changes from userspace can be understood as an input signal that affects
the DPLL outputs.
In addition, we could use the existing DPLL pin attributes to control
the DPLL device in NCO mode.
I mean specifically:
* fractional-frequency-offset-ppt as a variant of .adjfine(), but with
a higher resolution (adjfine has a resolution of 15.25 ppt)
* phase-adjust as a higher-resolution variant of .adjphase() (adjphase
uses nanoseconds, whereas phase-adjust uses picoseconds)
So:
'dpll pin set id <nco-pin> fractional-frequency-offset-ppt X'
corresponds to PTP's adjfine(X-as-scaled-ppm)
'dpll pin set id <nco-pin> phase-adjust Y' corresponds to PTP's
adjphase(Y/1000)
So in short, the NCO pin represents a software "signal" from userspace.
If we were to go the special DPLL mode route and want to implement this
functionality in the DPLL subsystem in the future, we would have to add
extra attributes (ffo, phase) to dpll_device.
WDYT?
Thanks,
Ivan
^ permalink raw reply
* Re: [PATCH net v7 3/4] iavf: send MAC change request synchronously
From: Simon Horman @ 2026-06-24 16:31 UTC (permalink / raw)
To: jtornosm
Cc: Simon Horman, netdev, intel-wired-lan, przemyslaw.kitszel,
aleksandr.loktionov, jacob.e.keller, anthony.l.nguyen, davem,
edumazet, kuba, pabeni
In-Reply-To: <20260623101800.991293-4-jtornosm@redhat.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
iavf: send MAC change request synchronously
This commit fixes a deadlock in iavf_set_mac() by making the MAC
address change synchronous. It introduces iavf_poll_virtchnl_response()
to directly poll the admin queue instead of waiting on the watchdog task.
> diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c b/drivers/net/ethernet/intel/iavf/iavf_main.c
> index 630388e9d28cb..3fa288e3798ae 100644
> --- a/drivers/net/ethernet/intel/iavf/iavf_main.c
> +++ b/drivers/net/ethernet/intel/iavf/iavf_main.c
[ ... ]
> @@ -1049,25 +1103,23 @@ static int iavf_set_mac(struct net_device *netdev, void *p)
> return -EADDRNOTAVAIL;
>
> ret = iavf_replace_primary_mac(adapter, addr->sa_data);
> -
> if (ret)
> return ret;
>
> - ret = wait_event_interruptible_timeout(adapter->vc_waitqueue,
> - iavf_is_mac_set_handled(netdev, addr->sa_data),
> - msecs_to_jiffies(2500));
> -
> - /* If ret < 0 then it means wait was interrupted.
> - * If ret == 0 then it means we got a timeout.
> - * else it means we got response for set MAC from PF,
> - * check if netdev MAC was updated to requested MAC,
> - * if yes then set MAC succeeded otherwise it failed return -EACCES
> - */
> - if (ret < 0)
> + ret = iavf_set_mac_sync(adapter, addr->sa_data);
> + if (ret) {
> + /* Rollback only if send failed (message never reached PF).
> + * Don't rollback on timeout (-EAGAIN) because the message was
> + * sent and PF will eventually respond. When the response arrives,
> + * iavf_virtchnl_completion() will handle rollback (on PF error)
> + * or acceptance (on PF success) automatically.
> + */
> + if (ret != -EAGAIN) {
> + iavf_mac_add_reject(adapter);
> + ether_addr_copy(adapter->hw.mac.addr, netdev->dev_addr);
> + }
> return ret;
> -
> - if (!ret)
> - return -EAGAIN;
>
> if (!ether_addr_equal(netdev->dev_addr, addr->sa_data))
> return -EACCES;
[Severity: High]
Will this cause a persistent state mismatch if a timeout is followed by a
retry?
If iavf_set_mac_sync() times out, it returns -EAGAIN and bypasses this
rollback, leaving adapter->hw.mac.addr updated but netdev->dev_addr at the
old MAC.
If the user then retries before the PF asynchronously completes the original
request, iavf_add_ether_addrs() returns -EBUSY. Since -EBUSY != -EAGAIN,
the rollback runs, forcibly reverting adapter->hw.mac.addr to the old MAC.
When the PF's delayed success response finally arrives,
iavf_virtchnl_completion() sees the old MAC in both hw.mac.addr and
netdev->dev_addr, bypassing the netdev MAC update. The PF hardware is now
programmed with the new MAC, but the kernel retains the old MAC, dropping
traffic.
> diff --git a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
> index ec234cc8bd9db..e6b7e8f82c7c1 100644
> --- a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
> +++ b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
[ ... ]
> @@ -555,20 +556,23 @@ iavf_set_mac_addr_type(struct virtchnl_ether_addr *virtchnl_ether_addr,
> * @adapter: adapter structure
> *
> * Request that the PF add one or more addresses to our filters.
> - **/
> -void iavf_add_ether_addrs(struct iavf_adapter *adapter)
> + *
> + * Return: 0 on success, negative on failure
> + */
> +int iavf_add_ether_addrs(struct iavf_adapter *adapter)
> {
> struct virtchnl_ether_addr_list *veal;
> struct iavf_mac_filter *f;
> int i = 0, count = 0;
> bool more = false;
> size_t len;
> + int ret;
>
> if (adapter->current_op != VIRTCHNL_OP_UNKNOWN) {
> /* bail because we already have a command pending */
> dev_err(&adapter->pdev->dev, "Cannot add filters, command %d pending\n",
> adapter->current_op);
> - return;
> + return -EBUSY;
> }
[Severity: High]
Could routine background tasks cause MAC changes to frequently fail?
The watchdog task routinely sets adapter->current_op for background commands
like VIRTCHNL_OP_GET_STATS. If iavf_set_mac() is called during this window,
iavf_set_mac_sync() will hit this check and immediately fail the MAC change
with -EBUSY.
Because there is no retry logic in iavf_set_mac(), this error propagates
directly to userspace, making MAC address configuration randomly fail based
on watchdog timing.
[ ... ]
> @@ -712,8 +724,8 @@ static void iavf_mac_add_ok(struct iavf_adapter *adapter)
> * @adapter: adapter structure
> *
> * Remove filters from list based on PF response.
> - **/
> -static void iavf_mac_add_reject(struct iavf_adapter *adapter)
> + */
> +void iavf_mac_add_reject(struct iavf_adapter *adapter)
> {
> struct net_device *netdev = adapter->netdev;
> struct iavf_mac_filter *f, *ftmp;
[Severity: Medium]
Does exporting and reusing iavf_mac_add_reject() for local rollback cause
unintended background MAC changes?
When the user requests a MAC address that is already in the filter list
(e.g., a secondary MAC), iavf_add_filter() sets f->is_new_mac = false and
f->add = true, and flags IAVF_FLAG_AQ_ADD_MAC_FILTER.
If the synchronous operation fails locally (like the -EBUSY return above),
iavf_set_mac() calls this function. However, iavf_mac_add_reject() only
clears the pending state and removes the filter if f->is_new_mac is true:
if (f->is_new_mac) {
list_del(&f->list);
kfree(f);
}
Reused filters are ignored, leaving f->add = true and the
IAVF_FLAG_AQ_ADD_MAC_FILTER flag active. The background watchdog task will
eventually process this flag and blindly send the MAC configuration to the
PF, even though the VF already aborted the operation locally.
^ permalink raw reply
* [PATCH net v3 11/11] rxrpc: Fix rxrpc_rotate_tx_rotate() to check there's something to rotate
From: David Howells @ 2026-06-24 16:38 UTC (permalink / raw)
To: netdev
Cc: David Howells, Marc Dionne, Jakub Kicinski, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, linux-afs, linux-kernel,
Jeffrey Altman, stable
In-Reply-To: <20260624163819.3017002-1-dhowells@redhat.com>
Fix rxrpc_rotate_tx_rotate() to check that there's something in the
transmission buffer to be rotated before it attempts to rotate anything.
Fixes: b341a0263b1b ("rxrpc: Implement progressive transmission queue struct")
Link: https://sashiko.dev/#/patchset/20260618134802.2477777-1-dhowells%40redhat.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Marc Dionne <marc.dionne@auristor.com>
cc: Jeffrey Altman <jaltman@auristor.com>
cc: Eric Dumazet <edumazet@google.com>
cc: "David S. Miller" <davem@davemloft.net>
cc: Jakub Kicinski <kuba@kernel.org>
cc: Paolo Abeni <pabeni@redhat.com>
cc: Simon Horman <horms@kernel.org>
cc: linux-afs@lists.infradead.org
cc: stable@kernel.org
---
net/rxrpc/input.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/rxrpc/input.c b/net/rxrpc/input.c
index 9bd0f1b92463..73cafe6bfa9f 100644
--- a/net/rxrpc/input.c
+++ b/net/rxrpc/input.c
@@ -237,6 +237,9 @@ static bool rxrpc_rotate_tx_window(struct rxrpc_call *call, rxrpc_seq_t to,
call->acks_lowest_nak = to;
}
+ if (after(seq, to))
+ return false;
+
/* We may have a left over fully-consumed buffer at the front that we
* couldn't drop before (rotate_and_keep below).
*/
^ permalink raw reply related
* [PATCH net v3 09/11] rxrpc: Fix socket notification race
From: David Howells @ 2026-06-24 16:38 UTC (permalink / raw)
To: netdev
Cc: David Howells, Marc Dionne, Jakub Kicinski, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, linux-afs, linux-kernel,
Jeffrey Altman, stable
In-Reply-To: <20260624163819.3017002-1-dhowells@redhat.com>
There's a race between rxrpc_recvmsg() and rxrpc_notify_socket(), whereby
the latter's attempt to avoid disabling interrupts and taking the socket's
recvmsg_lock if the call is already queued may happen simultaneously with
the former's discarding of a call that has nothing queued.
Fix this by removing the shortcut. Note that this only affects userspace's
use of AF_RXRPC; the AFS filesystem driver doesn't use the socket queue.
Fixes: 248f219cb8bc ("rxrpc: Rewrite the data and ack handling code")
Link: https://sashiko.dev/#/patchset/20260616155749.2125907-1-dhowells%40redhat.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Marc Dionne <marc.dionne@auristor.com>
cc: Jeffrey Altman <jaltman@auristor.com>
cc: Eric Dumazet <edumazet@google.com>
cc: "David S. Miller" <davem@davemloft.net>
cc: Jakub Kicinski <kuba@kernel.org>
cc: Paolo Abeni <pabeni@redhat.com>
cc: Simon Horman <horms@kernel.org>
cc: linux-afs@lists.infradead.org
cc: stable@kernel.org
---
net/rxrpc/recvmsg.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/net/rxrpc/recvmsg.c b/net/rxrpc/recvmsg.c
index f382a47c6eb0..9962e135cb73 100644
--- a/net/rxrpc/recvmsg.c
+++ b/net/rxrpc/recvmsg.c
@@ -27,8 +27,6 @@ void rxrpc_notify_socket(struct rxrpc_call *call)
_enter("%d", call->debug_id);
- if (!list_empty(&call->recvmsg_link))
- return;
if (test_bit(RXRPC_CALL_RELEASED, &call->flags)) {
rxrpc_see_call(call, rxrpc_call_see_notify_released);
return;
^ permalink raw reply related
* [PATCH net v3 10/11] rxrpc: Fix leak of released call in recvmsg(MSG_PEEK)
From: David Howells @ 2026-06-24 16:38 UTC (permalink / raw)
To: netdev
Cc: David Howells, Marc Dionne, Jakub Kicinski, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, linux-afs, linux-kernel,
Jeffrey Altman, stable
In-Reply-To: <20260624163819.3017002-1-dhowells@redhat.com>
Fix rxrpc_recvmsg() to also drop the ref it holds on an already-released
call if MSG_PEEK is in force (the function holds a ref on the call
irrespective of whether MSG_PEEK is specified or not).
Fixes: 962fb1f651c2 ("rxrpc: Fix recv-recv race of completed call")
Link: https://sashiko.dev/#/patchset/20260616155749.2125907-1-dhowells%40redhat.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Marc Dionne <marc.dionne@auristor.com>
cc: Jeffrey Altman <jaltman@auristor.com>
cc: Eric Dumazet <edumazet@google.com>
cc: "David S. Miller" <davem@davemloft.net>
cc: Jakub Kicinski <kuba@kernel.org>
cc: Paolo Abeni <pabeni@redhat.com>
cc: Simon Horman <horms@kernel.org>
cc: linux-afs@lists.infradead.org
cc: stable@kernel.org
---
net/rxrpc/recvmsg.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/rxrpc/recvmsg.c b/net/rxrpc/recvmsg.c
index 9962e135cb73..efcba4b2e74f 100644
--- a/net/rxrpc/recvmsg.c
+++ b/net/rxrpc/recvmsg.c
@@ -529,8 +529,7 @@ int rxrpc_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
if (test_bit(RXRPC_CALL_RELEASED, &call->flags)) {
rxrpc_see_call(call, rxrpc_call_see_already_released);
mutex_unlock(&call->user_mutex);
- if (!(flags & MSG_PEEK))
- rxrpc_put_call(call, rxrpc_call_put_recvmsg);
+ rxrpc_put_call(call, rxrpc_call_put_recvmsg);
goto try_again;
}
^ permalink raw reply related
* [PATCH net v3 08/11] rxrpc: Fix potential infinite loop in rxrpc_recvmsg()
From: David Howells @ 2026-06-24 16:38 UTC (permalink / raw)
To: netdev
Cc: David Howells, Marc Dionne, Jakub Kicinski, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, linux-afs, linux-kernel,
Jeffrey Altman, stable
In-Reply-To: <20260624163819.3017002-1-dhowells@redhat.com>
Fix the wait in rxrpc_recvmsg() also take check the oob queue.
Fixes: 5800b1cf3fd8 ("rxrpc: Allow CHALLENGEs to the passed to the app for a RESPONSE")
Link: https://sashiko.dev/#/patchset/20260616155749.2125907-1-dhowells%40redhat.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Marc Dionne <marc.dionne@auristor.com>
cc: Jeffrey Altman <jaltman@auristor.com>
cc: Eric Dumazet <edumazet@google.com>
cc: "David S. Miller" <davem@davemloft.net>
cc: Jakub Kicinski <kuba@kernel.org>
cc: Paolo Abeni <pabeni@redhat.com>
cc: Simon Horman <horms@kernel.org>
cc: linux-afs@lists.infradead.org
cc: stable@kernel.org
---
net/rxrpc/recvmsg.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/rxrpc/recvmsg.c b/net/rxrpc/recvmsg.c
index 39a03684432d..f382a47c6eb0 100644
--- a/net/rxrpc/recvmsg.c
+++ b/net/rxrpc/recvmsg.c
@@ -438,7 +438,8 @@ int rxrpc_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
return -EAGAIN;
}
- if (list_empty(&rx->recvmsg_q)) {
+ if (list_empty(&rx->recvmsg_q) &&
+ skb_queue_empty_lockless(&rx->recvmsg_oobq)) {
ret = -EWOULDBLOCK;
if (timeo == 0) {
call = NULL;
^ permalink raw reply related
* [PATCH net v3 07/11] rxrpc: Fix oob challenge leak in cleanup after notification failure
From: David Howells @ 2026-06-24 16:38 UTC (permalink / raw)
To: netdev
Cc: David Howells, Marc Dionne, Jakub Kicinski, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, linux-afs, linux-kernel,
Jeffrey Altman, stable
In-Reply-To: <20260624163819.3017002-1-dhowells@redhat.com>
Fix rxrpc_notify_socket_oob() to return an indication of failure in the
event that it failed to queue a packet and fix rxrpc_post_challenge() to
clean up the connection ref in such an event.
Fixes: 5800b1cf3fd8 ("rxrpc: Allow CHALLENGEs to the passed to the app for a RESPONSE")
Link: https://sashiko.dev/#/patchset/20260616155749.2125907-1-dhowells%40redhat.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Marc Dionne <marc.dionne@auristor.com>
cc: Jeffrey Altman <jaltman@auristor.com>
cc: Eric Dumazet <edumazet@google.com>
cc: "David S. Miller" <davem@davemloft.net>
cc: Jakub Kicinski <kuba@kernel.org>
cc: Paolo Abeni <pabeni@redhat.com>
cc: Simon Horman <horms@kernel.org>
cc: linux-afs@lists.infradead.org
cc: stable@kernel.org
---
net/rxrpc/ar-internal.h | 4 ++--
net/rxrpc/conn_event.c | 9 +++++++--
net/rxrpc/oob.c | 7 +++++--
3 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/net/rxrpc/ar-internal.h b/net/rxrpc/ar-internal.h
index b6ccd8a8199b..d2b31d15851b 100644
--- a/net/rxrpc/ar-internal.h
+++ b/net/rxrpc/ar-internal.h
@@ -1357,9 +1357,9 @@ static inline struct rxrpc_net *rxrpc_net(struct net *net)
}
/*
- * out_of_band.c
+ * oob.c
*/
-void rxrpc_notify_socket_oob(struct rxrpc_call *call, struct sk_buff *skb);
+bool rxrpc_notify_socket_oob(struct rxrpc_call *call, struct sk_buff *skb);
void rxrpc_add_pending_oob(struct rxrpc_sock *rx, struct sk_buff *skb);
int rxrpc_sendmsg_oob(struct rxrpc_sock *rx, struct msghdr *msg, size_t len);
diff --git a/net/rxrpc/conn_event.c b/net/rxrpc/conn_event.c
index c96ca615b787..611c790bc6d0 100644
--- a/net/rxrpc/conn_event.c
+++ b/net/rxrpc/conn_event.c
@@ -436,7 +436,7 @@ static bool rxrpc_post_challenge(struct rxrpc_connection *conn,
struct rxrpc_skb_priv *sp = rxrpc_skb(skb);
struct rxrpc_call *call = NULL;
struct rxrpc_sock *rx;
- bool respond = false;
+ bool respond = false, queued = false;
sp->chall.conn =
rxrpc_get_connection(conn, rxrpc_conn_get_challenge_input);
@@ -472,8 +472,13 @@ static bool rxrpc_post_challenge(struct rxrpc_connection *conn,
}
if (call)
- rxrpc_notify_socket_oob(call, skb);
+ queued = rxrpc_notify_socket_oob(call, skb);
rcu_read_unlock();
+ if (call && !queued) {
+ rxrpc_put_connection(conn, rxrpc_conn_put_challenge_input);
+ sp->chall.conn = NULL;
+ return false;
+ }
if (!call)
rxrpc_post_packet_to_conn(conn, skb);
diff --git a/net/rxrpc/oob.c b/net/rxrpc/oob.c
index 3318c8bd82ad..c80ee2487d09 100644
--- a/net/rxrpc/oob.c
+++ b/net/rxrpc/oob.c
@@ -32,11 +32,12 @@ struct rxrpc_oob_params {
* Post an out-of-band message for attention by the socket or kernel service
* associated with a reference call.
*/
-void rxrpc_notify_socket_oob(struct rxrpc_call *call, struct sk_buff *skb)
+bool rxrpc_notify_socket_oob(struct rxrpc_call *call, struct sk_buff *skb)
{
struct rxrpc_skb_priv *sp = rxrpc_skb(skb);
struct rxrpc_sock *rx;
struct sock *sk;
+ bool queued = false;
rcu_read_lock();
@@ -49,6 +50,7 @@ void rxrpc_notify_socket_oob(struct rxrpc_call *call, struct sk_buff *skb)
skb->skb_mstamp_ns = rx->oob_id_counter++;
rxrpc_get_skb(skb, rxrpc_skb_get_post_oob);
skb_queue_tail(&rx->recvmsg_oobq, skb);
+ queued = true;
trace_rxrpc_notify_socket(call->debug_id, sp->hdr.serial);
if (rx->app_ops)
@@ -56,11 +58,12 @@ void rxrpc_notify_socket_oob(struct rxrpc_call *call, struct sk_buff *skb)
}
spin_unlock_irq(&rx->recvmsg_lock);
- if (!rx->app_ops && !sock_flag(sk, SOCK_DEAD))
+ if (queued && !rx->app_ops && !sock_flag(sk, SOCK_DEAD))
sk->sk_data_ready(sk);
}
rcu_read_unlock();
+ return queued;
}
/*
^ permalink raw reply related
* [PATCH net v3 06/11] rxrpc: Fix the reception of a reply packet before data transmission
From: David Howells @ 2026-06-24 16:38 UTC (permalink / raw)
To: netdev
Cc: David Howells, Marc Dionne, Jakub Kicinski, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, linux-afs, linux-kernel,
Jeffrey Altman, stable
In-Reply-To: <20260624163819.3017002-1-dhowells@redhat.com>
Fix rxrpc_receiving_reply() to handle the reception of an apparent reply
DATA packet before rxrpc has had a chance to send any request DATA packets
on a client call by checking to see if the call has been exposed yet by
sending the first packet.
Without this, rxrpc_rotate_tx_window() might oops.
Also fix rxrpc_rotate_tx_window() to handle the Tx queue being empty by
changing the do...while loop into a while loop, just in case a call is
abnormally terminated by an early reply before the last request packet is
transmitted.
Fixes: b341a0263b1b ("rxrpc: Implement progressive transmission queue struct")
Link: https://sashiko.dev/#/patchset/20260616155749.2125907-1-dhowells%40redhat.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Marc Dionne <marc.dionne@auristor.com>
cc: Jeffrey Altman <jaltman@auristor.com>
cc: Eric Dumazet <edumazet@google.com>
cc: "David S. Miller" <davem@davemloft.net>
cc: Jakub Kicinski <kuba@kernel.org>
cc: Paolo Abeni <pabeni@redhat.com>
cc: Simon Horman <horms@kernel.org>
cc: linux-afs@lists.infradead.org
cc: stable@kernel.org
---
net/rxrpc/input.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/net/rxrpc/input.c b/net/rxrpc/input.c
index 2eedab1b0919..9bd0f1b92463 100644
--- a/net/rxrpc/input.c
+++ b/net/rxrpc/input.c
@@ -248,7 +248,7 @@ static bool rxrpc_rotate_tx_window(struct rxrpc_call *call, rxrpc_seq_t to,
tq = call->tx_queue;
}
- do {
+ while (before_eq(seq, to)) {
unsigned int ix = seq - call->tx_qbase;
_debug("tq=%x seq=%x i=%d f=%x", tq->qbase, seq, ix, tq->bufs[ix]->flags);
@@ -318,8 +318,7 @@ static bool rxrpc_rotate_tx_window(struct rxrpc_call *call, rxrpc_seq_t to,
break;
}
}
-
- } while (before_eq(seq, to));
+ }
if (trace)
trace_rxrpc_rack_update(call, summary);
@@ -394,6 +393,14 @@ static bool rxrpc_receiving_reply(struct rxrpc_call *call)
trace_rxrpc_timer_can(call, rxrpc_timer_trace_delayed_ack);
}
+ /* Deal with an apparent reply coming in before we've got the request
+ * queued or transmitted.
+ */
+ if (!test_bit(RXRPC_CALL_EXPOSED, &call->flags)) {
+ rxrpc_proto_abort(call, top, rxrpc_eproto_early_reply);
+ return false;
+ }
+
if (!test_bit(RXRPC_CALL_TX_LAST, &call->flags)) {
if (!rxrpc_rotate_tx_window(call, top, &summary)) {
rxrpc_proto_abort(call, top, rxrpc_eproto_early_reply);
^ permalink raw reply related
* [PATCH net v3 05/11] afs: Fix uncancelled rxrpc OOB message handler
From: David Howells @ 2026-06-24 16:38 UTC (permalink / raw)
To: netdev
Cc: David Howells, Marc Dionne, Jakub Kicinski, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, linux-afs, linux-kernel,
Li Daming, Ren Wei, Jeffrey Altman, stable
In-Reply-To: <20260624163819.3017002-1-dhowells@redhat.com>
Fix AFS to cancel its OOB message processing (typically to respond to
security challenges). Also move OOB message processing to afs_wq so that
it's also waited for and make the OOB handler just return if the net
namespace is no longer live.
Fixes: 5800b1cf3fd8 ("rxrpc: Allow CHALLENGEs to the passed to the app for a RESPONSE")
Link: https://sashiko.dev/#/patchset/20260609140911.838677-1-dhowells%40redhat.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Li Daming <d4n.for.sec@gmail.com>
cc: Ren Wei <n05ec@lzu.edu.cn>
cc: Marc Dionne <marc.dionne@auristor.com>
cc: Jeffrey Altman <jaltman@auristor.com>
cc: Eric Dumazet <edumazet@google.com>
cc: "David S. Miller" <davem@davemloft.net>
cc: Jakub Kicinski <kuba@kernel.org>
cc: Paolo Abeni <pabeni@redhat.com>
cc: Simon Horman <horms@kernel.org>
cc: linux-afs@lists.infradead.org
cc: stable@kernel.org
---
fs/afs/cm_security.c | 3 ++-
fs/afs/rxrpc.c | 5 ++++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/fs/afs/cm_security.c b/fs/afs/cm_security.c
index edcbd249d202..103168c70dd4 100644
--- a/fs/afs/cm_security.c
+++ b/fs/afs/cm_security.c
@@ -101,7 +101,8 @@ void afs_process_oob_queue(struct work_struct *work)
struct sk_buff *oob;
enum rxrpc_oob_type type;
- while ((oob = rxrpc_kernel_dequeue_oob(net->socket, &type))) {
+ while (READ_ONCE(net->live) &&
+ (oob = rxrpc_kernel_dequeue_oob(net->socket, &type))) {
switch (type) {
case RXRPC_OOB_CHALLENGE:
afs_respond_to_challenge(oob);
diff --git a/fs/afs/rxrpc.c b/fs/afs/rxrpc.c
index 6714a189d58f..d82916657a3d 100644
--- a/fs/afs/rxrpc.c
+++ b/fs/afs/rxrpc.c
@@ -128,6 +128,7 @@ void afs_close_socket(struct afs_net *net)
_enter("");
cancel_work_sync(&net->charge_preallocation_work);
+ cancel_work_sync(&net->rx_oob_work);
/* Future work items should now see ->live is false. */
kernel_listen(net->socket, 0);
@@ -148,6 +149,7 @@ void afs_close_socket(struct afs_net *net)
kernel_sock_shutdown(net->socket, SHUT_RDWR);
flush_workqueue(afs_async_calls);
+ cancel_work_sync(&net->rx_oob_work);
net->socket->sk->sk_user_data = NULL;
sock_release(net->socket);
key_put(net->fs_cm_token_key);
@@ -989,5 +991,6 @@ static void afs_rx_notify_oob(struct sock *sk, struct sk_buff *oob)
{
struct afs_net *net = sk->sk_user_data;
- schedule_work(&net->rx_oob_work);
+ if (READ_ONCE(net->live))
+ queue_work(afs_wq, &net->rx_oob_work);
}
^ permalink raw reply related
* [PATCH net v3 04/11] afs: Fix further netns teardown to cancel the preallocation charger
From: David Howells @ 2026-06-24 16:38 UTC (permalink / raw)
To: netdev
Cc: David Howells, Marc Dionne, Jakub Kicinski, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, linux-afs, linux-kernel,
Li Daming, Ren Wei, Jeffrey Altman, stable
In-Reply-To: <20260624163819.3017002-1-dhowells@redhat.com>
When an afs network namespace is torn down, it cancels and waits for the
work item that keeps the preallocated rxrpc call/conn/peer queue charged
before disabling incoming (i.e. listen 0), but there's a small window in
which it can be requeued by an incoming call wending through the I/O
thread.
Fix this by cancelling the charger work item again after reducing the
listen backlog to zero.
Fixes: 47694fbc9d24 ("afs: Fix netns teardown to cancel the preallocation charger")
Reported-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://sashiko.dev/#/patchset/20260609140911.838677-1-dhowells%40redhat.com
cc: Li Daming <d4n.for.sec@gmail.com>
cc: Ren Wei <n05ec@lzu.edu.cn>
cc: Marc Dionne <marc.dionne@auristor.com>
cc: Jeffrey Altman <jaltman@auristor.com>
cc: Eric Dumazet <edumazet@google.com>
cc: "David S. Miller" <davem@davemloft.net>
cc: Paolo Abeni <pabeni@redhat.com>
cc: Simon Horman <horms@kernel.org>
cc: linux-afs@lists.infradead.org
cc: stable@kernel.org
---
fs/afs/rxrpc.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/fs/afs/rxrpc.c b/fs/afs/rxrpc.c
index d5cfd24e815b..6714a189d58f 100644
--- a/fs/afs/rxrpc.c
+++ b/fs/afs/rxrpc.c
@@ -128,8 +128,13 @@ void afs_close_socket(struct afs_net *net)
_enter("");
cancel_work_sync(&net->charge_preallocation_work);
+ /* Future work items should now see ->live is false. */
+
kernel_listen(net->socket, 0);
+
+ /* Make sure work items are no longer running. */
flush_workqueue(afs_async_calls);
+ cancel_work_sync(&net->charge_preallocation_work);
if (net->spare_incoming_call) {
afs_put_call(net->spare_incoming_call);
^ permalink raw reply related
* [PATCH net v3 03/11] rxrpc: Fix double unlock in rxrpc_recvmsg()
From: David Howells @ 2026-06-24 16:38 UTC (permalink / raw)
To: netdev
Cc: David Howells, Marc Dionne, Jakub Kicinski, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, linux-afs, linux-kernel,
stable
In-Reply-To: <20260624163819.3017002-1-dhowells@redhat.com>
Fix a double unlock in rxrpc_recvmsg() when dealing with OOB messages.
Fixes: 5800b1cf3fd8 ("rxrpc: Allow CHALLENGEs to the passed to the app for a RESPONSE")
Link: https://sashiko.dev/#/patchset/20260609140911.838677-1-dhowells%40redhat.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Marc Dionne <marc.dionne@auristor.com>
cc: Eric Dumazet <edumazet@google.com>
cc: "David S. Miller" <davem@davemloft.net>
cc: Jakub Kicinski <kuba@kernel.org>
cc: Paolo Abeni <pabeni@redhat.com>
cc: Simon Horman <horms@kernel.org>
cc: linux-afs@lists.infradead.org
cc: stable@kernel.org
---
net/rxrpc/recvmsg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/rxrpc/recvmsg.c b/net/rxrpc/recvmsg.c
index 82614cbdb60f..39a03684432d 100644
--- a/net/rxrpc/recvmsg.c
+++ b/net/rxrpc/recvmsg.c
@@ -471,7 +471,7 @@ int rxrpc_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
release_sock(&rx->sk);
if (ret == -EAGAIN)
goto try_again;
- goto error_no_call;
+ goto error_trace;
}
/* Find the next call and dequeue it if we're not just peeking. If we
^ permalink raw reply related
* [PATCH net v3 02/11] rxrpc: Fix leak of connection from OOB challenge
From: David Howells @ 2026-06-24 16:38 UTC (permalink / raw)
To: netdev
Cc: David Howells, Marc Dionne, Jakub Kicinski, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, linux-afs, linux-kernel,
stable
In-Reply-To: <20260624163819.3017002-1-dhowells@redhat.com>
Fix leak of connection object from OOB challenge queue when response is
provided by userspace.
Fixes: 5800b1cf3fd8 ("rxrpc: Allow CHALLENGEs to the passed to the app for a RESPONSE")
Link: https://sashiko.dev/#/patchset/20260609140911.838677-1-dhowells%40redhat.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Marc Dionne <marc.dionne@auristor.com>
cc: Eric Dumazet <edumazet@google.com>
cc: "David S. Miller" <davem@davemloft.net>
cc: Jakub Kicinski <kuba@kernel.org>
cc: Paolo Abeni <pabeni@redhat.com>
cc: Simon Horman <horms@kernel.org>
cc: linux-afs@lists.infradead.org
cc: stable@kernel.org
---
net/rxrpc/oob.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/rxrpc/oob.c b/net/rxrpc/oob.c
index 05ca9c1faa57..3318c8bd82ad 100644
--- a/net/rxrpc/oob.c
+++ b/net/rxrpc/oob.c
@@ -210,6 +210,11 @@ static int rxrpc_respond_to_oob(struct rxrpc_sock *rx,
break;
}
+ switch (skb->mark) {
+ case RXRPC_OOB_CHALLENGE:
+ rxrpc_put_connection(sp->chall.conn, rxrpc_conn_put_oob);
+ break;
+ }
rxrpc_free_skb(skb, rxrpc_skb_put_oob);
return ret;
}
^ permalink raw reply related
* [PATCH net v3 01/11] rxrpc: Fix ACKALL packet handling
From: David Howells @ 2026-06-24 16:38 UTC (permalink / raw)
To: netdev
Cc: David Howells, Marc Dionne, Jakub Kicinski, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, linux-afs, linux-kernel,
Wyatt Feng, Yuan Tan, Yifan Wu, Juefei Pu, Zhengchuan Liang,
Xin Liu, Ren Wei, stable
In-Reply-To: <20260624163819.3017002-1-dhowells@redhat.com>
From: Wyatt Feng <bronzed_45_vested@icloud.com>
rxrpc_input_ackall() accepts ACKALL packets without checking whether the
call is in a state that can legitimately have outstanding transmit buffers.
A forged ACKALL can therefore reach a new service call in
RXRPC_CALL_SERVER_RECV_REQUEST before any reply packets have been queued.
In that state call->tx_top is zero and call->tx_queue is NULL, so
rxrpc_rotate_tx_window() dereferences a NULL txqueue and triggers a
null-pointer dereference.
Fix the handling of ACKALL packets by the following means:
(1) Add two new call states: RXRPC_CALL_CLIENT_PRE_SEND which indicates
that the client call is connected, but nothing has been transmitted as
yet; and RXRPC_CALL_CLIENT_AWAIT_ACK, which indicates that everything
has been transmitted at least once, but we're now waiting for the
stuff remaining in the Tx buffer to be ACK'd (retransmissions may
still happen).
The RXRPC_CALL_CLIENT_PRE_SEND state is set when the call is assigned
a channel and transitions to RXRPC_CALL_CLIENT_SEND_REQUEST when the
first packet is transmitted.
RXRPC_CALL_CLIENT_AWAIT_REPLY is then narrowed in scope to indicate
that all Tx packets have been ACK'd and we're now waiting for the
reply to be received.
(2) As per Wyatt Feng's original patch[1], the ACKALL handler then checks
that the call state is one in which there might be stuff in the Tx
buffer to ACK, but now this includes AWAIT_ACK rather than
AWAIT_REPLY. ACKALL packets are ignored if received in the wrong
state.
Note that unlike Wyatt Feng's patch, it's no longer necessary to check
to see if the Tx buffer exists as this the state set now covers this.
(3) Make the ACKALL handler use call->tx_transmitted rather than
call->tx_top as the former is explicitly the highest packet seq number
transmitted, whereas the latter has a looser definition.
Thanks to Jeffrey Altman for a description of the history of the ACKALL
packet[1].
Fixes: b341a0263b1b ("rxrpc: Implement progressive transmission queue struct")
Reported-by: Yuan Tan <yuantan098@gmail.com>
Reported-by: Yifan Wu <yifanwucs@gmail.com>
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Reported-by: Zhengchuan Liang <zcliangcn@gmail.com>
Reported-by: Xin Liu <bird@lzu.edu.cn>
Signed-off-by: Wyatt Feng <bronzed_45_vested@icloud.com>
Co-developed-by: David Howells <dhowells@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Ren Wei <n05ec@lzu.edu.cn>
cc: Marc Dionne <marc.dionne@auristor.com>
cc: linux-afs@lists.infradead.org
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20260616155749.2125907-2-dhowells@redhat.com/ [1]
Link: https://lore.kernel.org/r/c0fd4fec-1576-4070-b31e-a37d5506f5ed@auristor.com/ [2]
---
net/rxrpc/ar-internal.h | 2 ++
net/rxrpc/call_event.c | 5 ++++-
net/rxrpc/call_object.c | 2 ++
net/rxrpc/conn_client.c | 2 +-
net/rxrpc/input.c | 23 +++++++++++++++++++----
net/rxrpc/sendmsg.c | 3 ++-
6 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/net/rxrpc/ar-internal.h b/net/rxrpc/ar-internal.h
index 98f2165159d7..b6ccd8a8199b 100644
--- a/net/rxrpc/ar-internal.h
+++ b/net/rxrpc/ar-internal.h
@@ -650,7 +650,9 @@ enum rxrpc_call_event {
enum rxrpc_call_state {
RXRPC_CALL_UNINITIALISED,
RXRPC_CALL_CLIENT_AWAIT_CONN, /* - client waiting for connection to become available */
+ RXRPC_CALL_CLIENT_PRE_SEND, /* - client is connected, but hasn't sent anything yet */
RXRPC_CALL_CLIENT_SEND_REQUEST, /* - client sending request phase */
+ RXRPC_CALL_CLIENT_AWAIT_ACK, /* - client awaiting ACKs of request */
RXRPC_CALL_CLIENT_AWAIT_REPLY, /* - client awaiting reply */
RXRPC_CALL_CLIENT_RECV_REPLY, /* - client receiving reply phase */
RXRPC_CALL_SERVER_PREALLOC, /* - service preallocation */
diff --git a/net/rxrpc/call_event.c b/net/rxrpc/call_event.c
index fec59d9338b9..21be9c86d7a7 100644
--- a/net/rxrpc/call_event.c
+++ b/net/rxrpc/call_event.c
@@ -178,7 +178,7 @@ static void rxrpc_close_tx_phase(struct rxrpc_call *call)
switch (__rxrpc_call_state(call)) {
case RXRPC_CALL_CLIENT_SEND_REQUEST:
- rxrpc_set_call_state(call, RXRPC_CALL_CLIENT_AWAIT_REPLY);
+ rxrpc_set_call_state(call, RXRPC_CALL_CLIENT_AWAIT_ACK);
break;
case RXRPC_CALL_SERVER_SEND_REPLY:
rxrpc_set_call_state(call, RXRPC_CALL_SERVER_AWAIT_ACK);
@@ -244,6 +244,8 @@ static void rxrpc_transmit_fresh_data(struct rxrpc_call *call, unsigned int limi
break;
} while (req.n < limit && before(seq, send_top));
+ if (__rxrpc_call_state(call) == RXRPC_CALL_CLIENT_PRE_SEND)
+ rxrpc_set_call_state(call, RXRPC_CALL_CLIENT_SEND_REQUEST);
if (txb->flags & RXRPC_LAST_PACKET) {
rxrpc_close_tx_phase(call);
tq = NULL;
@@ -267,6 +269,7 @@ void rxrpc_transmit_some_data(struct rxrpc_call *call, unsigned int limit,
fallthrough;
case RXRPC_CALL_SERVER_SEND_REPLY:
+ case RXRPC_CALL_CLIENT_PRE_SEND:
case RXRPC_CALL_CLIENT_SEND_REQUEST:
if (!rxrpc_tx_window_space(call))
return;
diff --git a/net/rxrpc/call_object.c b/net/rxrpc/call_object.c
index fcb9d38bb521..817ed9acb91e 100644
--- a/net/rxrpc/call_object.c
+++ b/net/rxrpc/call_object.c
@@ -18,7 +18,9 @@
const char *const rxrpc_call_states[NR__RXRPC_CALL_STATES] = {
[RXRPC_CALL_UNINITIALISED] = "Uninit ",
[RXRPC_CALL_CLIENT_AWAIT_CONN] = "ClWtConn",
+ [RXRPC_CALL_CLIENT_PRE_SEND] = "ClPreSnd",
[RXRPC_CALL_CLIENT_SEND_REQUEST] = "ClSndReq",
+ [RXRPC_CALL_CLIENT_AWAIT_ACK] = "ClAwtAck",
[RXRPC_CALL_CLIENT_AWAIT_REPLY] = "ClAwtRpl",
[RXRPC_CALL_CLIENT_RECV_REPLY] = "ClRcvRpl",
[RXRPC_CALL_SERVER_PREALLOC] = "SvPrealc",
diff --git a/net/rxrpc/conn_client.c b/net/rxrpc/conn_client.c
index 9b757798dedd..48519f0de185 100644
--- a/net/rxrpc/conn_client.c
+++ b/net/rxrpc/conn_client.c
@@ -449,7 +449,7 @@ static void rxrpc_activate_one_channel(struct rxrpc_connection *conn,
trace_rxrpc_connect_call(call);
call->tx_last_sent = ktime_get_real();
rxrpc_start_call_timer(call);
- rxrpc_set_call_state(call, RXRPC_CALL_CLIENT_SEND_REQUEST);
+ rxrpc_set_call_state(call, RXRPC_CALL_CLIENT_PRE_SEND);
wake_up(&call->waitq);
}
diff --git a/net/rxrpc/input.c b/net/rxrpc/input.c
index ce761466b02d..2eedab1b0919 100644
--- a/net/rxrpc/input.c
+++ b/net/rxrpc/input.c
@@ -181,7 +181,8 @@ void rxrpc_congestion_degrade(struct rxrpc_call *call)
if (call->cong_ca_state != RXRPC_CA_SLOW_START &&
call->cong_ca_state != RXRPC_CA_CONGEST_AVOIDANCE)
return;
- if (__rxrpc_call_state(call) == RXRPC_CALL_CLIENT_AWAIT_REPLY)
+ if (__rxrpc_call_state(call) == RXRPC_CALL_CLIENT_AWAIT_ACK ||
+ __rxrpc_call_state(call) == RXRPC_CALL_CLIENT_AWAIT_REPLY)
return;
rtt = ns_to_ktime(call->srtt_us * (NSEC_PER_USEC / 8));
@@ -356,6 +357,7 @@ static void rxrpc_end_tx_phase(struct rxrpc_call *call, bool reply_begun,
switch (__rxrpc_call_state(call)) {
case RXRPC_CALL_CLIENT_SEND_REQUEST:
+ case RXRPC_CALL_CLIENT_AWAIT_ACK:
case RXRPC_CALL_CLIENT_AWAIT_REPLY:
if (reply_begun) {
rxrpc_set_call_state(call, RXRPC_CALL_CLIENT_RECV_REPLY);
@@ -694,6 +696,7 @@ static void rxrpc_input_data(struct rxrpc_call *call, struct sk_buff *skb)
switch (__rxrpc_call_state(call)) {
case RXRPC_CALL_CLIENT_SEND_REQUEST:
+ case RXRPC_CALL_CLIENT_AWAIT_ACK:
case RXRPC_CALL_CLIENT_AWAIT_REPLY:
/* Received data implicitly ACKs all of the request
* packets we sent when we're acting as a client.
@@ -1154,10 +1157,12 @@ static void rxrpc_input_ack(struct rxrpc_call *call, struct sk_buff *skb)
if (hard_ack + 1 == 0)
return rxrpc_proto_abort(call, 0, rxrpc_eproto_ackr_zero);
- /* Ignore ACKs unless we are or have just been transmitting. */
+ /* Ignore ACKs unless we are transmitting or are waiting for
+ * acknowledgement of the packets we've just been transmitting.
+ */
switch (__rxrpc_call_state(call)) {
case RXRPC_CALL_CLIENT_SEND_REQUEST:
- case RXRPC_CALL_CLIENT_AWAIT_REPLY:
+ case RXRPC_CALL_CLIENT_AWAIT_ACK:
case RXRPC_CALL_SERVER_SEND_REPLY:
case RXRPC_CALL_SERVER_AWAIT_ACK:
break;
@@ -1215,7 +1220,17 @@ static void rxrpc_input_ackall(struct rxrpc_call *call, struct sk_buff *skb)
{
struct rxrpc_ack_summary summary = { 0 };
- if (rxrpc_rotate_tx_window(call, call->tx_top, &summary))
+ switch (__rxrpc_call_state(call)) {
+ case RXRPC_CALL_CLIENT_SEND_REQUEST:
+ case RXRPC_CALL_CLIENT_AWAIT_ACK:
+ case RXRPC_CALL_SERVER_SEND_REPLY:
+ case RXRPC_CALL_SERVER_AWAIT_ACK:
+ break;
+ default:
+ return;
+ }
+
+ if (rxrpc_rotate_tx_window(call, call->tx_transmitted, &summary))
rxrpc_end_tx_phase(call, false, rxrpc_eproto_unexpected_ackall);
}
diff --git a/net/rxrpc/sendmsg.c b/net/rxrpc/sendmsg.c
index c35de4fd75e3..ed2c9a51005a 100644
--- a/net/rxrpc/sendmsg.c
+++ b/net/rxrpc/sendmsg.c
@@ -366,7 +366,8 @@ static int rxrpc_send_data(struct rxrpc_sock *rx,
if (state >= RXRPC_CALL_COMPLETE)
goto maybe_error;
ret = -EPROTO;
- if (state != RXRPC_CALL_CLIENT_SEND_REQUEST &&
+ if (state != RXRPC_CALL_CLIENT_PRE_SEND &&
+ state != RXRPC_CALL_CLIENT_SEND_REQUEST &&
state != RXRPC_CALL_SERVER_ACK_REQUEST &&
state != RXRPC_CALL_SERVER_SEND_REPLY) {
/* Request phase complete for this client call */
^ permalink raw reply related
* [PATCH net v3 00/11] rxrpc: Miscellaneous fixes
From: David Howells @ 2026-06-24 16:38 UTC (permalink / raw)
To: netdev
Cc: David Howells, Marc Dionne, Jakub Kicinski, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, linux-afs, linux-kernel
Here are some miscellaneous AF_RXRPC fixes for more stuff found by Sashiko[1][2]:
(1) Fix ACKALL handling by adding two more call states to simplify when
ACKs are valid.
(2) Fix connection leak from AF_RXRPC recvmsg userspace OOB handling.
(3) Fix double unlock in AF_RXRPC recvmsg userspace OOB handling.
(4) Fix AFS preallocate charge to flush the waitqueue after unlistening
the socket so that any charging thread that does manage to get started
will be waited for before socket destruction.
(5) Fix AFS OOB notify handling to cancel in-progress OOB notification
handling and then to flush the workqueue it's on.
(6) Fix handling of apparent reply reception before initial transmission
starts in client call.
(7) Fix OOB challenge leak in cleanup on notification failure.
(8) Fix infinite loop in recvmsg if OOB packet available, but no calls.
(9) Fix notify vs recvmsg race where notify thinks the call is already
queued.
(10) Fix MSG_PEEK call leak for calls with no content.
(11) Fix rxrpc_rotate_tx_window() to check that there's something in the Tx
buffer before attempting to rotate it.
Note that the latest Sashiko review[3] has some more pre-existing issues,
but I'd like to get this set of fixes committed before tackling those.
David
The patches can be found here also:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-fixes
[1] https://sashiko.dev/#/patchset/20260609140911.838677-1-dhowells%40redhat.com
[2] https://sashiko.dev/#/patchset/20260616155749.2125907-1-dhowells%40redhat.com
[3] https://sashiko.dev/#/patchset/20260618134802.2477777-1-dhowells%40redhat.com
Changes
=======
ver #3)
- Rewrote ACKALL fix to add two new call states to make it easier to track
when ACKs are valid.
- Addressed the Sashiko review[3]:
- Use READ_ONCE() to access net->live.
- Added a patch to check the Tx buffer is occupied before rotating it.
ver #2)
- Addressed the Sashiko review[2] of ver #1:
- Added patches to fix more bugs that it found.
- Adjusted AFS preallocate charge cleanup to only cancel the preallocate
work item after unlistening rather than flushing the entire waitqueue
(which may be waiting on DNS lookup).
- Added extra cancel for OOB rx handler in AFS.
David Howells (10):
rxrpc: Fix leak of connection from OOB challenge
rxrpc: Fix double unlock in rxrpc_recvmsg()
afs: Fix further netns teardown to cancel the preallocation charger
afs: Fix uncancelled rxrpc OOB message handler
rxrpc: Fix the reception of a reply packet before data transmission
rxrpc: Fix oob challenge leak in cleanup after notification failure
rxrpc: Fix potential infinite loop in rxrpc_recvmsg()
rxrpc: Fix socket notification race
rxrpc: Fix leak of released call in recvmsg(MSG_PEEK)
rxrpc: Fix rxrpc_rotate_tx_rotate() to check there's something to
rotate
Wyatt Feng (1):
rxrpc: Fix ACKALL packet handling
fs/afs/cm_security.c | 3 ++-
fs/afs/rxrpc.c | 10 +++++++++-
net/rxrpc/ar-internal.h | 6 ++++--
net/rxrpc/call_event.c | 5 ++++-
net/rxrpc/call_object.c | 2 ++
net/rxrpc/conn_client.c | 2 +-
net/rxrpc/conn_event.c | 9 +++++++--
net/rxrpc/input.c | 39 ++++++++++++++++++++++++++++++++-------
net/rxrpc/oob.c | 12 ++++++++++--
net/rxrpc/recvmsg.c | 10 ++++------
net/rxrpc/sendmsg.c | 3 ++-
11 files changed, 77 insertions(+), 24 deletions(-)
^ 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