netdev - Re: [PATCH net 2/4] tcp: tcp_fragment() should apply sane memory limits

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]

Date:   Mon, 17 Jun 2019 20:53:58 -0700
From:   Christoph Paasch <christoph.paasch@...il.com>
To:     Eric Dumazet <eric.dumazet@...il.com>
Cc:     Eric Dumazet <edumazet@...gle.com>,
        "David S . Miller" <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jonathan Looney <jtl@...flix.com>,
        Neal Cardwell <ncardwell@...gle.com>,
        Tyler Hicks <tyhicks@...onical.com>,
        Yuchung Cheng <ycheng@...gle.com>,
        Bruce Curtis <brucec@...flix.com>,
        Jonathan Lemon <jonathan.lemon@...il.com>,
        Dustin Marquess <dmarquess@...le.com>
Subject: Re: [PATCH net 2/4] tcp: tcp_fragment() should apply sane memory limits

On Mon, Jun 17, 2019 at 8:44 PM Eric Dumazet <eric.dumazet@...il.com> wrote:
>
>
>
> On 6/17/19 8:19 PM, Christoph Paasch wrote:
> >
> > Yes, this does the trick for my packetdrill-test.
> >
> > I wonder, is there a way we could end up in a situation where we can't
> > retransmit anymore?
> > For example, sk_wmem_queued has grown so much that the new test fails.
> > Then, if we legitimately need to fragment in __tcp_retransmit_skb() we
> > won't be able to do so. So we will never retransmit. And if no ACK
> > comes back in to make some room we are stuck, no?
>
> Well, RTO will eventually fire.

But even the RTO would have to go through __tcp_retransmit_skb(), and
let's say the MTU of the interface changed and thus we need to
fragment. tcp_fragment() would keep on failing then, no? Sure,
eventually we will ETIMEOUT but that's a long way to go.

> Really TCP can not work well with tiny sndbuf limits.
>
> There is really no point trying to be nice.

Sure, fair enough :-)


Christoph

>
> There is precedent in TCP stack where we always allow one packet in RX or TX queue
> even with tiny rcv/sndbuf limits (or global memory pressure)
>
> We only need to make sure to allow having at least one packet in rtx queue as well.