* [PATCH v3 net] tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().
@ 2024-10-14 22:33 Kuniyuki Iwashima
2024-10-15 7:55 ` Eric Dumazet
` (3 more replies)
0 siblings, 4 replies; 6+ messages in thread
From: Kuniyuki Iwashima @ 2024-10-14 22:33 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
David Ahern
Cc: Martin KaFai Lau, Kuniyuki Iwashima, Kuniyuki Iwashima, netdev
Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler().
"""
We are seeing a use-after-free from a bpf prog attached to
trace_tcp_retransmit_synack. The program passes the req->sk to the
bpf_sk_storage_get_tracing kernel helper which does check for null
before using it.
"""
The commit 83fccfc3940c ("inet: fix potential deadlock in
reqsk_queue_unlink()") added timer_pending() in reqsk_queue_unlink() not
to call del_timer_sync() from reqsk_timer_handler(), but it introduced a
small race window.
Before the timer is called, expire_timers() calls detach_timer(timer, true)
to clear timer->entry.pprev and marks it as not pending.
If reqsk_queue_unlink() checks timer_pending() just after expire_timers()
calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will
continue running and send multiple SYN+ACKs until it expires.
The reported UAF could happen if req->sk is close()d earlier than the timer
expiration, which is 63s by default.
The scenario would be
1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(),
but del_timer_sync() is missed
2. reqsk timer is executed and scheduled again
3. req->sk is accept()ed and reqsk_put() decrements rsk_refcnt, but
reqsk timer still has another one, and inet_csk_accept() does not
clear req->sk for non-TFO sockets
4. sk is close()d
5. reqsk timer is executed again, and BPF touches req->sk
Let's not use timer_pending() by passing the caller context to
__inet_csk_reqsk_queue_drop().
Note that reqsk timer is pinned, so the issue does not happen in most
use cases. [1]
[0]
BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0
Use-after-free read at 0x00000000a891fb3a (in kfence-#1):
bpf_sk_storage_get_tracing+0x2e/0x1b0
bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda
bpf_trace_run2+0x4c/0xc0
tcp_rtx_synack+0xf9/0x100
reqsk_timer_handler+0xda/0x3d0
run_timer_softirq+0x292/0x8a0
irq_exit_rcu+0xf5/0x320
sysvec_apic_timer_interrupt+0x6d/0x80
asm_sysvec_apic_timer_interrupt+0x16/0x20
intel_idle_irq+0x5a/0xa0
cpuidle_enter_state+0x94/0x273
cpu_startup_entry+0x15e/0x260
start_secondary+0x8a/0x90
secondary_startup_64_no_verify+0xfa/0xfb
kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6
allocated by task 0 on cpu 9 at 260507.901592s:
sk_prot_alloc+0x35/0x140
sk_clone_lock+0x1f/0x3f0
inet_csk_clone_lock+0x15/0x160
tcp_create_openreq_child+0x1f/0x410
tcp_v6_syn_recv_sock+0x1da/0x700
tcp_check_req+0x1fb/0x510
tcp_v6_rcv+0x98b/0x1420
ipv6_list_rcv+0x2258/0x26e0
napi_complete_done+0x5b1/0x2990
mlx5e_napi_poll+0x2ae/0x8d0
net_rx_action+0x13e/0x590
irq_exit_rcu+0xf5/0x320
common_interrupt+0x80/0x90
asm_common_interrupt+0x22/0x40
cpuidle_enter_state+0xfb/0x273
cpu_startup_entry+0x15e/0x260
start_secondary+0x8a/0x90
secondary_startup_64_no_verify+0xfa/0xfb
freed by task 0 on cpu 9 at 260507.927527s:
rcu_core_si+0x4ff/0xf10
irq_exit_rcu+0xf5/0x320
sysvec_apic_timer_interrupt+0x6d/0x80
asm_sysvec_apic_timer_interrupt+0x16/0x20
cpuidle_enter_state+0xfb/0x273
cpu_startup_entry+0x15e/0x260
start_secondary+0x8a/0x90
secondary_startup_64_no_verify+0xfa/0xfb
Fixes: 83fccfc3940c ("inet: fix potential deadlock in reqsk_queue_unlink()")
Reported-by: Martin KaFai Lau <martin.lau@kernel.org>
Closes: https://lore.kernel.org/netdev/eb6684d0-ffd9-4bdc-9196-33f690c25824@linux.dev/
Link: https://lore.kernel.org/netdev/b55e2ca0-42f2-4b7c-b445-6ffd87ca74a0@linux.dev/ [1]
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
---
v3:
* Stop timer before reqsk_queue_removed().
v2: https://lore.kernel.org/netdev/20241009174226.7738-1-kuniyu@amazon.com/
* Added issue scenario in changelog
* Correct reqsk for __inet_csk_reqsk_queue_drop()
v1: https://lore.kernel.org/netdev/20241007141557.14424-1-kuniyu@amazon.com/
---
net/ipv4/inet_connection_sock.c | 21 ++++++++++++++++-----
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index 2c5632d4fddb..2b698f8419fe 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -1045,21 +1045,31 @@ static bool reqsk_queue_unlink(struct request_sock *req)
found = __sk_nulls_del_node_init_rcu(sk);
spin_unlock(lock);
}
- if (timer_pending(&req->rsk_timer) && del_timer_sync(&req->rsk_timer))
- reqsk_put(req);
+
return found;
}
-bool inet_csk_reqsk_queue_drop(struct sock *sk, struct request_sock *req)
+static bool __inet_csk_reqsk_queue_drop(struct sock *sk,
+ struct request_sock *req,
+ bool from_timer)
{
bool unlinked = reqsk_queue_unlink(req);
+ if (!from_timer && timer_delete_sync(&req->rsk_timer))
+ reqsk_put(req);
+
if (unlinked) {
reqsk_queue_removed(&inet_csk(sk)->icsk_accept_queue, req);
reqsk_put(req);
}
+
return unlinked;
}
+
+bool inet_csk_reqsk_queue_drop(struct sock *sk, struct request_sock *req)
+{
+ return __inet_csk_reqsk_queue_drop(sk, req, false);
+}
EXPORT_SYMBOL(inet_csk_reqsk_queue_drop);
void inet_csk_reqsk_queue_drop_and_put(struct sock *sk, struct request_sock *req)
@@ -1152,7 +1162,7 @@ static void reqsk_timer_handler(struct timer_list *t)
if (!inet_ehash_insert(req_to_sk(nreq), req_to_sk(oreq), NULL)) {
/* delete timer */
- inet_csk_reqsk_queue_drop(sk_listener, nreq);
+ __inet_csk_reqsk_queue_drop(sk_listener, nreq, true);
goto no_ownership;
}
@@ -1178,7 +1188,8 @@ static void reqsk_timer_handler(struct timer_list *t)
}
drop:
- inet_csk_reqsk_queue_drop_and_put(oreq->rsk_listener, oreq);
+ __inet_csk_reqsk_queue_drop(sk_listener, oreq, true);
+ reqsk_put(req);
}
static bool reqsk_queue_hash_req(struct request_sock *req,
--
2.39.5 (Apple Git-154)
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v3 net] tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().
2024-10-14 22:33 [PATCH v3 net] tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink() Kuniyuki Iwashima
@ 2024-10-15 7:55 ` Eric Dumazet
2024-10-15 17:37 ` Martin KaFai Lau
` (2 subsequent siblings)
3 siblings, 0 replies; 6+ messages in thread
From: Eric Dumazet @ 2024-10-15 7:55 UTC (permalink / raw)
To: Kuniyuki Iwashima
Cc: David S. Miller, Jakub Kicinski, Paolo Abeni, David Ahern,
Martin KaFai Lau, Kuniyuki Iwashima, netdev
On Tue, Oct 15, 2024 at 12:33 AM Kuniyuki Iwashima <kuniyu@amazon.com> wrote:
>
> Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler().
>
> """
> We are seeing a use-after-free from a bpf prog attached to
> trace_tcp_retransmit_synack. The program passes the req->sk to the
> bpf_sk_storage_get_tracing kernel helper which does check for null
> before using it.
> """
>
> The commit 83fccfc3940c ("inet: fix potential deadlock in
> reqsk_queue_unlink()") added timer_pending() in reqsk_queue_unlink() not
> to call del_timer_sync() from reqsk_timer_handler(), but it introduced a
> small race window.
>
> Before the timer is called, expire_timers() calls detach_timer(timer, true)
> to clear timer->entry.pprev and marks it as not pending.
>
> If reqsk_queue_unlink() checks timer_pending() just after expire_timers()
> calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will
> continue running and send multiple SYN+ACKs until it expires.
>
> The reported UAF could happen if req->sk is close()d earlier than the timer
> expiration, which is 63s by default.
>
>
> Fixes: 83fccfc3940c ("inet: fix potential deadlock in reqsk_queue_unlink()")
> Reported-by: Martin KaFai Lau <martin.lau@kernel.org>
> Closes: https://lore.kernel.org/netdev/eb6684d0-ffd9-4bdc-9196-33f690c25824@linux.dev/
> Link: https://lore.kernel.org/netdev/b55e2ca0-42f2-4b7c-b445-6ffd87ca74a0@linux.dev/ [1]
> Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v3 net] tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().
2024-10-14 22:33 [PATCH v3 net] tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink() Kuniyuki Iwashima
2024-10-15 7:55 ` Eric Dumazet
@ 2024-10-15 17:37 ` Martin KaFai Lau
2024-10-16 1:00 ` patchwork-bot+netdevbpf
2024-11-23 13:24 ` liujian (CE)
3 siblings, 0 replies; 6+ messages in thread
From: Martin KaFai Lau @ 2024-10-15 17:37 UTC (permalink / raw)
To: Kuniyuki Iwashima
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
David Ahern, Martin KaFai Lau, Kuniyuki Iwashima, netdev
On 10/14/24 3:33 PM, Kuniyuki Iwashima wrote:
> Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler().
>
> """
> We are seeing a use-after-free from a bpf prog attached to
> trace_tcp_retransmit_synack. The program passes the req->sk to the
> bpf_sk_storage_get_tracing kernel helper which does check for null
> before using it.
> """
>
> The commit 83fccfc3940c ("inet: fix potential deadlock in
> reqsk_queue_unlink()") added timer_pending() in reqsk_queue_unlink() not
> to call del_timer_sync() from reqsk_timer_handler(), but it introduced a
> small race window.
>
> Before the timer is called, expire_timers() calls detach_timer(timer, true)
> to clear timer->entry.pprev and marks it as not pending.
>
> If reqsk_queue_unlink() checks timer_pending() just after expire_timers()
> calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will
> continue running and send multiple SYN+ACKs until it expires.
>
> The reported UAF could happen if req->sk is close()d earlier than the timer
> expiration, which is 63s by default.
>
> The scenario would be
>
> 1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(),
> but del_timer_sync() is missed
>
> 2. reqsk timer is executed and scheduled again
>
> 3. req->sk is accept()ed and reqsk_put() decrements rsk_refcnt, but
> reqsk timer still has another one, and inet_csk_accept() does not
> clear req->sk for non-TFO sockets
>
> 4. sk is close()d
>
> 5. reqsk timer is executed again, and BPF touches req->sk
>
> Let's not use timer_pending() by passing the caller context to
> __inet_csk_reqsk_queue_drop().
>
>
> Fixes: 83fccfc3940c ("inet: fix potential deadlock in reqsk_queue_unlink()")
> Reported-by: Martin KaFai Lau <martin.lau@kernel.org>
> Closes: https://lore.kernel.org/netdev/eb6684d0-ffd9-4bdc-9196-33f690c25824@linux.dev/
> Link: https://lore.kernel.org/netdev/b55e2ca0-42f2-4b7c-b445-6ffd87ca74a0@linux.dev/ [1]
> Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Reviewed-by: Martin KaFai Lau <martin.lau@kernel.org>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v3 net] tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().
2024-10-14 22:33 [PATCH v3 net] tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink() Kuniyuki Iwashima
2024-10-15 7:55 ` Eric Dumazet
2024-10-15 17:37 ` Martin KaFai Lau
@ 2024-10-16 1:00 ` patchwork-bot+netdevbpf
2024-11-23 13:24 ` liujian (CE)
3 siblings, 0 replies; 6+ messages in thread
From: patchwork-bot+netdevbpf @ 2024-10-16 1:00 UTC (permalink / raw)
To: Kuniyuki Iwashima
Cc: davem, edumazet, kuba, pabeni, dsahern, martin.lau, kuni1840,
netdev
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 14 Oct 2024 15:33:12 -0700 you wrote:
> Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler().
>
> """
> We are seeing a use-after-free from a bpf prog attached to
> trace_tcp_retransmit_synack. The program passes the req->sk to the
> bpf_sk_storage_get_tracing kernel helper which does check for null
> before using it.
> """
>
> [...]
Here is the summary with links:
- [v3,net] tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().
https://git.kernel.org/netdev/net/c/e8c526f2bdf1
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v3 net] tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().
2024-10-14 22:33 [PATCH v3 net] tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink() Kuniyuki Iwashima
` (2 preceding siblings ...)
2024-10-16 1:00 ` patchwork-bot+netdevbpf
@ 2024-11-23 13:24 ` liujian (CE)
2024-11-23 17:18 ` Kuniyuki Iwashima
3 siblings, 1 reply; 6+ messages in thread
From: liujian (CE) @ 2024-11-23 13:24 UTC (permalink / raw)
To: Kuniyuki Iwashima, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Ahern
Cc: Martin KaFai Lau, Kuniyuki Iwashima, netdev, liujian56
在 2024/10/15 6:33, Kuniyuki Iwashima 写道:
> Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler().
>
> """
> We are seeing a use-after-free from a bpf prog attached to
> trace_tcp_retransmit_synack. The program passes the req->sk to the
> bpf_sk_storage_get_tracing kernel helper which does check for null
> before using it.
> """
>
> The commit 83fccfc3940c ("inet: fix potential deadlock in
> reqsk_queue_unlink()") added timer_pending() in reqsk_queue_unlink() not
> to call del_timer_sync() from reqsk_timer_handler(), but it introduced a
> small race window.
>
> Before the timer is called, expire_timers() calls detach_timer(timer, true)
> to clear timer->entry.pprev and marks it as not pending.
>
> If reqsk_queue_unlink() checks timer_pending() just after expire_timers()
> calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will
> continue running and send multiple SYN+ACKs until it expires.
>
> The reported UAF could happen if req->sk is close()d earlier than the timer
> expiration, which is 63s by default.
>
> The scenario would be
>
> 1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(),
> but del_timer_sync() is missed
>
> 2. reqsk timer is executed and scheduled again
>
> 3. req->sk is accept()ed and reqsk_put() decrements rsk_refcnt, but
> reqsk timer still has another one, and inet_csk_accept() does not
> clear req->sk for non-TFO sockets
>
> 4. sk is close()d
>
> 5. reqsk timer is executed again, and BPF touches req->sk
>
> Let's not use timer_pending() by passing the caller context to
> __inet_csk_reqsk_queue_drop().
>
> Note that reqsk timer is pinned, so the issue does not happen in most
> use cases. [1]
>
> [0]
> BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0
>
> Use-after-free read at 0x00000000a891fb3a (in kfence-#1):
> bpf_sk_storage_get_tracing+0x2e/0x1b0
> bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda
> bpf_trace_run2+0x4c/0xc0
> tcp_rtx_synack+0xf9/0x100
> reqsk_timer_handler+0xda/0x3d0
> run_timer_softirq+0x292/0x8a0
> irq_exit_rcu+0xf5/0x320
> sysvec_apic_timer_interrupt+0x6d/0x80
> asm_sysvec_apic_timer_interrupt+0x16/0x20
> intel_idle_irq+0x5a/0xa0
> cpuidle_enter_state+0x94/0x273
> cpu_startup_entry+0x15e/0x260
> start_secondary+0x8a/0x90
> secondary_startup_64_no_verify+0xfa/0xfb
>
> kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6
>
> allocated by task 0 on cpu 9 at 260507.901592s:
> sk_prot_alloc+0x35/0x140
> sk_clone_lock+0x1f/0x3f0
> inet_csk_clone_lock+0x15/0x160
> tcp_create_openreq_child+0x1f/0x410
> tcp_v6_syn_recv_sock+0x1da/0x700
> tcp_check_req+0x1fb/0x510
> tcp_v6_rcv+0x98b/0x1420
> ipv6_list_rcv+0x2258/0x26e0
> napi_complete_done+0x5b1/0x2990
> mlx5e_napi_poll+0x2ae/0x8d0
> net_rx_action+0x13e/0x590
> irq_exit_rcu+0xf5/0x320
> common_interrupt+0x80/0x90
> asm_common_interrupt+0x22/0x40
> cpuidle_enter_state+0xfb/0x273
> cpu_startup_entry+0x15e/0x260
> start_secondary+0x8a/0x90
> secondary_startup_64_no_verify+0xfa/0xfb
>
> freed by task 0 on cpu 9 at 260507.927527s:
> rcu_core_si+0x4ff/0xf10
> irq_exit_rcu+0xf5/0x320
> sysvec_apic_timer_interrupt+0x6d/0x80
> asm_sysvec_apic_timer_interrupt+0x16/0x20
> cpuidle_enter_state+0xfb/0x273
> cpu_startup_entry+0x15e/0x260
> start_secondary+0x8a/0x90
> secondary_startup_64_no_verify+0xfa/0xfb
>
> Fixes: 83fccfc3940c ("inet: fix potential deadlock in reqsk_queue_unlink()")
> Reported-by: Martin KaFai Lau <martin.lau@kernel.org>
> Closes: https://lore.kernel.org/netdev/eb6684d0-ffd9-4bdc-9196-33f690c25824@linux.dev/
> Link: https://lore.kernel.org/netdev/b55e2ca0-42f2-4b7c-b445-6ffd87ca74a0@linux.dev/ [1]
> Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
> ---
> v3:
> * Stop timer before reqsk_queue_removed().
>
> v2: https://lore.kernel.org/netdev/20241009174226.7738-1-kuniyu@amazon.com/
> * Added issue scenario in changelog
> * Correct reqsk for __inet_csk_reqsk_queue_drop()
>
> v1: https://lore.kernel.org/netdev/20241007141557.14424-1-kuniyu@amazon.com/
> ---
> net/ipv4/inet_connection_sock.c | 21 ++++++++++++++++-----
> 1 file changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
> index 2c5632d4fddb..2b698f8419fe 100644
> --- a/net/ipv4/inet_connection_sock.c
> +++ b/net/ipv4/inet_connection_sock.c
> @@ -1045,21 +1045,31 @@ static bool reqsk_queue_unlink(struct request_sock *req)
> found = __sk_nulls_del_node_init_rcu(sk);
> spin_unlock(lock);
> }
> - if (timer_pending(&req->rsk_timer) && del_timer_sync(&req->rsk_timer))
> - reqsk_put(req);
> +
> return found;
> }
>
> -bool inet_csk_reqsk_queue_drop(struct sock *sk, struct request_sock *req)
> +static bool __inet_csk_reqsk_queue_drop(struct sock *sk,
> + struct request_sock *req,
> + bool from_timer)
> {
> bool unlinked = reqsk_queue_unlink(req);
>
> + if (!from_timer && timer_delete_sync(&req->rsk_timer))
> + reqsk_put(req);
> +
> if (unlinked) {
> reqsk_queue_removed(&inet_csk(sk)->icsk_accept_queue, req);
> reqsk_put(req);
> }
> +
> return unlinked;
> }
> +
> +bool inet_csk_reqsk_queue_drop(struct sock *sk, struct request_sock *req)
> +{
> + return __inet_csk_reqsk_queue_drop(sk, req, false);
> +}
> EXPORT_SYMBOL(inet_csk_reqsk_queue_drop);
>
> void inet_csk_reqsk_queue_drop_and_put(struct sock *sk, struct request_sock *req)
> @@ -1152,7 +1162,7 @@ static void reqsk_timer_handler(struct timer_list *t)
>
> if (!inet_ehash_insert(req_to_sk(nreq), req_to_sk(oreq), NULL)) {
> /* delete timer */
> - inet_csk_reqsk_queue_drop(sk_listener, nreq);
> + __inet_csk_reqsk_queue_drop(sk_listener, nreq, true);
> goto no_ownership;
> }
>
> @@ -1178,7 +1188,8 @@ static void reqsk_timer_handler(struct timer_list *t)
> }
>
> drop:
> - inet_csk_reqsk_queue_drop_and_put(oreq->rsk_listener, oreq);
> + __inet_csk_reqsk_queue_drop(sk_listener, oreq, true);
> + reqsk_put(req);
Excuse me, why is "req" used here instead of "oreq"?
Typo?
> }
>
> static bool reqsk_queue_hash_req(struct request_sock *req,
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v3 net] tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().
2024-11-23 13:24 ` liujian (CE)
@ 2024-11-23 17:18 ` Kuniyuki Iwashima
0 siblings, 0 replies; 6+ messages in thread
From: Kuniyuki Iwashima @ 2024-11-23 17:18 UTC (permalink / raw)
To: liujian56
Cc: davem, dsahern, edumazet, kuba, kuni1840, kuniyu, martin.lau,
netdev, pabeni
From: "liujian (CE)" <liujian56@huawei.com>
Date: Sat, 23 Nov 2024 21:24:39 +0800
> > @@ -1178,7 +1188,8 @@ static void reqsk_timer_handler(struct timer_list *t)
> > }
> >
> > drop:
> > - inet_csk_reqsk_queue_drop_and_put(oreq->rsk_listener, oreq);
> > + __inet_csk_reqsk_queue_drop(sk_listener, oreq, true);
> > + reqsk_put(req);
> Excuse me, why is "req" used here instead of "oreq"?
> Typo?
Oops, will post a followup.
Thanks!
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-11-23 17:18 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-10-14 22:33 [PATCH v3 net] tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink() Kuniyuki Iwashima
2024-10-15 7:55 ` Eric Dumazet
2024-10-15 17:37 ` Martin KaFai Lau
2024-10-16 1:00 ` patchwork-bot+netdevbpf
2024-11-23 13:24 ` liujian (CE)
2024-11-23 17:18 ` Kuniyuki Iwashima
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).