Hello,
On Mon, Aug 09, 2021 at 01:17:27PM +0200, Alexander Bluhm wrote:
> On Fri, Aug 06, 2021 at 05:22:18PM +0200, Alexandr Nedvedicky wrote:
> > > Although I did not obverve it, there seems to be the same problem
> > > for snd_wl1 and rcv_up. For rcv_up I copied the comparison with
> > > rcv_nxt from urgent processing to keep future urgent data.
>
> Over the weekend I thought about the SEQ_GT(tp->rcv_nxt, tp->rcv_up)
> check. I think FreeBSD is right and we don't need it.
>
> In the regular case we may receive a retransmit of an old packet.
> This check preserves the rcv_up from packets that we received earlier
> but with higher sequence number. But in the header prediction code
> we know that TAILQ_EMPTY(&tp->t_segq). So the current packet is
> the most recent one and we can blindly take its rcv_nxt as urgent
> pointer.
>
> So maybe we want take the simplified diff below.
I agree here.
>
> > can you also share some details about testing you have done?
> > (tool + command line options)
>
> That is quite tricky. I do not have a simple test case for that.
> One of our OpenBSD based product guarantees unidirectional traffic.
> We habe a userland process that receives the data, sends it to
> another OpenBSD machine. There it goes to socket splicing and
> finaly it ends in a Linux FTP server.
>
> some magic -> user land sending process --> socket splicing --> Linux FTP
>
> I suspect that with all the machines and processes involved, we
> have strange timing and run into the race.
>
looks like one has to be (un)lucky enough to trigger the
session stale. I think it's worth to get it in.
OK sashan
