On Fri, 18 Oct 2002, Stephen Cameron wrote:
> Adds CCISS_RESCANDISK ioctl. Applies to 2.5.43 after the
> previous 9 patches I sent.
> -- steve
>
> This is meant to be used in a configuration like
> Steeleye's Lifekeeper. Two hosts connect to the storage, one
> reserves disks. The 2nd will not be able to read the partition
> information because of the reservations. In the event the 1st
> system fails, the 2nd can detect this, (via special hardware +
> software typically) and then take over the storage and rescan
> the disks via this ioctl.
> + if (minor(inode->i_rdev) != 0) {
> + /* if not node 0 make sure it is a partition = 0 */
> + if (minor(inode->i_rdev) & 0x0f)
> + return -ENXIO;
That's bogus. We call ->open() only for entire disk.
> + kdev = mk_kdev(MAJOR_NR + ctlr, disk->first_minor);
> + bdev = bdget(kdev_t_to_nr(kdev));
> + rescan_partitions(disk, bdev);
... and that is (a) obvious leak and (b) broken unless disk is already
open - it will try to do IO on bdev.
More interesting issue, though, is whether we need to bother with
complications coming from that interface anymore. Notice that
comment re "too many device nodes" doesn't hold these days - that
sort of stuff looks like a candidate for "write command into node
on driverfs" - especially when we are talking about configuring
the device, shutting disks down/starting them up, etc. Linus, Pat?
Unless I'm mistaken that's precisely the sort of work that is
supposed to live in driverfs...
-
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/
This archive was generated by hypermail 2b29 : Wed Oct 23 2002 - 22:00:41 EST