Re: [REGRESSION] Chrome and VSCode breakage with the commit b9b588f22a0c

[Eric Biggers <ebiggers@kernel.org>]

On Wed, Feb 26, 2025 at 04:01:18PM -0500, Chuck Lever wrote:
> On 2/26/25 3:42 PM, Eric Biggers wrote:
> > On Wed, Feb 26, 2025 at 09:11:04AM -0500, 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. You can report the issue here:
> >>
> >> https://support.google.com/chrome/answer/95315?hl=en&co=GENIE.Platform%3DDesktop
> >>
> >>
> > 
> > FYI this was already reported on the Chrome issue tracker 2 weeks ago:
> > https://issuetracker.google.com/issues/396434686
> 
> That appears to be as a response to the first report to us. Thanks for
> finding this.
> 
> I notice that this report indicates the problem is with a developer
> build of Chrome, not a GA build.
> 
> If /dev/dri is a tmpfs file system, then it would indeed be affected by
> b9b588f22a0c. No indication yet of how.

Just to confirm, the commit did change the directory iteration order, right?
The theory at https://issuetracker.google.com/issues/396434686#comment4 seems
promising.  Just the exact code hasn't been identified yet.

- Eric