netdev - Re: [PATCH net-next v3 3/6] tcp: add dropreasons in tcp_rcv_state

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: <CANn89iJwx9b2dUGUKFSV3PF=kN5o+kxz3A_fHZZsOS4AnXhBNw@mail.gmail.com>
Date: Tue, 13 Feb 2024 13:03:46 +0100
From: Eric Dumazet <edumazet@...gle.com>
To: Jason Xing <kerneljasonxing@...il.com>
Cc: davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com, 
	dsahern@...nel.org, netdev@...r.kernel.org, 
	Jason Xing <kernelxing@...cent.com>, Kuniyuki Iwashima <kuniyu@...zon.com>
Subject: Re: [PATCH net-next v3 3/6] tcp: add dropreasons in tcp_rcv_state_process()

On Tue, Feb 13, 2024 at 11:30 AM Jason Xing <kerneljasonxing@...il.com> wrote:
>
> On Tue, Feb 13, 2024 at 5:35 PM Eric Dumazet <edumazet@...gle.com> wrote:
> >
> > >
> > > Hi Eric, Kuniyuki
> > >
> > > Sorry, I should have checked tcp_conn_request() carefully last night.
> > > Today, I checked tcp_conn_request() over and over again.
> > >
> > > I didn't find there is any chance to return a negative/positive value,
> > > only 0. It means @acceptable is always true and it should never return
> > > TCP_CONNREQNOTACCEPTABLE for TCP ipv4/6 protocol and never trigger a
> > > reset in this way.
> > >
> >
> > Then send a cleanup, thanks.
> >
> > A standalone patch is going to be simpler than reviewing a whole series.
>
> I fear that I could misunderstand what you mean. I'm not that familiar
> with how it works. Please enlighten me, thanks.
>
> Are you saying I don't need to send a new version of the current patch
> series, only send a patch after this series is applied?
>

No. I suggested the clean up being sent before the series.

If acceptable is always true in TCP, why keep dead code ?

This would avoid many questions.

diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 2d20edf652e6cb5eb56bda0107c99bed0b0a335f..b1c4462a0798c45e9b10d62715bc88fa35349078
100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -6623,7 +6623,6 @@ int tcp_rcv_state_process(struct sock *sk,
struct sk_buff *skb)
        const struct tcphdr *th = tcp_hdr(skb);
        struct request_sock *req;
        int queued = 0;
-       bool acceptable;
        SKB_DR(reason);

        switch (sk->sk_state) {
@@ -6649,12 +6648,10 @@ int tcp_rcv_state_process(struct sock *sk,
struct sk_buff *skb)
                         */
                        rcu_read_lock();
                        local_bh_disable();
-                       acceptable =
icsk->icsk_af_ops->conn_request(sk, skb) >= 0;
+                       icsk->icsk_af_ops->conn_request(sk, skb);
                        local_bh_enable();
                        rcu_read_unlock();

-                       if (!acceptable)
-                               return 1;
                        consume_skb(skb);
                        return 0;
                }