[dm-devel] device mapper ioctl handling

[Mikulas Patocka]

Hi

I was thinking about that ioctl handling - and the problem is that the 
current code is broken too. The current code does:

1. dm_get_live_table
2. call the "prepare_ioctl" method on the first target, that returns the 
   block device where the ioctl should be forwarded
3. call bdgrab on the block device
4. call blkdev_get on the block device
5. call dm_put_live_table
6. call __blkdev_driver_ioctl to forward the ioctl to the target device
7. call blkdev_put

One problem: bdgrab is not paired with bdput, so it introduces a memory 
leak? Perhaps it should be deleted.

The second problem: it may call ioctl on a device that is not part of a dm 
table. Between step 5 and step 6, the table may be reloaded with a 
different target, but it still calls the ioctl on the old device.

So - we need to prevent table reload while the ioctl is in progress.

But there is another possible problem - there is multipath flag 
MPATHF_QUEUE_IF_NO_PATH and the ioctl may take indefinite time if the flag 
is set and there is no active path. In this situation it would prevent 
reloading the upper targets above the multipath target. But I think this 
is acceptable - if the multipath device has MPATHF_QUEUE_IF_NO_PATH set, 
bios sent to the device are queued indefinitely and these queued bios 
would already prevent suspending the upper layer device mapper devices. 
So, if a stuck ioctl prevents suspending the upper layer devices, it 
doesn't make it worse.

Mikulas