[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1fbd0d02-6c34-4bb4-b9b8-66e121ff67e3@akamai.com>
Date: Tue, 24 Sep 2024 10:26:17 -0700
From: Josh Hunt <johunt@...mai.com>
To: Paolo Abeni <pabeni@...hat.com>, edumazet@...gle.com, davem@...emloft.net,
kuba@...nel.org, netdev@...r.kernel.org, ncardwell@...gle.com
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH net v3] tcp: check skb is non-NULL in tcp_rto_delta_us()
On 9/19/24 2:05 AM, Paolo Abeni wrote:
> !-------------------------------------------------------------------|
> This Message Is From an External Sender
> This message came from outside your organization.
> |-------------------------------------------------------------------!
>
> On 9/10/24 21:08, Josh Hunt wrote:
>> diff --git a/include/net/tcp.h b/include/net/tcp.h
>> index 2aac11e7e1cc..196c148fce8a 100644
>> --- a/include/net/tcp.h
>> +++ b/include/net/tcp.h
>> @@ -2434,9 +2434,26 @@ static inline s64 tcp_rto_delta_us(const struct
>> sock *sk)
>> {
>> const struct sk_buff *skb = tcp_rtx_queue_head(sk);
>> u32 rto = inet_csk(sk)->icsk_rto;
>> - u64 rto_time_stamp_us = tcp_skb_timestamp_us(skb) +
>> jiffies_to_usecs(rto);
>> - return rto_time_stamp_us - tcp_sk(sk)->tcp_mstamp;
>> + if (likely(skb)) {
>> + u64 rto_time_stamp_us = tcp_skb_timestamp_us(skb) +
>> jiffies_to_usecs(rto);
>> +
>> + return rto_time_stamp_us - tcp_sk(sk)->tcp_mstamp;
>> + } else {
>> + WARN_ONCE(1,
>> + "rtx queue emtpy: "
>> + "out:%u sacked:%u lost:%u retrans:%u "
>> + "tlp_high_seq:%u sk_state:%u ca_state:%u "
>> + "advmss:%u mss_cache:%u pmtu:%u\n",
>> + tcp_sk(sk)->packets_out, tcp_sk(sk)->sacked_out,
>> + tcp_sk(sk)->lost_out, tcp_sk(sk)->retrans_out,
>> + tcp_sk(sk)->tlp_high_seq, sk->sk_state,
>> + inet_csk(sk)->icsk_ca_state,
>> + tcp_sk(sk)->advmss, tcp_sk(sk)->mss_cache,
>> + inet_csk(sk)->icsk_pmtu_cookie);
>
> As the underlying issue here share the same root cause as the one
> covered by the WARN_ONCE() in tcp_send_loss_probe(), I'm wondering if it
> would make sense do move the info dumping in a common helper, so that we
> get the verbose warning on either cases.
>
> Thanks,
>
> Paolo
Thanks for the review Paolo. Sorry for the delay in replying I was OOO.
I can send a follow-up commit to create a common helper.
Josh
Powered by blists - more mailing lists