public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org, linux-xfs@vger.kernel.org, hch@lst.de,
	Carlos Maiolino <cem@kernel.org>
Subject: Re: [PATCH 20/29] xfs: don't fail repairs on metadata files with no attr fork
Date: Mon, 21 Oct 2024 10:27:51 -0700	[thread overview]
Message-ID: <20241021172751.GA21853@frogsfrogsfrogs> (raw)
In-Reply-To: <2024101838-thickness-exposure-ec78@gregkh>

On Fri, Oct 18, 2024 at 08:00:21AM +0200, Greg KH wrote:
> On Thu, Oct 17, 2024 at 11:58:10AM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > Fix a minor bug where we fail repairs on metadata files that do not have
> > attr forks because xrep_metadata_inode_subtype doesn't filter ENOENT.
> > 
> > Cc: <stable@vger.kernel.org> # v6.8
> > Fixes: 5a8e07e799721b ("xfs: repair the inode core and forks of a metadata inode")
> > Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> > Reviewed-by: Christoph Hellwig <hch@lst.de>
> > ---
> >  fs/xfs/scrub/repair.c |    8 +++++---
> >  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> Why is a bugfix / stable-tagged-patch, number 20 in a 29 patch series?
> Why isn't it first, or better yet, on it's own if it is fixing a bug
> that people want merged "soon"?

I have too many patches, and every time I try to get a set through the
review process I end up having to write *more* patches to appease the
reviewers, and fixes get lost.  Look at the copyrights on the other
patches, I've been trying to get this upstreamed since 2018.

This particular bugfix got lost last month probably because I forgot to
ping cem to take it for 6.12-rc1.  Thanks for pushing on this, Greg.

Hey Carlos, can you queue this one up for 6.12-rc5, please?

--D

> thanks,
> 
> greg k-h
> 

  reply	other threads:[~2024-10-21 17:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20241017184009.GV21853@frogsfrogsfrogs>
2024-10-17 18:46 ` [PATCHSET v5.1 3/9] xfs: metadata inode directory trees Darrick J. Wong
2024-10-17 18:58   ` [PATCH 20/29] xfs: don't fail repairs on metadata files with no attr fork Darrick J. Wong
2024-10-18  6:00     ` Greg KH
2024-10-21 17:27       ` Darrick J. Wong [this message]
2024-10-22 11:16         ` Carlos Maiolino
2024-10-26  7:29     ` Carlos Maiolino

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=20241021172751.GA21853@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=cem@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=linux-xfs@vger.kernel.org \
    --cc=stable@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox