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

Message-ID: <417f41b3-b343-46ca-9efe-fa815e85bdd3@molgen.mpg.de>
Date: Sat, 5 Apr 2025 09:43:29 +0200
From: Paul Menzel <pmenzel@...gen.mpg.de>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Chuck Lever <chuck.lever@...cle.com>, Takashi Iwai <tiwai@...e.de>,
 linux-fsdevel@...r.kernel.org, stable@...r.kernel.org,
 regressions@...ts.linux.dev, linux-kernel@...r.kernel.org,
 Christian Brauner <brauner@...nel.org>
Subject: Re: [REGRESSION] Chrome and VSCode breakage with the commit
 b9b588f22a0c

Dear Greg,


Thank you for replying on a Saturday.

Am 05.04.25 um 09:29 schrieb Greg KH:
> On Sat, Apr 05, 2025 at 08:32:13AM +0200, Paul Menzel wrote:

>> Am 29.03.25 um 15:57 schrieb Chuck Lever:
>>> On 3/29/25 8:17 AM, Takashi Iwai wrote:
>>>> On Sun, 23 Feb 2025 09:53:10 +0100, Takashi Iwai wrote:
>>
>>>>> 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.
>>
>>>>> #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
>>
>>> Thank you very much for your report and for chasing this to conclusion.
>> Doesn’t marking this an invalid contradict Linux’ no regression policy to
>> never break user space, so users can always update the Linux kernel?
>> Shouldn’t this commit still be reverted, and another way be found keeping
>> the old ordering?
>>
>> Greg, Sasha, in stable/linux-6.13.y the two commits below would need to be
>> reverted:
>>
>> 180c7e44a18bbd7db89dfd7e7b58d920c44db0ca
>> d9da7a68a24518e93686d7ae48937187a80944ea
>>
>> For stable/linux-6.12.y:
>>
>> 176d0333aae43bd0b6d116b1ff4b91e9a15f88ef
>> 639b40424d17d9eb1d826d047ab871fe37897e76
> 
> Unless the changes are also reverted in Linus's tree, we'll be keeping
> these in.  Please work with the maintainers to resolve this in mainline
> and we will be glad to mirror that in the stable trees as well.

Commit b9b588f22a0c (libfs: Use d_children list to iterate simple_offset 
directories) does not have a Fixes: tag or Cc: stable@...r.kernel.org. I 
do not understand, why it was applied to the stable series at all [1], 
and cannot be reverted when it breaks userspace?


Kind regards,

Paul


[1]: https://docs.kernel.org/process/stable-kernel-rules.html