linux-kernel - Re: [PATCH net-next v4] tcp: extend tcp_retransmit

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: <20250715072058.12f343bb@kernel.org>
Date: Tue, 15 Jul 2025 07:20:58 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: <fan.yu9@....com.cn>
Cc: <edumazet@...gle.com>, <kuniyu@...zon.com>, <ncardwell@...gle.com>,
 <davem@...emloft.net>, <netdev@...r.kernel.org>,
 <linux-kernel@...r.kernel.org>, <linux-trace-kernel@...r.kernel.org>,
 <yang.yang29@....com.cn>, <xu.xin16@....com.cn>, <tu.qiang35@....com.cn>,
 <jiang.kun2@....com.cn>, <pabeni@...hat.com>, <horms@...nel.org>
Subject: Re: [PATCH net-next v4] tcp: extend tcp_retransmit_skb tracepoint
 with failure reasons

On Tue, 15 Jul 2025 12:35:32 +0800 (CST) fan.yu9@....com.cn wrote:
> > -            return -EINVAL;
> > +            result = TCP_RETRANS_END_SEQ_ERROR;  
> 
> I agree that some of the result types (e.g., ENOMEM, END_SEQ_ERROR)
> may be redundant or unlikely in practice. If we focus only on the most
> critical cases, would the following subset be more acceptable?
> - TCP_RETRANS_FAIL_QUEUED (packet stuck in host/driver queue)
> - TCP_RETRANS_FAIL_ZERO_WINDOW (receiver window closed)
> - TCP_RETRANS_FAIL_ROUTE (routing issues)
> - TCP_RETRANS_FAIL_DEFAULT (catch-all for unexpected failures)

Isn't it enough to add the retval to the tracepoint?
All the cases we care about already have meaningful and distinct error
codes.