linux-ext4 - 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-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.0.83.0704102041210.7971@sigma.j-a-k-j.com>
Date:	Tue, 10 Apr 2007 20:49:16 -0400 (EDT)
From:	"John Anthony Kazos Jr." <jakj@...-k-j.com>
To:	kernelnewbies@...linux.org, linux-ext4@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: ext3, BKL, journal replay, multiple non-bind mounts of same device

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?
-
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