Messages in this thread | | | Date | Sat, 03 Dec 2005 12:42:40 -0500 | From | Jeff Mahoney <> | Subject | Re: [PATCH] fs: remove s_old_blocksize from struct super_block |
| |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Anton Altaparmakov wrote: > I have no idea why Jeff (Mahoney) considered the setting to be > unnecessary, when Al Viro added the resetting code a few years ago it > was done precisely because utilities were behaving randomly/erratically... > > IMHO the above commit consitutes a regression in 2.6 kernel.
Anton -
Linus and I discussed[1] this briefly on the list in March. Here's my conclusion[2]. My initial attempts tried to preserve the behavior, but keeping it at the VFS level made the fix more complex. Linus pointed out that the file systems explicitly set the block size to a known value before doing anything. Userspace utilities that don't open the block device with O_EXCL can have the block size changed underneath them in mid-execution - by the kernel or another userspace process using the BLKBSZSET ioctl. Incidentally, the ioctl doesn't save the old value either.
I don't think any userspace utility can expect a particular block size without an exclusive open and explicit set of the block size.
Pushing the resetting of the block size up into the file system doesn't eliminate the race. The race exists when get_sb_bdev_excl opens the block device, which it is allowed to do since it's the same file system type, and then tries to get the super block. If deactivate_super has already changed sb->s_count -= S_BIAS -1, sget will ignore the superblock and allocate a new one. It will then call the file system's fill_super(). Once a new superblock is allocated, the only thing that the two have in common is the block device and there is nothing preventing ->fill_super() from running concurrently with anything under - ->kill_sb(). This includes ->put_super() as well, so pushing the reset up into the individual file systems would just preserve/reintroduce the race.
bdev->bd_mount_sem might be a workable synchronization point for this if you truly want to preserve the old behavior.
- -Jeff
[1]: http://www.ussg.iu.edu/hypermail/linux/kernel/0503.1/2369.html [2]: http://www.ussg.iu.edu/hypermail/linux/kernel/0503.2/0460.html
- -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDkdkQLPWxlyuTD7IRAo0uAJ4+JQOz5g47rVlGZzwoaELY1G3q1QCfWSi+ HfGC1KAvRhm+YXU47cTK83U= =JHuY -----END PGP SIGNATURE----- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |