linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
To: chuck.lever@oracle.com, brauner@kernel.org,
	 Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
	 Linux regressions mailing list <regressions@lists.linux.dev>,
	linux-fsdevel@vger.kernel.org
Subject: 6.14/regression/bisected - commit b9b588f22a0c somehow broke HW acceleration in the Google Chrome
Date: Thu, 13 Feb 2025 07:16:34 +0500	[thread overview]
Message-ID: <CABXGCsMnkng1vqZ_8ODeFrynL1sskce1SWGskHtrHLmGo5qfDA@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2036 bytes --]

Hi,
I spotted that Google Chrome started working without HW acceleration.
And git bisect found commit b9b588f22a0c049a14885399e27625635ae6ef91
Author: Chuck Lever <chuck.lever@oracle.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@oracle.com>
    Link: https://lore.kernel.org/r/20241228175522.1854234-6-cel@kernel.org
    Signed-off-by: Christian Brauner <brauner@kernel.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.

[-- Attachment #2: .config.zip --]
[-- Type: application/zip, Size: 67874 bytes --]

[-- Attachment #3: about-gpu-2025-02-12T09-25-55-112Z.zip --]
[-- Type: application/zip, Size: 14923 bytes --]

             reply	other threads:[~2025-02-13  2:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-13  2:16 Mikhail Gavrilov [this message]
2025-02-13 14:17 ` 6.14/regression/bisected - commit b9b588f22a0c somehow broke HW acceleration in the Google Chrome Chuck Lever
2025-02-13 15:27   ` Mikhail Gavrilov
2025-02-13 15:39     ` Chuck Lever

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CABXGCsMnkng1vqZ_8ODeFrynL1sskce1SWGskHtrHLmGo5qfDA@mail.gmail.com \
    --to=mikhail.v.gavrilov@gmail.com \
    --cc=brauner@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=regressions@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).