[PATCH] blkdev_open/bd_claim vs BLKBSZSET

[PATCH] blkdev_open/bd_claim vs BLKBSZSET

[Nathan Scott]

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);

Re: [PATCH] blkdev_open/bd_claim vs BLKBSZSET

[viro]

On Tue, Feb 24, 2004 at 10:17:05AM +1100, Nathan Scott wrote:
> 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...)
 
> 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?

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

Re: [PATCH] blkdev_open/bd_claim vs BLKBSZSET

[Nathan Scott]

On Mon, Feb 23, 2004 at 11:28:04PM +0000, viro@parcelfarce.linux.theplanet.co.uk wrote:
> On Tue, Feb 24, 2004 at 10:17:05AM +1100, Nathan Scott wrote:
> > 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...)
>  
> > 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?
> 
> <shrug> it can be done that way, but I really wonder why the hell does
> mkfs.xfs bother with BLKBSZSET in the first place?

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.

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

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

cheers.

-- 
Nathan

Re: [PATCH] blkdev_open/bd_claim vs BLKBSZSET

[viro]

On Tue, Feb 24, 2004 at 10:53:39AM +1100, Nathan Scott wrote:
> No idea if that can still happen in 2.6, I imagine it can in 2.4
> where we originally saw the problem.

2.6 has none of that idiocy...