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

[Alan Cox]

> But the desktop needs some means to deal with that. AFAICS the only
> feasible way for applications to communicate about device usage policy
> is locking with O_EXCL. Many people do not realize that even read-only

serial ports and mail both use fcntl file locking , which is much more
flexible.

> > The kernel does not have sufficient information to handle /dev/sg locking
> 
> But the kernel knows already that there is a block device behind it. It
> is displayed in sysfs. It shall "just" reuse the lock mechanism of that
> device, not more and not less. Naturally this "just" definition is
> bendable and that is why I initially asked here.

This doesn't help. There are legitimate reasons to use /dev/sg on a
device which is active. For most subsystems this actually makes a lot of
sense when doing things like enclosure control.

> The sad thing is, this is just another assumption. At least on Debian
> /dev/sgX belongs to the cdrom group when it's a cdrom device and the
> permissions do just invite to work with it.

Which means it is privilegded.

> IIRC there were similar issues with the SCSI command filtering with
> both but I am not sure on that.

SG_IO does command filtering, /dev/sg is intended to be assigned
correctly.

> > The desktop user space should really know what it is doing with the CD
> > device if it wants to do things like CD burning. If the serial port
> > people could get this right in 1977 then there is no excuse fo the CD
> 
> Serial port? Do we have multiple drivers with multiple interfaces
> accessing the same hardware simultaneously and independently? I don't
> think so.

getty/modem/uucp/terminal emulator/slip/ppp/.. 

I do think so.

> The use of /dev/sg* is still common practice, its invention predates

The /dev/sg interface cannot do the locking. If you use /dev/sg you are
telling the kernel you what you are doing. If you don't then you'll make
coasters or even bigger messes. 

If you are prepared to fix the apps then I'd suggest fixing them to use
fcntl locks with exclusive lock/shared lock according to their need for
exclusivity. That would fix some of the HAL problems (open has side
effects relocking doesnt), but there are still corner cases with mounted
file systems that need handling and I can see those might need some kernel
helping hands.

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/