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: <CAL+tcoBdvbA7OFYgdjN=LdLiQ=CyBxCkRy-0S_cPRPhxRHgenA@mail.gmail.com>
Date: Tue, 13 Feb 2024 20:38:27 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: Eric Dumazet <edumazet@...gle.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 8:04 PM Eric Dumazet <edumazet@...gle.com> wrote:
>
> 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;
>                 }

Thanks for your explanation. Since the DCCP seems dead, there is no
need to keep it for TCP as you said. I will send this patch first,
then two updated patch series following.

Thanks,
Jason