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@xxxxxxxxxxxxxxx. 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
