linux-kernel - 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>] [day] [month] [year] [list]

Message-ID: <CABXGCsMnkng1vqZ_8ODeFrynL1sskce1SWGskHtrHLmGo5qfDA@mail.gmail.com>
Date: Thu, 13 Feb 2025 07:16:34 +0500
From: Mikhail Gavrilov <mikhail.v.gavrilov@...il.com>
To: chuck.lever@...cle.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: 6.14/regression/bisected - commit b9b588f22a0c somehow broke HW
 acceleration in the Google Chrome

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.

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?

-- 
Best Regards,
Mike Gavrilov.

Download attachment ".config.zip" of type "application/zip" (67874 bytes)

Download attachment "about-gpu-2025-02-12T09-25-55-112Z.zip" of type "application/zip" (14923 bytes)