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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAL+tcoA8SdpKo94z9MsFyMPEHgns9kzb505v6hybenot4CpCXg@mail.gmail.com>
Date: Mon, 13 Jan 2025 20:59:32 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: Eric Dumazet <edumazet@...gle.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 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.

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.

Thanks,
Jason