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

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

On Fri, Jun 21, 2019 at 4:07 PM Pierre-Loup A. Griffais
<pgriffais@...vesoftware.com> wrote:
>
>
>
> 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
> >
>
I asked on the github thread if users seeing the problem could check
the new wqueue too big counter:
https://github.com/ValveSoftware/steam-for-linux/issues/6326

So far one person is seeing the counter increase when they see the
problem, and another that doesn't see the problem has the counter at
0. Obviously not a great sample size, but hopefully more will report.
If nothing else, someone is seeing the counter increase while trying
to connect to steam.
-- 
Josh