Re: broken device locking, sg vs. sg_io on block devices

[Eduard Bloch <edi@gmx.de>]

#include <hallo.h>
* Christoph Hellwig [Fri, Mar 30 2007, 02:43:27PM]:

> > Long story:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=413960
> > https://bugzilla.novell.com/show_bug.cgi?id=226019
> > http://lists.alioth.debian.org/pipermail/debburn-devel/2007-February/000297.html
> > and other error messages.
> > 
> > There is AFAICS no simple way to establish locking across the driver
> > borders. If kernel developers have a good idea, any help is appreciated.
> > 
> > Below are the typical symptoms: wodim operates via /dev/sgX because the
> > user chosen it this way, some other process (most likely hald) comes
> > along and reads from /dev/sr0 and the drive gets confused. Boom.
> 
> You have thre problems here, and none of them are in the kernel :)
> 
> First the hardsware is broken when it can't deal with concurrent requests,
> I'd try to get a refund for it.  Second wodim should never ever use
> /dev/sg if the sr node is available.  And third HAL should stop poking
> devices all the time.  Then again hald is a totally lost cause and
> I can only recommend to uninstall it ASAP.

Then make /dev/sg* unusable when something opens /dev/sr. Please.
Otherwise it is just another assumption of how things might or should
work, not really matching the use cases in the wild. And here are
some real world facts:

 - there is a fixed mapping between the fake-SCSI numbers and devices
   established by Schilling. People are using it, it is hardcoded into
   frontend applications. We cannot change that overnight without
   breaking even more stuff.
   
   If there is a simple way to get the mapping between the sg and sr
   devices that would be great and almost solve the problems, but I
   cannot discover a such thing in the kernel.

 - hald is using O_EXCL already, as wodim does, and this seems to work
   well as long as they are acting on the same virtual devices.

 - hald is installed together with KDE. Do you suggest to remove KDE as
   well? I don't think so.

 - of course the hardware does not handle concurent requests, it is
   designed that way. It is burden of kernel to canalize the access and
   deal with concurrency issues. Obviously the kernel can and shall not
   do all the work but at least the basic safety mechanisms must work
   reliably and currently they don't.

Eduard.
-- 
<LGS> Halloechen, ihr Spinner, so frueh auf?
<nusse> nein, wir schlafen alle im kollektiv
<knorke> mein alkoven ist kaputt
<teq> alkohol kaputt?