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] [day] [month] [year] [list]
Message-ID: <20200706155517.96748-1-kuniyu@amazon.co.jp>
Date:   Tue, 7 Jul 2020 00:55:17 +0900
From:   Kuniyuki Iwashima <kuniyu@...zon.co.jp>
To:     <eric.dumazet@...il.com>
CC:     <benh@...zon.com>, <davem@...emloft.net>, <ja@....bg>,
        <kuba@...nel.org>, <kuni1840@...il.com>, <kuniyu@...zon.co.jp>,
        <kuznet@....inr.ac.ru>, <netdev@...r.kernel.org>,
        <osa-contribution-log@...zon.com>, <yoshfuji@...ux-ipv6.org>
Subject: Re: [PATCH v2 net-next] inet: Remove an unnecessary argument of syn_ack_recalc().

From:   Eric Dumazet <eric.dumazet@...il.com>
Date:   Sun, 5 Jul 2020 10:08:08 -0700
> On 7/4/20 8:28 AM, Kuniyuki Iwashima wrote:
> > Commit 0c3d79bce48034018e840468ac5a642894a521a3 ("tcp: reduce SYN-ACK
> > retrans for TCP_DEFER_ACCEPT") introduces syn_ack_recalc() which decides
> > if a minisock is held and a SYN+ACK is retransmitted or not.
> > 
> > If rskq_defer_accept is not zero in syn_ack_recalc(), max_retries always
> > has the same value because max_retries is overwritten by rskq_defer_accept
> > in reqsk_timer_handler().
> > 
> > This commit adds two changes:
> > - remove max_retries from the arguments of syn_ack_recalc() and use
> >    rskq_defer_accept instead.
> > - rename thresh to max_retries for readability.
> > 
> 
> Honestly this looks unnecessary code churn to me.
> 
> This will make future backports more error prone.
> 
> Real question is : why do you want this change in the first place ?

The current code does non-zero checks for rskq_defer_accept twice in
reqsk_timer_handler() and syn_ack_recalc(), the former of which is
redundant.

Also, max_retries can have two meanings in reqsk_timer_handler() depending
on TCP_DEFER_ACCEPT:
  - the number of retries to resend SYN+ACK (unused)
  - the number of retries to drop bare ACK

On the other hand, the max_retries in reqsk_timer_handler() has only the
latter meaning and is confusing because rskq_defer_accept has the same
(original) value and the both values are used.

As far as I see, in the original code, the non-zero check was reasonable
because it was done once and the max_retries was evaluated through the
function (tcp_synack_timer()).


$ git blame net/ipv4/tcp_timer.c 1944972d3bb651474a5021c9da8d0166ae19f1eb
...
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 464) static void tcp_synack_timer(struct sock *sk)
...
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 468)    int max_retries = tp->syn_retries ? : sysctl_tcp_synack_retries;
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 469)    int thresh = max_retries;
...
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 505)    if (tp->defer_accept)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 506)            max_retries = tp->defer_accept;
...
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 515)                            if ((req->retrans < thresh ||
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 516)                                 (req->acked && req->retrans < max_retries))
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 517)                                && !req->class->rtx_syn_ack(sk, req, NULL)) {


Currently, the code already looks a bit churned and error-prone.

It might be because of the ambiguity of the name of max_retries. 

rskq_defer_accept is assigned to max_retries but not always "max".
The code checks thresh at first, and then max_retries. So, as a result of
the evaluation order, it can be "max" (also may be smaller than thresh).
Moreover, in this context, there are three kinds of "retries": timer
(num_timeout), resending SYN+ACK (thresh), and dropping bare ACK
(max_retries and rskq_defer_accept).

In the original code, it was OK because we did not use rskq_defer_accept
twice.

The commit introduces syn_ack_recalc() and delegates the decision of
retries to the function.

I think it is better to 
  - remove the redundant check of rskq_defer_accept
  - pass only necessary arguments to syn_ack_recalc()
  - use a more understandable name instead of max_retries in two functions. 

For example, max_resends and rskq_defer_accept, or max_syn_ack_retries and
rskq_defer_accept. (I am not confident about what is the most
understandable name for anyone.)

So, I would like to respin the patch rephrasing max_retries to the proper
name.

What would you think about this?

Sincerely,
Kuniyuki

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ