[ 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
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.
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
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%3...
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.
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
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.
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
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
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
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
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
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.
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 :)
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
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
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.
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
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%3...
FYI this was already reported on the Chrome issue tracker 2 weeks ago: https://issuetracker.google.com/issues/396434686
- Eric
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%3...
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.
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%3...
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
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%3...
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.
linux-stable-mirror@lists.linaro.org
-
Chuck Lever -
Eric Biggers -
Greg KH -
Takashi Iwai