linux-ext4 - Re: ext3, BKL, journal replay, multiple non-bind mounts of same device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20070411035621.GM5967@schatzie.adilger.int>
Date:	Tue, 10 Apr 2007 21:56:21 -0600
From:	Andreas Dilger <adilger@...sterfs.com>
To:	"John Anthony Kazos Jr." <jakj@...-k-j.com>
Cc:	kernelnewbies@...linux.org, linux-ext4@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: ext3, BKL, journal replay, multiple non-bind mounts of same device

On Apr 10, 2007  20:49 -0400, John Anthony Kazos Jr. wrote:
> Since it is possible for the same block device to be mounted multiple 
> times concurrently by the same filesystem, and since ext3 explicitly 
> disables the BKL during its fill_super operation which would prevent this, 
> what is the result of mounting it multiple times this way? Especially if 
> the filesystem is dirty and a journal is replayed. (In any case, what 
> operation is being performed by ext3/ext4 that requires the BKL to be 
> dropped? What's the need to even consider the BKL during fill_super?)
> 
> And in general, how does a filesystem deal with being mounted multiple 
> times in this way? In my testing and exploration so far, everything seems 
> to generally work, but I haven't tried deliberately using different 
> instances of the mount concurrently. Do we end up with locks not being 
> held properly on the superblock because the super_block structure 
> instances don't know about each other? Has dealing with this behavior of 
> bd_claim really been considered before, and if so, what's the general 
> scheme for handling it?

It is a myth (that actually frightened me quite a bit when I first did it)
that the filesystem is mounted twice in this case.  The truth of the matter
is if you "mount -t ext3 /dev/XXXX /mnt/1" and "... /mnt/2" you actually
get the equivalent of a bind mount for this block device on the two mount
points.  You can see this easily because e.g. you don't get two kjournald
threads for the two mounts, and it doesn't completely blow up.

If, on the other hand, you tried one mount with ext3 and another with ext4
it will fail the second with -EBUSY.

As for the BKL changes, your best bet is to go back through GIT and/or BK
or search the mailing lists to see when and why that was added.  It appears
to have  been 2.6.11, but I don't know why.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html