On Wed, Mar 13, 2024 at 07:20:44PM +0100, Greg Kroah-Hartman wrote: > 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?
Ok - sorry for bothering you then :)
