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