Re: PATCH/FIX for drivers/cdrom/cdrom.c

[Arjan van de Ven <arjan@infradead.org>]

On Thu, 2006-08-17 at 14:27 +0200, Bodo Eggert wrote:
> Arjan van de Ven <arjan@infradead.org> wrote:
> > On Wed, 2006-08-16 at 14:37 -0400, Lennart Sorensen wrote:
> 
> >> Perhaps the real problem is that some @#$@#$ user space task is
> >> constantly trying to mount the disc while something else is trying to
> >> write to it.
> >> 
> >> gnome and kde both seem very eager to implement such things.  perhaps
> >> there should be a way to prevent any access by such processes while
> >> writing to the disc.
> > 
> > there is. O_EXCL works for this.
> > Any sane desktop app and cd burning app use O_EXCL already for this
> > purpose...
> 
> This was discussed to death:
> 
> HAL using O_EXCL will randomly prevent burning/mounting/etc by causing a
> race condition, so it can't do that.

all burning apps will retry a few times if they get "busy"....

>  HAL not using O_EXCL will OTOH succeed
> in opening despite of O_EXCL used by the burning process and thereby
> prevent burning by opening a busy device. The proposed solution was
> introducing O_NONE or O_HARMLESS to prevent side-effects from opening
> the device.

doesn't help, since hal doesn't just open it, but also issues an ioctl
that then goes to the device, and THAT is causing the damage. Not the
open itself.

> This will, however, not prevent other users from maliciously destroying the
> CD by not using O_EXCL.

if the user wants to destroy his own burning cd... then why is it the
kernels job to stop him?

> Maybe it's possible to cache the result and thereby prevent repeated
> opening from disturbing the burning process.

oh I really want to have this ioctl cached, but more so that the kernel
can enforce a reasonable polling interval ;)

-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com