public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Helge Hafting <helge.hafting@aitel.hist.no>
To: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
Cc: Jeff Garzik <jeff@garzik.org>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	7eggert@gmx.de, Arjan van de Ven <arjan@infradead.org>,
	Dirk <noisyb@gmx.net>,
	linux-kernel@vger.kernel.org
Subject: Re: PATCH/FIX for drivers/cdrom/cdrom.c
Date: Thu, 17 Aug 2006 16:38:12 +0200	[thread overview]
Message-ID: <44E47F54.3000300@aitel.hist.no> (raw)
In-Reply-To: <20060817135431.GE13641@csclub.uwaterloo.ca>

Lennart Sorensen wrote:
> On Thu, Aug 17, 2006 at 09:41:06AM -0400, Jeff Garzik wrote:
>   
>> Lennart Sorensen wrote:
>>     
>>> Why can't O_EXCL mean that the kernel prevents anyone else from issuing
>>> ioctl's to the device?  One would think that is the meaning of exlusive.
>>> That way when the burning program opens the device with O_EXCL, no one
>>> else can screw it up while it is open.  If it happens to be polled by
>>> hal when the burning program tries to open it, it can just wait and
>>> retry again until it gets it open.
>>>       
>> Such use of O_EXCL is a weird and non-standard behavior.
>>     
>
> So what method exists for opening a file/device an guaranteeing that
> nothing else can do anything to it?
>   
None on the file level I hope, for it will surely get abused.
Windows have exclusive open for example, and there acrobat reader
locks the pdf file it views, so you can't make a new version without
killing acrobat first.  (And then you have to restart it to
view the new file.)  Stupid in the extreme.  Fortunately, acrobat can't
do that on linux where there is no (easy) opportunity to do so.

There are many other examples - backup sw can't read files that
happens to be opened exclusive by some process.

I guess this particular case could be solved by fixing the cdrom
driver like this:

Whenever the device is opened for writing (i.e. someone is
burning a CD/DVD), then reject the probing ioctls HAL uses.
Or just make the device exclusive while burning.  Restore
normal operation as soon as the burn ends.   There is no
use for reading the device during a burn anyway - a special case
for CD/DVD writers.


Helge Hafting







  reply	other threads:[~2006-08-17 14:41 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <6Kxns-7AV-13@gated-at.bofh.it>
     [not found] ` <6Kytd-1g2-31@gated-at.bofh.it>
     [not found]   ` <6KyCQ-1w7-25@gated-at.bofh.it>
2006-08-17 12:27     ` PATCH/FIX for drivers/cdrom/cdrom.c Bodo Eggert
2006-08-17 12:35       ` Arjan van de Ven
2006-08-18 12:31         ` Bodo Eggert
2006-08-18 12:53           ` Arjan van de Ven
2006-08-18 16:45           ` Alan Cox
2006-08-17 13:39       ` Alan Cox
2006-08-17 13:23         ` Lennart Sorensen
2006-08-17 13:41           ` Jeff Garzik
2006-08-17 13:54             ` Lennart Sorensen
2006-08-17 14:38               ` Helge Hafting [this message]
2006-08-18 12:39                 ` Bodo Eggert
2006-08-17 13:48           ` Alan Cox
2006-08-17 14:36             ` Lennart Sorensen
2006-08-17 14:38               ` Arjan van de Ven
2006-08-17 15:09               ` Alan Cox
2006-08-19 17:52               ` Oleg Verych
2006-08-21 17:31                 ` Lennart Sorensen
2006-08-16 17:26 Dirk
2006-08-16 17:40 ` Jan Engelhardt
2006-08-16 18:37   ` Dirk
2006-08-16 18:37 ` Lennart Sorensen
2006-08-16 18:44   ` Arjan van de Ven
2006-08-16 19:30   ` Dirk
2006-08-16 19:08 ` Alan Cox
2006-08-16 22:25 ` Andrew Morton
2006-08-17  7:50   ` Jan Engelhardt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44E47F54.3000300@aitel.hist.no \
    --to=helge.hafting@aitel.hist.no \
    --cc=7eggert@gmx.de \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arjan@infradead.org \
    --cc=jeff@garzik.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lsorense@csclub.uwaterloo.ca \
    --cc=noisyb@gmx.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox