Documentation/filesystems/porting.rst

135 new file_system_type method - kill_sb(superblock).  If you are converting
208 just takes the superblock and inode number as arguments and does the
834 in ->destroy_inode()) is *NOT* ordered wrt superblock destruction;
835 as the matter of fact, the superblock and all associated structures
961 suitable superblock to reuse based on the block device pointer.
963 The new logic tries to find a suitable superblock first based on the device
970 In the old logic concurrent mounters would find the superblock on the list of
972 would hold s_umount they would wait until the superblock became either born or
983 The holder of a block device is now the superblock.
987 superblock without matching on the device pointer stored in the superblock.
989 find the owning superblock of any additional devices.
991 In the old mechanism reusing or creating a superblock for a racing mount(2) and
996     existing superblock was made to wait until the superblock either became
997     ready or until the superblock was removed from the list of superblocks of
998     the filesystem type. If the superblock is ready the caller would simple
1002     the superblock had been removed from the list of superblocks of the
1003     filesystem type the mounter would wait until the superblock was shutdown,
1004     reuse the block device and allocate a new superblock.
1007     the superblock had been removed from the list of superblocks of the
1009     superblock (the bd_holder point may still be set to the filesystem type).
1012 mounter could open the block devices of any superblock of the same
1014 still in use by another superblock.
1016 Making the superblock the owner of the block device changes this as the holder
1017 is now a unique superblock and thus block devices associated with it cannot be
1020 superblock.
1022 The new logic thus waits until the superblock and the devices are shutdown in
1023 ->kill_sb(). Removal of the superblock from the list of superblocks of the
1027     superblock is made to wait until the superblock is either ready or until
1028     the superblock and all devices are shutdown in ->kill_sb(). If the
1029     superblock is ready the caller will simply reuse it.
1032     the superblock has been removed from the list of superblocks of the
1033     filesystem type the mounter is made to wait until the superblock and the
1034     devices are shut down in ->kill_sb() and the superblock is removed from the
1036     superblock and grab ownership of the block device (the bd_holder pointer of
1037     the block device will be set to the newly allocated superblock).
1039 (3) This case is now collapsed into (2) as the superblock is left on the list
1041     ->kill_sb(). In other words, if the superblock isn't on the list of
1042     superblock of the filesystem type anymore then it has given up ownership of