iv/linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

porting: document new block device opening order

Browse Source 
We've changed the order of opening block devices and superblock
handling. Let's document this so filesystem and vfs developers have
a proper digital paper trail.

Signed-off-by: Christian Brauner <brauner@kernel.org>
This commit is contained in:
Christian Brauner 2023-09-15 16:01:02 +02:00
parent ae81711c1e
commit 2ba0dd6562
No known key found for this signature in database
GPG Key ID: 91C61BC06578DCA2
1 changed files with 26 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
Documentation/filesystems/porting.rst
View File

@ -949,3 +949,29 @@ mmap_lock held. All in-tree users have been audited and do not seem to
depend on the mmap_lock being held, but out of tree users should verify depend on the mmap_lock being held, but out of tree users should verify
for themselves. If they do need it, they can return VM_FAULT_RETRY to for themselves. If they do need it, they can return VM_FAULT_RETRY to
be called with the mmap_lock held. be called with the mmap_lock held.
---
**mandatory**
The order of opening block devices and matching or creating superblocks has
changed.
The old logic opened block devices first and then tried to find a
suitable superblock to reuse based on the block device pointer.
The new logic tries to find a suitable superblock first based on the device
number, and opening the block device afterwards.
Since opening block devices cannot happen under s_umount because of lock
ordering requirements s_umount is now dropped while opening block devices and
reacquired before calling fill_super().
In the old logic concurrent mounters would find the superblock on the list of
superblocks for the filesystem type. Since the first opener of the block device
would hold s_umount they would wait until the superblock became either born or
was discarded due to initialization failure.
Since the new logic drops s_umount concurrent mounters could grab s_umount and
would spin. Instead they are now made to wait using an explicit wait-wake
mechanism without having to hold s_umount.