lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5632e043-bdba-4d75-bc7e-bf58014492fd@redhat.com>
Date: Thu, 19 Sep 2024 11:05:50 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Josh Hunt <johunt@...mai.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/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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ