Message-ID: <ef223eea-7796-4a0e-a401-68acf2b549ad@oracle.com>
Date: Mon, 7 Apr 2025 10:10:38 -0400
From: Chuck Lever <chuck.lever@...cle.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: 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>,
        Paul Menzel <pmenzel@...gen.mpg.de>
Subject: Re: [REGRESSION] Chrome and VSCode breakage with the commit
 b9b588f22a0c

On 4/5/25 4:19 AM, Greg KH wrote:
> On Sat, Apr 05, 2025 at 09:43:29AM +0200, Paul Menzel wrote:
>> 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?
> 
> The maintainers asked for it to be applied as it fixed reported
> problems, please see the mailing list archives for details.
> 
> Note, I have submitted a revert for this already, see:
> 	https://lore.kernel.org/r/2025022644-blinked-broadness-c810@gregkh
> as I too think this should be fixed as it caused problems, but the
> maintainers involved decided otherwise, please see that thread for
> details.

Greg, thank you for your patience on this issue.

My aim was to address the CVE specifically in v6.6, and I think I didn't
understand that the stable process requires that the upstream patch
needed to be applied to later LTS kernels as well.

Thus I labeled commit b9b588f22a0c inappropriately. It should have had a
Fixes: tag and "Cc: stable", even though LTS v6.12 and v6.13 were not my
immediate priority.

I will try to be better next time.


-- 
Chuck Lever

Powered by blists - more mailing lists