linux-kernel - Re: Steam is broken on new kernels

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-next>] [day] [month] [year] [list]

Date:   Fri, 21 Jun 2019 16:04:57 -0700
From:   "Pierre-Loup A. Griffais" <pgriffais@...vesoftware.com>
To:     Eric Dumazet <edumazet@...gle.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>
CC:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: Steam is broken on new kernels



On 6/21/19 3:38 PM, Eric Dumazet wrote:
> Please look at my recent patch.
>   Sorry I am travelling....
> 
> On Fri, Jun 21, 2019, 6:19 PM Linus Torvalds 
> <torvalds@...ux-foundation.org <mailto:torvalds@...ux-foundation.org>> 
> wrote:
> 
>     On Fri, Jun 21, 2019 at 2:41 PM Greg Kroah-Hartman
>     <gregkh@...uxfoundation.org <mailto:gregkh@...uxfoundation.org>> wrote:
>      >
>      > What specific commit caused the breakage?
> 
>     Both on reddit and on github there seems to be confusion about whether
>     it's a problem or not. Some people have it working with the exact same
>     kernel that breaks for others.
> 
>     And then some people seem to say it works intermittently for them,
>     which seems to indicate a timing issue.
> 
>     Looking at the SACK patches (assuming it's one of them), I'd suspect
>     the "tcp: tcp_fragment() should apply sane memory limits".
> 
>     Eric, that one does
> 
>             if (unlikely((sk->sk_wmem_queued >> 1) > sk->sk_sndbuf)) {
>                     NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPWQUEUETOOBIG);
>                     return -ENOMEM;
>             }
> 
>     but I think it's *normal* for "sk_wmem_queued >> 1" to be around the
>     same size as sk_sndbuf. So if there is some fragmentation, and we add
>     more skb's to it, that would seem to trigger fairly easily.
>     Particularly since this is all in "truesize" units, which can be a lot
>     bigger than the packets themselves.
> 
>     I don't know the code, so I may be out to lunch and barking up
>     completely the wrong tree, but that particular check does seem like it
>     might trigger much more easily than I think the code _intended_ it to
>     trigger?
> 
>     Pierre-Loup - do you guys have a test-case inside of valve? Or is this
>     purely "we see some people with problems"?

Definitely the latter, although the volume of complaints clearly points 
to a real problem from our experience. Reproducing locally, bisecting 
and testing possible fixes is just now starting on our end.

I agree not all users seem affected; most affected people report success 
by using -tcp to launch Steam, which makes it use direct TCP instead of 
WebSockets, our current default connection method for Linux.

Thanks,
  - Pierre-Loup

> 
>                     Linus
>