lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87wmc83uaf.wl-tiwai@suse.de>
Date: Sat, 29 Mar 2025 13:17:44 +0100
From: Takashi Iwai <tiwai@...e.de>
To: regressions@...ts.linux.dev
Cc: Chuck Lever <chuck.lever@...cle.com>,
	linux-fsdevel@...r.kernel.org,
	stable@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [REGRESSION] Chrome and VSCode breakage with the commit b9b588f22a0c

On 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ