All of lore.kernel.org
 help / color / mirror / Atom feed
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 08:13:04 -0400	[thread overview]
Message-ID: <ablFUL_cBSJBJHgp@bfoster> (raw)
In-Reply-To: <20260316154216.1598410-1-hch@lst.de>

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..?

Brian

> Changes since v2:
>  - mark b_hold as signed in patch 1 before removing it in patch 2
>  - document the changed locking in xfs_buf_rele_cached.
> 
> Changes since v2:
>  - add more details and a link to a commit message
> 
> Diffstat:
>  libxfs/xfs_ag.c |   13 ----
>  libxfs/xfs_ag.h |    2 
>  xfs_buf.c       |  148 ++++++++++++++++++++------------------------------------
>  xfs_buf.h       |   14 +----
>  xfs_buf_mem.c   |   11 ----
>  xfs_trace.h     |   10 +--
>  6 files changed, 66 insertions(+), 132 deletions(-)
> 


  parent reply	other threads:[~2026-03-17 12:13 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 ` Brian Foster [this message]
2026-03-17 12:56   ` buffer cache simplification v4 Christoph Hellwig
2026-03-17 13:36     ` Brian Foster
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=ablFUL_cBSJBJHgp@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.