All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Josh Triplett <josh@joshtriplett.org>
Cc: Jan Kara <jack@suse.cz>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Theodore Ts'o <tytso@mit.edu>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Jan Kara <jack@suse.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-ext4@vger.kernel.org
Subject: Re: ext4 regression in v5.9-rc2 from e7bfb5c9bb3d on ro fs with overlapped bitmaps
Date: Mon, 5 Oct 2020 18:19:41 +0200	[thread overview]
Message-ID: <20201005161941.GF4225@quack2.suse.cz> (raw)
In-Reply-To: <20201005101641.GA516771@localhost>

On Mon 05-10-20 03:16:41, Josh Triplett wrote:
> On Mon, Oct 05, 2020 at 11:46:01AM +0200, Jan Kara wrote:
> > On Mon 05-10-20 01:14:54, Josh Triplett wrote:
> > > Ran into an ext4 regression when testing upgrades to 5.9-rc kernels:
> > > 
> > > Commit e7bfb5c9bb3d ("ext4: handle add_system_zone() failure in
> > > ext4_setup_system_zone()") breaks mounting of read-only ext4 filesystems
> > > with intentionally overlapping bitmap blocks.
> > > 
> > > On an always-read-only filesystem explicitly marked with
> > > EXT4_FEATURE_RO_COMPAT_SHARED_BLOCKS, prior to that commit, it's safe to
> > > point all the block and inode bitmaps to a single block of all 1s,
> > > because a read-only filesystem will never allocate or free any blocks or
> > > inodes.
> > > However, after that commit, the block validity check rejects such
> > > filesystems with -EUCLEAN and "failed to initialize system zone (-117)".
> > > This causes systems that previously worked correctly to fail when
> > > upgrading to v5.9-rc2 or later.
> > > 
> > > This was obviously a bugfix, and I'm not suggesting that it should be
> > > reverted; it looks like this effectively worked by accident before,
> > > because the block_validity check wasn't fully functional. However, this
> > > does break real systems, and I'd like to get some kind of regression fix
> > > in before 5.9 final if possible. I think it would suffice to make
> > > block_validity default to false if and only if
> > > EXT4_FEATURE_RO_COMPAT_SHARED_BLOCKS is set.
> > > 
> > > Does that seem like a reasonable fix?
> > 
> > Well, but EXT4_FEATURE_RO_COMPAT_SHARED_BLOCKS is your internal feature
> > that's not present in current upstream kernel AFAICS.
> 
> It isn't "my" feature; the value for
> EXT4_FEATURE_RO_COMPAT_SHARED_BLOCKS is defined in the headers in the
> e2fsprogs tree. The kernel currently does absolutely nothing with it,
> nor did it previously need to; it's just an RO_COMPAT feature which
> ensures that the kernel can only mount the filesystem read-only. The
> point is that an always-read-only filesystem will never change the block
> or inode bitmaps, so ensuring they don't overlap is unnecessary (and
> harmful).

Ah, I see. I missed EXT4_FEATURE_RO_COMPAT_SHARED_BLOCKS is actually
defined in e2fsprogs. Then what you suggests makes sense I guess and it's
good the headers are synced up again...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

  reply	other threads:[~2020-10-05 16:19 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-04 23:17 Linux 5.9-rc8 Linus Torvalds
2020-10-05  8:14 ` ext4 regression in v5.9-rc2 from e7bfb5c9bb3d on ro fs with overlapped bitmaps Josh Triplett
2020-10-05  9:46   ` Jan Kara
2020-10-05 10:16     ` Josh Triplett
2020-10-05 16:19       ` Jan Kara [this message]
2020-10-05 16:20   ` Jan Kara
2020-10-05 17:36   ` Darrick J. Wong
2020-10-06  0:04     ` Theodore Y. Ts'o
2020-10-06  0:32     ` Josh Triplett
2020-10-06  2:51       ` Darrick J. Wong
2020-10-06  3:18         ` Theodore Y. Ts'o
2020-10-06  5:03           ` Josh Triplett
2020-10-06  6:03             ` Josh Triplett
2020-10-06 13:35             ` Theodore Y. Ts'o
2020-10-07  8:03               ` Josh Triplett
2020-10-07 14:32                 ` Theodore Y. Ts'o
2020-10-07 20:14                   ` Josh Triplett
2020-10-08  2:10                     ` Theodore Y. Ts'o
2020-10-08 17:54                       ` Darrick J. Wong
2020-10-08 22:38                         ` Josh Triplett
2020-10-09  2:54                           ` Darrick J. Wong
2020-10-09 19:08                             ` Josh Triplett
2020-10-08 22:22                       ` Josh Triplett
2020-10-09 14:37                         ` Theodore Y. Ts'o
2020-10-09 20:30                           ` Josh Triplett
2021-01-10 18:41                           ` Malicious fs images was " Pavel Machek
2021-01-11 18:51                             ` Darrick J. Wong
2021-01-11 19:39                               ` Eric Biggers
2021-01-12 21:43                             ` Theodore Ts'o
2021-01-12 22:28                               ` Pavel Machek
2021-01-13  5:09                                 ` Theodore Ts'o
2020-10-08  2:57                     ` Andreas Dilger
2020-10-08 19:12                       ` Josh Triplett
2020-10-08 19:25                         ` Andreas Dilger
2020-10-08 22:28                           ` Josh Triplett

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=20201005161941.GF4225@quack2.suse.cz \
    --to=jack@suse.cz \
    --cc=adilger.kernel@dilger.ca \
    --cc=jack@suse.com \
    --cc=josh@joshtriplett.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    /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.