On Wednesday 29 September 2004 16:35, Alan Cox wrote:

On Mer, 2004-09-29 at 13:08, Bartlomiej Zolnierkiewicz wrote:

quoted

quoted

Even in 2.4 ide drive hotplug was easy. The drive hotplug comes out
trivially because your controllers are fairly constant. As we all know
driver level hotplug is a bit trickier although the block layer has
really made this vastly easier in 2.6

For drive level hotplug you don't actually need refcounting at all
providing you've got a couple of locking issues dealt with.

These issues can't be solved without refcounting.

So you keep saying, but you refcount objects that are going away, you
don't need to refcount objects that are staying put.

quoted

Feel free to probe me wrong, you can start with fixing
->open vs unregister race (drive->usage involved). :)

Doesn't occur in the 2.4 situation or the 2.6 stuff with the locking in
the 2.6.8.1-ac patch.

I will verify this in a few days, I have some real work to do first.

quoted

quoted

Firstly the drive never goes away as a high level object (in fact you
don't want it to as then you can't ioctl it to make it come back!). That
means the upper layers don't know anything about it.

ioctls on not present devices are layering VIOLATION

Oh dear then I guess most of Linux is misdesigned. You aren't thinking
about the semantics at all. 

If /dev/hda is a CD-ROM drive I can issue commands to it with no CD 
present. Thats not a layering violation, and its how the IDE code works.
So whats the difference between hotplugging a drive and removing
a CD. Both are removing the media but leaving the controller behind.

Removing a CD leaves you with a drive between controller and media.

1st case: ioctl -> IDE driver -> drive
(lack of refcounting workarounded by ide-default)

2nd case: ioctl -> IDE driver
(lack of refcounting)

On that item I think you are talking out of your backside.

quoted

quoted

At the IDE layer the 2.4 code simply enforced the rule that you must be
the only opener of the device in order to hot unplug it. That means we

"enforced" - there are a couple of races, sorry but ROTFL

quoted

know its quiescent and not mounted. The only 2.4 race I know about is

- double unlock obvious mistake

Details ?

2003/08/16 alan               | 	/* Drive shutdown sequence done */
2003/08/16 alan               | 	/* Prevent new opens ?? */
2003/08/16 alan               | 	spin_unlock_irqrestore(&io_request_lock, flags);
2003/08/16 alan               | 	/*
2003/08/16 alan               | 	 * Flush kernel side caches, and dump the /proc files
2003/08/16 alan               | 	 */
2003/08/16 alan               | 	spin_unlock_irqrestore(&io_request_lock, flags);

quoted

- ->open() vs unregister

unregister is hot plug controller not drive and thats unfixable in 2.4

Doesn't matter. race is the same AFAICS, drive->usage
access is not protected by any lock.

quoted

- /proc races (the same you fixed in your 2.6 patch)

yeah that lot postdates the 2.4 work. hotplug drives is not the cause
however.

quoted

- ioctl races

Details ?

OK BKL protects us against i.e. concurrent HDIO_GETGEO
and hotplug ioctl.  There is however no protection for controller
hotplug.

quoted

gendisk layer and block layer enforces you to make /dev/hda disappear.

No it does not. The block layer couldn't give a flying **** whether
/dev/hda disappears or not. SCSI devices that are offlined don't need to
disappear either you just hand back commands with an error. You know -
like every CD-ROM does...

quoted

Does sysfs ring any bells?  Ask viro about static objects vs sysfs.
And yes not only gendisk and block enforces this, Patrick added basic,
premature sysfs support to IDE driver in the middle of 2.5 series.

We can get back to discussion when you get familiar with issues involved.

Ditto...

Alan