linux-kernel - Re: [REGRESSION] Chrome and VSCode breakage with the commit b9b588f22a0c

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]

Message-ID: <445aeb83-5d84-4b4b-8d87-e7f17c97e6bf@oracle.com>
Date: Sat, 29 Mar 2025 10:57:59 -0400
From: Chuck Lever <chuck.lever@...cle.com>
To: Takashi Iwai <tiwai@...e.de>
Cc: linux-fsdevel@...r.kernel.org, stable@...r.kernel.org,
        regressions@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [REGRESSION] Chrome and VSCode breakage with the commit
 b9b588f22a0c

On 3/29/25 8:17 AM, Takashi Iwai wrote:
> On Sun, 23 Feb 2025 09:53:10 +0100,
> Takashi Iwai wrote:
>>
>> [ resent due to a wrong address for regression reporting, sorry! ]
>>
>> Hi,
>>
>> we received a bug report showing the regression on 6.13.1 kernel
>> against 6.13.0.  The symptom is that Chrome and VSCode stopped working
>> with Gnome Scaling, as reported on openSUSE Tumbleweed bug tracker
>>   https://bugzilla.suse.com/show_bug.cgi?id=1236943
>>
>> Quoting from there:
>> """
>> I use the latest TW on Gnome with a 4K display and 150%
>> scaling. Everything has been working fine, but recently both Chrome
>> and VSCode (installed from official non-openSUSE channels) stopped
>> working with Scaling.
>> ....
>> I am using VSCode with:
>> `--enable-features=UseOzonePlatform --enable-features=WaylandWindowDecorations --ozone-platform-hint=auto` and for Chrome, I select `Preferred Ozone platform` == `Wayland`.
>> """
>>
>> Surprisingly, the bisection pointed to the backport of the commit
>> b9b588f22a0c049a14885399e27625635ae6ef91 ("libfs: Use d_children list
>> to iterate simple_offset directories").
>>
>> Indeed, the revert of this patch on the latest 6.13.4 was confirmed to
>> fix the issue.  Also, the reporter verified that the latest 6.14-rc
>> release is still affected, too.
>>
>> For now I have no concrete idea how the patch could break the behavior
>> of a graphical application like the above.  Let us know if you need
>> something for debugging.  (Or at easiest, join to the bugzilla entry
>> and ask there; or open another bug report at whatever you like.)
>>
>> BTW, I'll be traveling tomorrow, so my reply will be delayed.
>>
>>
>> thanks,
>>
>> Takashi
>>
>> #regzbot introduced: b9b588f22a0c049a14885399e27625635ae6ef91
>> #regzbot monitor: https://bugzilla.suse.com/show_bug.cgi?id=1236943
> 
> After all, this seems to be a bug in Chrome and its variant, which was
> surfaced by the kernel commit above: as the commit changes the
> directory enumeration, it also changed the list order returned from
> libdrm drmGetDevices2(), and it screwed up the application that worked
> casually beforehand.  That said, the bug itself has been already
> present.  The Chrome upstream tracker:
>   https://issuetracker.google.com/issues/396434686
> 
> #regzbot invalid: problem has always existed on Chrome and related code
> 
> 
> Takashi

Thank you very much for your report and for chasing this to conclusion.


-- 
Chuck Lever