* [PATCH] blkdev_open/bd_claim vs BLKBSZSET
@ 2004-02-23 23:17 Nathan Scott
2004-02-23 23:28 ` viro
0 siblings, 1 reply; 4+ messages in thread
From: Nathan Scott @ 2004-02-23 23:17 UTC (permalink / raw)
To: akpm, torvalds; +Cc: linux-kernel
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);
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH] blkdev_open/bd_claim vs BLKBSZSET
2004-02-23 23:17 [PATCH] blkdev_open/bd_claim vs BLKBSZSET Nathan Scott
@ 2004-02-23 23:28 ` viro
2004-02-23 23:53 ` Nathan Scott
0 siblings, 1 reply; 4+ messages in thread
From: viro @ 2004-02-23 23:28 UTC (permalink / raw)
To: Nathan Scott; +Cc: akpm, torvalds, linux-kernel
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] blkdev_open/bd_claim vs BLKBSZSET
2004-02-23 23:28 ` viro
@ 2004-02-23 23:53 ` Nathan Scott
2004-02-24 0:54 ` viro
0 siblings, 1 reply; 4+ messages in thread
From: Nathan Scott @ 2004-02-23 23:53 UTC (permalink / raw)
To: viro; +Cc: akpm, torvalds, linux-kernel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2004-02-24 0:54 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-02-23 23:17 [PATCH] blkdev_open/bd_claim vs BLKBSZSET Nathan Scott
2004-02-23 23:28 ` viro
2004-02-23 23:53 ` Nathan Scott
2004-02-24 0:54 ` viro
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox