netdev - Re: [PATCH net-next 2/2] tcp: add TCP_RFC7323_PAWS

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANn89i+bYZuR_XL4HoL0cNtpiGax2Tuayd5kp_MbmTz1R1Ku7w@mail.gmail.com>
Date: Mon, 13 Jan 2025 14:09:37 +0100
From: Eric Dumazet <edumazet@...gle.com>
To: Jason Xing <kerneljasonxing@...il.com>
Cc: "David S . Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, 
	Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org, Simon Horman <horms@...nel.org>, 
	Neal Cardwell <ncardwell@...gle.com>, Kuniyuki Iwashima <kuniyu@...zon.com>, eric.dumazet@...il.com
Subject: Re: [PATCH net-next 2/2] tcp: add TCP_RFC7323_PAWS_ACK drop reason

On Mon, Jan 13, 2025 at 2:00 PM Jason Xing <kerneljasonxing@...il.com> wrote:
>
> On Mon, Jan 13, 2025 at 3:37 PM Eric Dumazet <edumazet@...gle.com> wrote:
> >
> > On Mon, Jan 13, 2025 at 8:22 AM Jason Xing <kerneljasonxing@...il.com> wrote:
> > >
> > > Hello Eric,
> > >
> > > On Fri, Jan 10, 2025 at 10:33 PM Eric Dumazet <edumazet@...gle.com> wrote:
> > > >
> > > > XPS can cause reorders because of the relaxed OOO
> > > > conditions for pure ACK packets.
> > > >
> > > > For hosts not using RFS, what can happpen is that ACK
> > > > packets are sent on behalf of the cpu processing NIC
> > > > interrupts, selecting TX queue A for ACK packet P1.
> > > >
> > > > Then a subsequent sendmsg() can run on another cpu.
> > > > TX queue selection uses the socket hash and can choose
> > > > another queue B for packets P2 (with payload).
> > > >
> > > > If queue A is more congested than queue B,
> > > > the ACK packet P1 could be sent on the wire after
> > > > P2.
> > > >
> > > > A linux receiver when processing P2 currently increments
>
> Maybe P1? If the receiver processes the P2 packet (as you said, with
> payload) earlier than P1 (pure ack) and it really returns with a drop
> reason, I think it should hit #1 case instead of #2 case.
>

Sure, this is a typo of course.

> IIUC, the receiver processes the P1 and finds that P1.seq < rcv.nxt
> because P2 already updates rcv.nxt earlier.
>
> > > > LINUX_MIB_PAWSESTABREJECTED (TcpExtPAWSEstab)
> > > > and use TCP_RFC7323_PAWS drop reason.
> > > > It might also send a DUPACK if not rate limited.
> > > >
> > > > In order to better understand this pattern, this
> > > > patch adds a new drop_reason : TCP_RFC7323_PAWS_ACK.
> > > >
> > > > For old ACKS like these, we no longer increment
> > > > LINUX_MIB_PAWSESTABREJECTED and no longer sends a DUPACK,
> > >
> > > I'm afraid that not all the hosts enable the XPS feature. In this way,
> > > this patch will lead the hosts that don't enable XPS not sending
> > > DUPACK any more if OOO happens.
> > >
> > > So I wonder if it would affect those non XPS cases?
> >
> > Everything is fine. The non XPS cases will be handled perfectly well.
> >
> > For the record, all TCP packetdrill tests we currently have are passing.
> >
> > Feel free to cook a packetdrill test to show exactly the issue you are
> > thinking of,
> > chances are very high you won't find a concerning problem.
>
> Thanks for your reply. I don't think it's a concerning issue either
> even if it happens. Admittedly, OOO pure ack happens really rarely
> from my experience.

Good then :)