Kernel 2.5.44
1) a module which needs to create a device needs to call add_disk
in it's init, or it seems the kernel won't allow opens of the
device node.
* But it can't call add_disk normally without invoking
* check_partitions (escape, do so with capacity=0 or minors=1)
* which will stall as it needs to read the device or its
* backer on disk, and we're still in init ...
This hits NBD. Pavel's kernel NBD escaped (luckily?-) because his
device is not partitionable, and so he called add_disk with
minors=1 even though capacity was set to maximum. But he narrowly
missed hanging in init.
It's not clear how we're supposed to /subsequently/ go out and find
some partitions over NBD, or how to avoid the races in doing so,
since we are already sort of open for business. HEEEEELP. My own
ENBD is being hit by this because it is partitionable.
Can someone document the new genhd and partitions interfaces?
I'm confused as anything, and fed up hunting for disappeared things
that now seem to be available via strings of pointer references off
of new structs (how do I get to rescan_partitions, for example!).
2) Partitions, ah yes, partitions.
Well, seems the kernel is similarly not permitting opens of minors
until we've run the partition check in add_disk. That's good
encapsulation if you are planning on doing i/o to them, but I
was planning on doing ioctls! And I don't think it's fair to
stop me doing ioctls to the minors. Well, we can argue that, but it
will break my userspace tools, and I'd rather not introduce
incompatibilities between kernel versions.
In any case, I don't think it's fair to equate minors with
partitions. Partitions are ONE use of minors. I use minors as
indices, to indicate which channel to a device should be used.
The device has its partition structure, and any partition can
be served (I'm speaking of requests) via any channel, i.e.,
any minor.
* My catch 22 is that I can't start using the channels/minors to
* talk to the remote device (ENBD) until I've opened the device
* and done the partition search via add_disk, which won't work
* until the channels are open ...
Help. I'm still fairly sane, but this is hurting.
Ideally, what I would like, is to be able to open the minors for
ioctls before allowing them to be open for r/w as partitions. Then
I don't need to do any changes. I open NOBLOCK for ioctls, if
that's any help.
Now, what's with this register_region business? Can I maybe open 256
devices on the same major, with 1 minor each, just to enable
communications to the remote, then read the remote partition table, then
unregister them all, then register them all again this time with 16
minors per device, as I originally wanted? No! The partition check
will fail, because there are too many partitions (>0) !
Help.
OK, I know what the userspace solution is, but I don't want to do it:
Make all ioctls go the the whole disk minor. And keep them there. And
even then, how am I supposed to rescan the device for partitions and
avoid the races that must be in progress for access to those partitions
at startup?
Peter
Peter T. Breuer wrote:
> Kernel 2.5.44
>
> 1) a module which needs to create a device needs to call add_disk
> in it's init, or it seems the kernel won't allow opens of the
> device node.
>
> * But it can't call add_disk normally without invoking
> * check_partitions (escape, do so with capacity=0 or minors=1)
> * which will stall as it needs to read the device or its
> * backer on disk, and we're still in init ...
>
> This hits NBD. Pavel's kernel NBD escaped (luckily?-) because his
> device is not partitionable, and so he called add_disk with
> minors=1 even though capacity was set to maximum. But he narrowly
> missed hanging in init.
>
> It's not clear how we're supposed to /subsequently/ go out and find
> some partitions over NBD, or how to avoid the races in doing so,
> since we are already sort of open for business. HEEEEELP. My own
> ENBD is being hit by this because it is partitionable.
>
> Can someone document the new genhd and partitions interfaces?
> I'm confused as anything, and fed up hunting for disappeared things
> that now seem to be available via strings of pointer references off
> of new structs (how do I get to rescan_partitions, for example!).
>
> 2) Partitions, ah yes, partitions.
>
> Well, seems the kernel is similarly not permitting opens of minors
> until we've run the partition check in add_disk. That's good
> encapsulation if you are planning on doing i/o to them, but I
> was planning on doing ioctls! And I don't think it's fair to
> stop me doing ioctls to the minors. Well, we can argue that, but it
> will break my userspace tools, and I'd rather not introduce
> incompatibilities between kernel versions.
>
> In any case, I don't think it's fair to equate minors with
> partitions. Partitions are ONE use of minors. I use minors as
> indices, to indicate which channel to a device should be used.
> The device has its partition structure, and any partition can
> be served (I'm speaking of requests) via any channel, i.e.,
> any minor.
>
> * My catch 22 is that I can't start using the channels/minors to
> * talk to the remote device (ENBD) until I've opened the device
> * and done the partition search via add_disk, which won't work
> * until the channels are open ...
>
>
> Help. I'm still fairly sane, but this is hurting.
>
> Ideally, what I would like, is to be able to open the minors for
> ioctls before allowing them to be open for r/w as partitions. Then
> I don't need to do any changes. I open NOBLOCK for ioctls, if
> that's any help.
>
> Now, what's with this register_region business? Can I maybe open 256
> devices on the same major, with 1 minor each, just to enable
> communications to the remote, then read the remote partition table, then
> unregister them all, then register them all again this time with 16
> minors per device, as I originally wanted? No! The partition check
> will fail, because there are too many partitions (>0) !
>
> Help.
>
> OK, I know what the userspace solution is, but I don't want to do it:
> Make all ioctls go the the whole disk minor. And keep them there. And
> even then, how am I supposed to rescan the device for partitions and
> avoid the races that must be in progress for access to those partitions
> at startup?
>
>
>
>
> Peter
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
I suppose this is related to the fact that with 2.5.44 (also in -ac),
trying to mount an unformated floppy give the following oops:
Unable to handle kernel NULL pointer dereference at virtual address 00000290
printing eip:
c01483bc
*pde = 00000000
Oops: 0000
CPU: 1
EIP: 0060:[<c01483bc>] Not tainted
EFLAGS: 00010202
EIP is at do_open+0x2bc/0x470
eax: c039ba08 ebx: f7f78c00 ecx: 000002a0 edx: f78c4a80
esi: f7881ec0 edi: f7881e60 ebp: c03114cc esp: f16f9d54
ds: 0068 es: 0068 ss: 0068
Process mount (pid: 159, threadinfo=f16f8000 task=f7921980)
Stack: 00000000 f7881ec0 f16f9e14 00000003 f7881ee0 00026c6c f7f78c00 00000000
00000000 021c9df4 00000000 0000001c c01485de f7881ec0 f78c4a80 f16f9e14
00000000 00000000 00000003 f7881ec0 00000000 00000000 f78c4a80 00000000
Call Trace:
[<c01485de>] blkdev_get+0x6e/0x80
[<c0146dba>] get_sb_bdev+0xaa/0x220
[<c017ee2f>] vfat_get_sb+0x1f/0x30
[<c017ed50>] vfat_fill_super+0x0/0xc0
[<c01470d0>] do_kern_mount+0x50/0xc0
[<c015b1b5>] do_add_mount+0x65/0x150
[<c015b4aa>] do_mount+0x16a/0x190
[<c015b2ed>] copy_mount_options+0x4d/0xa0
[<c015b9c5>] sys_mount+0xb5/0x130
[<c01072ef>] syscall_call+0x7/0xb
Code: 8b 41 f0 0b 41 f4 75 23 8b 46 44 ff 48 54 8b 46 44 8d 48 20