From: Brian Foster <bfoster@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Carlos Maiolino <cem@kernel.org>,
Dave Chinner <dchinner@redhat.com>,
linux-xfs@vger.kernel.org
Subject: Re: buffer cache simplification v4
Date: Tue, 17 Mar 2026 09:36:33 -0400 [thread overview]
Message-ID: <ablY4bjxZs54FWeS@bfoster> (raw)
In-Reply-To: <20260317125604.GA29925@lst.de>
On Tue, Mar 17, 2026 at 01:56:04PM +0100, Christoph Hellwig wrote:
> On Tue, Mar 17, 2026 at 08:13:04AM -0400, Brian Foster wrote:
> > On Mon, Mar 16, 2026 at 04:41:32PM +0100, Christoph Hellwig wrote:
> > > Hi all,
> > >
> > > this series has a few old patches that simplify the LRU handling, and
> > > moves back to only having a per-buftarg hash now that the buffer hash
> > > is using the scalable rhashtable. While some of this looks like
> > > performance work, performance and scalability is unchanged even on the
> > > 80 core dual socket system I test this on. Besides cleaning up the
> > > code nice, it also happens to fix a syzcaller reported use after free
> > > during buffer shutdown, which happened incidentally because of how the
> > > tear down of the buftarg vs the perag structures is handled.
> > >
> > > Changes since v3:
> > > - split the change to handling how referenced buffers on the LRU
> > > are handled into a separate patch
> > >
> >
> > It looks like there's a patch ordering problem or something here. It
> > doesn't apply to master, and looks like patch 1 is trying to modify
> > hunks that don't yet exist. A local rebase issue related to reordering
> > the change in patch 3 perhaps..?
>
> This is against the xfs for-next tree (commit
> f8544b654f22b1138ba12bc0971a96963b20311d)
>
Still doesn't apply.. I.e., here's a hunk from patch 1:
@@ -154,7 +155,7 @@ struct xfs_buf {
xfs_daddr_t b_rhash_key; /* buffer cache index */
int b_length; /* size of buffer in BBs */
- int b_hold; /* reference count */
+ struct lockref b_lockref; /* refcount + lock */
atomic_t b_lru_ref; /* lru reclaim ref count */
xfs_buf_flags_t b_flags; /* status flags */
struct semaphore b_sema; /* semaphore for lockables */
Where is b_hold an int? AFAICT that was part of the first patch in the
previous version, which isn't included here.
Brian
next prev parent reply other threads:[~2026-03-17 13:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-16 15:41 buffer cache simplification v4 Christoph Hellwig
2026-03-16 15:41 ` [PATCH 1/3] xfs: use a lockref for the buffer reference count Christoph Hellwig
2026-03-16 15:41 ` [PATCH 2/3] xfs: switch (back) to a per-buftarg buffer hash Christoph Hellwig
2026-03-16 22:30 ` Darrick J. Wong
2026-03-16 15:41 ` [PATCH 3/3] xfs: don't decrement the buffer LRU count for in-use buffers Christoph Hellwig
2026-03-16 22:20 ` Darrick J. Wong
2026-03-17 12:13 ` buffer cache simplification v4 Brian Foster
2026-03-17 12:56 ` Christoph Hellwig
2026-03-17 13:36 ` Brian Foster [this message]
2026-03-17 13:39 ` Christoph Hellwig
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=ablY4bjxZs54FWeS@bfoster \
--to=bfoster@redhat.com \
--cc=cem@kernel.org \
--cc=dchinner@redhat.com \
--cc=hch@lst.de \
--cc=linux-xfs@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.