linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: zhanchengbin <zhanchengbin1@huawei.com>
Cc: linux-ext4@vger.kernel.org, linfeilong <linfeilong@huawei.com>,
	louhongxiang@huawei.com, liuzhiqiang26@huawei.com
Subject: Re: [bug report] tune2fs: filesystem inconsistency occurs by concurrent write
Date: Sun, 25 Jun 2023 22:17:58 -0400	[thread overview]
Message-ID: <20230626021758.GF8954@mit.edu> (raw)
In-Reply-To: <29f6134f-ba0a-d601-0a5a-ad2b5e9bbf1d@huawei.com>

On Mon, Jun 26, 2023 at 12:00:08AM +0800, zhanchengbin wrote:
> Tune2fs does not recognize writes to the manipulated filesystem in another
> namespace, there will be two simultaneous write operations on a
> block, resulting in filesystem inconsistencies.

What you are reporting has nothing to do with namespaces, since
"tune2fs -e remount-ro /dev/sdb" is something which is allowed
regardless of whether the file system is mounted.  What reproduction
is effectively doing is trying to set up a race between when tune2fs
writes a byte to update to update the errors behavior, and when the
actual unmount of the file system happens (e.g., when the last
namespace unmounts the file system).  At that point, the kernel is
going to be updating the superblock as part of the unmount, and then
it calculates the superblock, and then it writes out the superblock.

If the tune2fs races with the unmount, it's possible for the tune2fs
update of the error beavhiour bit, and the update of the superblock
checksum, to race with the kernel's final update of the superblock,
includinig its attempt to update the checksum.

There are some workarounds to this, but ultimately, we need to replace
the ad-hoc modification of the block device by tune2fs with some
ioctls which specifically update superblock when the file system
mounted.

As far as whether or not tune2fs can detect if the file system is
mounted, what we can do is check to see if the block device is busy.
If it is mounted in some other namespace, we won't be able to see it
mounted in /proc/self/mounts, but we can see that it's not possible to
open the block device with O_EXCL.

Compare:

root@kvm-xfstests:~# /vtmp/tst_ismounted /dev/vdc
Device /dev/vdc reports flags 31
        /dev/vdc is apparently in use.
        /dev/vdc is mounted.
        /dev/vdc is mounted on /vdc.

and then "unshare -m" in another terminal, followed by umount /dev/vdc
in the first terminal:

root@kvm-xfstests:~# /vtmp/tst_ismounted /dev/vdc
Device /dev/vdc reports flags 10
        /dev/vdc is apparently in use.

... and then after we exit the last mount namespace which was keeping
/dev/vdc mounted:

root@kvm-xfstests:~# [ 2409.811328] EXT4-fs (vdc): unmounting filesystem bdc026fd-85a8-4ccf-94f8-961487000293.
root@kvm-xfstests:~# /vtmp/tst_ismounted /dev/vdc
Device /dev/vdc reports flags 00

Cheers,

						- Ted

  reply	other threads:[~2023-06-26  2:18 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-25 16:00 [bug report] tune2fs: filesystem inconsistency occurs by concurrent write zhanchengbin
2023-06-26  2:17 ` Theodore Ts'o [this message]
2023-06-26 11:56   ` zhanchengbin
2023-07-04  8:35   ` zhanchengbin
2023-07-04 19:33     ` Theodore Ts'o
2023-07-08  7:29       ` zhanchengbin
2023-07-12  0:05         ` Darrick J. Wong
2023-07-12  9:06           ` zhanchengbin
2023-07-12 15:42             ` Theodore Ts'o

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=20230626021758.GF8954@mit.edu \
    --to=tytso@mit.edu \
    --cc=linfeilong@huawei.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=liuzhiqiang26@huawei.com \
    --cc=louhongxiang@huawei.com \
    --cc=zhanchengbin1@huawei.com \
    /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;
as well as URLs for NNTP newsgroup(s).