[REGRESSION] Chrome and VSCode breakage with the commit b9b588f22a0c

[REGRESSION] Chrome and VSCode breakage with the commit b9b588f22a0c

[Takashi Iwai]

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

[REGRESSION] Chrome and VSCode breakage with the commit b9b588f22a0c

[Takashi Iwai]

[ 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

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

[Chuck Lever]

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.


-- 
Chuck Lever

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

[Takashi Iwai]

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?  The reported stuff are no distro
packages, and I myself have no experience with them, hence have no
idea about the upstream development.
If you have more clue about Chrome development, it'd be appreciated if
you can report / ask from your side.  Of course, feel free to put me
to Cc.


thanks,

Takashi

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

[Chuck Lever]

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


> The reported stuff are no distro
> packages, and I myself have no experience with them, hence have no
> idea about the upstream development.
> If you have more clue about Chrome development, it'd be appreciated if
> you can report / ask from your side.  Of course, feel free to put me
> to Cc.


-- 
Chuck Lever

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

[Takashi Iwai]

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.


Takashi

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

[Chuck Lever]

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.


-- 
Chuck Lever

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

[Greg KH]

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}

Takashi, thanks for the report and the bisection, much appreciated.

greg k-h

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

[Greg KH]

On Wed, Feb 26, 2025 at 03:26:44PM +0100, 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}
> 
> Takashi, thanks for the report and the bisection, much appreciated.

Now sent:
	https://lore.kernel.org/r/2025022644-blinked-broadness-c810@gregkh

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

[Takashi Iwai]

On Wed, 26 Feb 2025 15:20:20 +0100,
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.

Yeah, I'm going to ask the original reporter, but this is still not
perfect at all; namely, you'll be missed in the loop.  e.g. who can
answer to the questions from Chrome team about the breakage commit?
That's why I asked you posting it previously.  If it has to be done by
the original reporter, at least, may your name / mail be put as the
contact for the kernel stuff in the report?


thanks,

Takashi

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

[Takashi Iwai]

On Wed, 26 Feb 2025 15:35:34 +0100,
Greg KH wrote:
> 
> On Wed, Feb 26, 2025 at 03:26:44PM +0100, 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}
> > 
> > Takashi, thanks for the report and the bisection, much appreciated.
> 
> Now sent:
> 	https://lore.kernel.org/r/2025022644-blinked-broadness-c810@gregkh

Thanks Greg!

Let's continue hunting the cause before 6.14 release, meanwhile.


Takashi

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

[Greg KH]

On Wed, Feb 26, 2025 at 03:40:07PM +0100, Takashi Iwai wrote:
> On Wed, 26 Feb 2025 15:35:34 +0100,
> Greg KH wrote:
> > 
> > On Wed, Feb 26, 2025 at 03:26:44PM +0100, 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}
> > > 
> > > Takashi, thanks for the report and the bisection, much appreciated.
> > 
> > Now sent:
> > 	https://lore.kernel.org/r/2025022644-blinked-broadness-c810@gregkh
> 
> Thanks Greg!
> 
> Let's continue hunting the cause before 6.14 release, meanwhile.

I'd prefer that the revert land in Linus's tree first and I can take the
revert from there for the stable releases, otherwise it's going to be a
mess once 6.14-final is released :(

thanks,

greg k-h

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

[Takashi Iwai]

On Wed, 26 Feb 2025 16:02:04 +0100,
Greg KH wrote:
> 
> On Wed, Feb 26, 2025 at 03:40:07PM +0100, Takashi Iwai wrote:
> > On Wed, 26 Feb 2025 15:35:34 +0100,
> > Greg KH wrote:
> > > 
> > > On Wed, Feb 26, 2025 at 03:26:44PM +0100, 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}
> > > > 
> > > > Takashi, thanks for the report and the bisection, much appreciated.
> > > 
> > > Now sent:
> > > 	https://lore.kernel.org/r/2025022644-blinked-broadness-c810@gregkh
> > 
> > Thanks Greg!
> > 
> > Let's continue hunting the cause before 6.14 release, meanwhile.
> 
> I'd prefer that the revert land in Linus's tree first and I can take the
> revert from there for the stable releases, otherwise it's going to be a
> mess once 6.14-final is released :(

Ah, I thought your patch were for stable-only, but it was for
mainline.  Let's see how it goes.


thanks,

Takashi

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

[Chuck Lever]

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.


-- 
Chuck Lever

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

[Chuck Lever]

On 2/26/25 9:35 AM, Takashi Iwai wrote:
> On Wed, 26 Feb 2025 15:20:20 +0100,
> 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.
> 
> Yeah, I'm going to ask the original reporter, but this is still not
> perfect at all; namely, you'll be missed in the loop.  e.g. who can
> answer to the questions from Chrome team about the breakage commit?
> That's why I asked you posting it previously.  If it has to be done by
> the original reporter, at least, may your name / mail be put as the
> contact for the kernel stuff in the report?

Certainly! Perhaps add Cc: linux-fsdevel@ as well.


-- 
Chuck Lever

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

[Takashi Iwai]

On Wed, 26 Feb 2025 17:00:43 +0100,
Chuck Lever wrote:
> 
> On 2/26/25 9:35 AM, Takashi Iwai wrote:
> > On Wed, 26 Feb 2025 15:20:20 +0100,
> > 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.
> > 
> > Yeah, I'm going to ask the original reporter, but this is still not
> > perfect at all; namely, you'll be missed in the loop.  e.g. who can
> > answer to the questions from Chrome team about the breakage commit?
> > That's why I asked you posting it previously.  If it has to be done by
> > the original reporter, at least, may your name / mail be put as the
> > contact for the kernel stuff in the report?
> 
> Certainly! Perhaps add Cc: linux-fsdevel@ as well.

OK, thanks, now asked on the bugzilla.


Takashi

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

[Greg KH]

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 :)

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

[Greg KH]

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

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

[Eric Biggers]

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

- Eric

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

[Chuck Lever]

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.


-- 
Chuck Lever

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

[Eric Biggers]

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

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

[Chuck Lever]

On 2/26/25 4:40 PM, Eric Biggers wrote:
> 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?

Yes, the order of entry iteration changed, but I thought it was going
back to the way tmpfs iterated directories before v6.6.

Also my impression is POSIX allows filesystems some leeway in that
order, and thus apps cannot depend on it. Makes me suspect there's some
other issue, like offset_readdir() is skipping an entry somehow.


> The theory at https://issuetracker.google.com/issues/396434686#comment4 seems
> promising.  Just the exact code hasn't been identified yet.

Yes.


-- 
Chuck Lever

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

[Takashi Iwai]

On Sun, 23 Feb 2025 09:53:10 +0100,
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

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


Takashi

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

[Chuck Lever]

On 3/29/25 8:17 AM, Takashi Iwai wrote:
> On Sun, 23 Feb 2025 09:53:10 +0100,
> 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
> 
> 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
> 
> 
> Takashi

Thank you very much for your report and for chasing this to conclusion.


-- 
Chuck Lever

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

[Paul Menzel]

Dear Chuck, dear Takashi, dear Christian,


I just came across this issue.

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


Kind regards,

Paul

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

[Greg KH]

On Sat, Apr 05, 2025 at 08:32:13AM +0200, Paul Menzel wrote:
> Dear Chuck, dear Takashi, dear Christian,
> 
> 
> I just came across this issue.
> 
> 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.

thanks,

greg k-h

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

[Paul Menzel]

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@vger.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?


Kind regards,

Paul


[1]: https://docs.kernel.org/process/stable-kernel-rules.html

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

[Greg KH]

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

thanks,

greg k-h

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

[Chuck Lever]

On 4/5/25 3:43 AM, 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@vger.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?
I NACK'd the upstream revert because I expected an RCA before 6.14
final (that didn't happen), and the Chrome issue was the only reported
problem and it was specific to a particular hardware configuration and
the /latest developer release/ of Chrome. Neither v6.14.0 nor a Chrome
developer release are going to be put in front of users who do not
expect to encounter issues.

Note that the libfs series addresses several issues. Commit b9b588f22a0c
itself addresses CVE-2024-46701 [1] (in v6.6). I did not add a "Cc:
stable" for commit b9b588f22a0c because it cannot be cherry picked to
apply to v6.6, it has to be manually adjusted to apply.

The final RCA reported in [2] shows that there is nothing incorrect
about b9b588f22a0c.

In addition, the next Chrome release will carry a fix for the clearly
incorrect library behavior -- applications cannot depend on the order
of directory entry iteration, because that can change arbitrarily, and
not just because of file system implementation quirks. You will note
that even after sorting the directory entries, the library still had
problems discovering the accelerated graphics device.

Reverting now might follow the letter of the rule about "no regressions"
but IMHO moving forward from here seems to me to be the more
constructive approach.


-- 
Chuck Lever

[1] https://nvd.nist.gov/vuln/detail/CVE-2024-46701
[2] https://issuetracker.google.com/issues/396434686?pli=1

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

[Christian Brauner]

On Sat, Apr 05, 2025 at 12:25:00PM -0400, Chuck Lever wrote:
> On 4/5/25 3:43 AM, 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@vger.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?
> I NACK'd the upstream revert because I expected an RCA before 6.14
> final (that didn't happen), and the Chrome issue was the only reported
> problem and it was specific to a particular hardware configuration and
> the /latest developer release/ of Chrome. Neither v6.14.0 nor a Chrome
> developer release are going to be put in front of users who do not
> expect to encounter issues.

Exactly.

> 
> Note that the libfs series addresses several issues. Commit b9b588f22a0c
> itself addresses CVE-2024-46701 [1] (in v6.6). I did not add a "Cc:
> stable" for commit b9b588f22a0c because it cannot be cherry picked to
> apply to v6.6, it has to be manually adjusted to apply.
> 
> The final RCA reported in [2] shows that there is nothing incorrect
> about b9b588f22a0c.
> 
> In addition, the next Chrome release will carry a fix for the clearly
> incorrect library behavior -- applications cannot depend on the order
> of directory entry iteration, because that can change arbitrarily, and
> not just because of file system implementation quirks. You will note
> that even after sorting the directory entries, the library still had
> problems discovering the accelerated graphics device.
> 
> Reverting now might follow the letter of the rule about "no regressions"
> but IMHO moving forward from here seems to me to be the more
> constructive approach.

I agree.

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

[Chuck Lever]

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