blkdev_open/bd_claim vs BLKBSZSET

Hi there,

I was modifying mkfs.xfs to use O_EXCL for 2.6, and hit a snag. It seems that once I've opened a block dev with O_EXCL I can no longer issue the BLKBSZSET ioctl to it. (Is that the expected behavior? If so, ignore...)

The fs/block_dev.c code for blkdev_open does:

int blkdev_open(struct inode * inode, struct file * filp)

	...
		if (!(res = bd_claim(bdev, filp)))
		return 0;

And the drivers/block/ioctl.c code for BLKBSZSET does this:

	int	holder;
	...
	case BLKBSZSET:
		...
		if (bd_claim(bdev, &holder) < 0)
			return -EBUSY;
		ret = set_blocksize(bdev, n);
		bd_release(bdev);

And mkfs gets EBUSY back from the ioctl. Using the patch below, the ioctl succeeds cos the original filp bdev owner from open now matches with the owner in the ioctl call. I suspect that would be the correct behavior, but perhaps I'm overlooking some good reason for it being this way?

cheers.

Nathan


--- /usr/tmp/TmpDir.4274-0/drivers/block/ioctl.c_1.1	2004-02-24 08:58:28.000000000 +1100
+++ drivers/block/ioctl.c	2004-02-23 20:12:24.216909064 +1100
@@ -138,7 +138,6 @@
 	struct block_device *bdev = inode->i_bdev;
 	struct gendisk *disk = bdev->bd_disk;
 	struct backing_dev_info *bdi;
-	int holder;
 	int ret, n;
 
 	switch (cmd) {
@@ -175,7 +174,7 @@
 			return -EINVAL;
 		if (get_user(n, (int *) arg))
 			return -EFAULT;
-		if (bd_claim(bdev, &holder) < 0)
+		if (bd_claim(bdev, file) < 0)
 			return -EBUSY;
 		ret = set_blocksize(bdev, n);
 		bd_release(bdev);

<shrug> it can be done that way, but I really wonder why the hell does mkfs.xfs bother with BLKBSZSET in the first place?

FWIW, that ioctl is practically never the right thing to do these days. I'm not saying that we shouldn't apply the patch - it looks sane - but it looks like mkfs.xfs is doing something bogus.

Thats taking me back a few years - IIRC this was originally added because mkfs.xfs zeroes out the last N KB of the device before it goes on to creating the XFS filesystem. Waaay back (~3 years now?) there was a problem when someone had, say, a 4K block size ext2 fs on the device - mount/unmount of that left the device block size at 4K in the kernel, when mkfs.xfs then came along it would not be able to zero the last small-amount-less-than-4K of the device (on devices where the size was not 4K aligned only - heh, that was a fun wrinkle) and mkfs would see write-past-end-of-device errors.

No idea if that can still happen in 2.6, I imagine it can in 2.4 where we originally saw the problem.

At least for some older kernel versions this was needed - possibly still is, I'm not sure.

cheers.

Nathan

2.6 has none of that idiocy...