[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2025022600-nutlike-vagabond-ef64@gregkh>
Date: Wed, 26 Feb 2025 08:19:52 -0800
From: Greg KH <gregkh@...uxfoundation.org>
To: Chuck Lever <chuck.lever@...cle.com>
Cc: Takashi Iwai <tiwai@...e.de>, regressions@...ts.linux.dev,
linux-fsdevel@...r.kernel.org, stable@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [REGRESSION] Chrome and VSCode breakage with the commit
b9b588f22a0c
On Wed, Feb 26, 2025 at 08:18:37AM -0800, Greg KH wrote:
> 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 :)
And, to be explicit, when a CVE-assigned-commit is reverted, the CVE is
semi-automatically revoked (I have to remember to run the script to
check for it.) So this is fine, the CVE will just "go away" from all
systems that attempt to account for them, and then will come back when
the real fix happens.
thanks,
greg k-h
Powered by blists - more mailing lists