linux-kernel - Re: 6.14/regression/bisected - commit b9b588f22a0c somehow broke HW acceleration in the Google Chrome

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: <9f3ad2da-3a85-4b1e-94b5-968a34ee7a7a@oracle.com>
Date: Thu, 13 Feb 2025 09:17:57 -0500
From: Chuck Lever <chuck.lever@...cle.com>
To: Mikhail Gavrilov <mikhail.v.gavrilov@...il.com>, brauner@...nel.org,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        Linux regressions mailing list <regressions@...ts.linux.dev>,
        linux-fsdevel@...r.kernel.org
Subject: Re: 6.14/regression/bisected - commit b9b588f22a0c somehow broke HW
 acceleration in the Google Chrome

On 2/12/25 9:16 PM, Mikhail Gavrilov wrote:
> Hi,
> I spotted that Google Chrome started working without HW acceleration.
> And git bisect found commit b9b588f22a0c049a14885399e27625635ae6ef91
> Author: Chuck Lever <chuck.lever@...cle.com>
> Date:   Sat Dec 28 12:55:21 2024 -0500
> 
>     libfs: Use d_children list to iterate simple_offset directories
> 
>     The mtree mechanism has been effective at creating directory offsets
>     that are stable over multiple opendir instances. However, it has not
>     been able to handle the subtleties of renames that are concurrent
>     with readdir.
> 
>     Instead of using the mtree to emit entries in the order of their
>     offset values, use it only to map incoming ctx->pos to a starting
>     entry. Then use the directory's d_children list, which is already
>     maintained properly by the dcache, to find the next child to emit.
> 
>     One of the sneaky things about this is that when the mtree-allocated
>     offset value wraps (which is very rare), looking up ctx->pos++ is
>     not going to find the next entry; it will return NULL. Instead, by
>     following the d_children list, the offset values can appear in any
>     order but all of the entries in the directory will be visited
>     eventually.
> 
>     Note also that the readdir() is guaranteed to reach the tail of this
>     list. Entries are added only at the head of d_children, and readdir
>     walks from its current position in that list towards its tail.
> 
>     Signed-off-by: Chuck Lever <chuck.lever@...cle.com>
>     Link: https://lore.kernel.org/r/20241228175522.1854234-6-cel@kernel.org
>     Signed-off-by: Christian Brauner <brauner@...nel.org>
> 
>  fs/libfs.c | 84
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------------------------
>  1 file changed, 58 insertions(+), 26 deletions(-)
> 
> I tested Google Chrome after reverting commit b9b588f22a0c and ensured
> that this fixed the issue.

I need a simpler reproducer, please. "Chrome stopped working" doesn't
give me anything actionable.


> Machine spec: https://linux-hardware.org/?probe=5810cda90d
> I attached below my build config.
> 
> Chuck, you, as the author problem commit, can look into this, please?


-- 
Chuck Lever