Re: [GIT PULL] bcachefs fixes for 6.7.y

[Greg Kroah-Hartman]

On Tue, Mar 12, 2024 at 08:54:24PM -0400, Kent Overstreet wrote:
> On Sun, Mar 10, 2024 at 03:43:38PM -0400, Kent Overstreet wrote:
> > The following changes since commit 2e7cdd29fc42c410eab52fffe5710bf656619222:
> > 
> >   Linux 6.7.9 (2024-03-06 14:54:01 +0000)
> > 
> > are available in the Git repository at:
> > 
> >   https://evilpiepirate.org/git/bcachefs.git tags/bcachefs-for-v6.7-stable-20240310
> > 
> > for you to fetch changes up to 560ceb6a4d9e3bea57c29f5f3a7a1d671dfc7983:
> > 
> >   bcachefs: Fix BTREE_ITER_FILTER_SNAPSHOTS on inodes btree (2024-03-10 14:36:57 -0400)
> > 
> > ----------------------------------------------------------------
> > bcachefs fixes for 6.7 stable
> > 
> > "bcachefs: fix simulateously upgrading & downgrading" is the important
> > one here. This fixes a really nasty bug where in a rare situation we
> > wouldn't downgrade; we'd write a superblock where the version number is
> > higher than the currently supported version.
> > 
> > This caused total failure to mount multi device filesystems with the
> > splitbrain checking in 6.8, since now we wouldn't be updating the member
> > sequence numbers used for splitbrain checking, but the version number
> > said we would be - and newer versions would attempt to kick every device
> > out of the fs.
> > 
> > ----------------------------------------------------------------
> > Helge Deller (1):
> >       bcachefs: Fix build on parisc by avoiding __multi3()
> > 
> > Kent Overstreet (3):
> >       bcachefs: check for failure to downgrade
> >       bcachefs: fix simulateously upgrading & downgrading
> >       bcachefs: Fix BTREE_ITER_FILTER_SNAPSHOTS on inodes btree
> > 
> > Mathias Krause (1):
> >       bcachefs: install fd later to avoid race with close
> > 
> >  fs/bcachefs/btree_iter.c        |  4 +++-
> >  fs/bcachefs/chardev.c           |  3 +--
> >  fs/bcachefs/errcode.h           |  1 +
> >  fs/bcachefs/mean_and_variance.h |  2 +-
> >  fs/bcachefs/super-io.c          | 27 ++++++++++++++++++++++++---
> >  5 files changed, 30 insertions(+), 7 deletions(-)
> 
> Why wasn't this applied?

Because our queue is huge and 1/2 of the stable team is finally taking
his first vacation in years (and regretting reading email during it
right now)?  Relax, it will get there, backport requests like this not
being handled in 48 hours seems like a big ask, don't you think?

greg k-h