On Wed, Feb 26, 2025 at 10:56:46AM -0500, Chuck Lever wrote: > On 2/26/25 9:26 AM, Greg KH wrote: > > On Wed, Feb 26, 2025 at 09:20:20AM -0500, Chuck Lever wrote: > >> On 2/26/25 9:16 AM, Takashi Iwai wrote: > >>> On Wed, 26 Feb 2025 15:11:04 +0100, > >>> Chuck Lever wrote: > >>>> > >>>> On 2/26/25 3:38 AM, Takashi Iwai wrote: > >>>>> On Sun, 23 Feb 2025 16:18:41 +0100, > >>>>> Chuck Lever wrote: > >>>>>> > >>>>>> On 2/23/25 3:53 AM, 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 > >>>>>> > >>>>>> We received a similar report a few days ago, and are likewise puzzled at > >>>>>> the commit result. Please report this issue to the Chrome development > >>>>>> team and have them come up with a simple reproducer that I can try in my > >>>>>> own lab. I'm sure they can quickly get to the bottom of the application > >>>>>> stack to identify the misbehaving interaction between OS and app. > >>>>> > >>>>> Do you know where to report to? > >>>> > >>>> You'll need to drive this, since you currently have a working > >>>> reproducer. > >>> > >>> No, I don't have, I'm merely a messenger. > >> > >> Whoever was the original reporter has the ability to reproduce this and > >> answer any questions the Chrome team might have. Please have them drive > >> this. I'm already two steps removed, so it doesn't make sense for me to > >> report a problem for which I have no standing. > > > > Ugh, no. The bug was explictly bisected to the offending commit. We > > should just revert that commit for now and it can come back in the > > future if the root-cause is found. > > > > As the revert seems to be simple, and builds here for me, I guess I'll > > have to send it in. {sigh} > > Note that reverting also reintroduces a CVE. That's fine, regressions are more important :)
