public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Maxim Levitsky <maximlevitsky@gmail.com>,
	Kay Sievers <kay.sievers@vrfy.org>
Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Jens Axboe <axboe@kernel.dk>
Subject: Re: [REGRESSION] cdrom drive doesn't detect removal
Date: Thu, 23 Sep 2010 10:47:27 +0200	[thread overview]
Message-ID: <4C9B141F.3050908@kernel.org> (raw)
In-Reply-To: <1285163911.3159.5.camel@maxim-laptop>

Hello,

On 09/22/2010 03:58 PM, Maxim Levitsky wrote:
>> 1. Make exclusive opens really exclusive.
>> That is if someone opens a device with exclusive access, no more opens
>> will succeed.
> And as a follow-up, indeed hal first tries exclusive open, and if it
> fails, it retries with non-exclusive open, and it succeeds.
> And that somewhat makes me think that exclusive open is pretty much
> useless.

Yeah, what I'm curious about is why hal behaves differently with
claiming block patch.  Exclusive open still fails with EBUSY with or
without the patch, right?  So, why does hal behave differently?

> Look if it fails. sure the device is open, but if doesn't fail, nothing
> prevents a bit less honest clients (that don't use exclusive open) to
> open the device. How exclusive such an open is then?

It's cooperative exclusion.  It doesn't assume the presence of hostile
programs having access to the device.

> So I mean exclusive open should really block _all_ following opens of
> the device, exclusive or not.

That will probably break a lot of stuff.

> Btw I had few failed dual layer disk burns that failed just after write
> of few MBs. I wouldn't be surprised if this was the cause.

Usually open sequence just inserts TEST UNIT READY which usually is
safe but yeah it's possible that some device might react badly.

I'm currently working on in-kernel media presence polling to handle
the open and polling command sequence issues.  That said, it's not
entirely clear how the mount case should be handled.  If a media is
mounted, the device is exclusively open and media presence polling
shouldn't be inserting commands in the middle but then how can it
detect the media has been ejected by the user?  Kay, can you please
enlighten me on how it's supposed to work?

Thanks.

-- 
tejun

  reply	other threads:[~2010-09-23  8:47 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-12  9:49 [REGRESSION] cdrom drive doesn't detect removal Maxim Levitsky
2010-09-14  1:27 ` Maxim Levitsky
2010-09-14  7:39   ` Tejun Heo
2010-09-14  8:07     ` Kay Sievers
2010-09-14 23:38       ` Maxim Levitsky
2010-09-14 23:49         ` Kay Sievers
2010-09-15  0:37           ` Maxim Levitsky
2010-09-15  1:01             ` Kay Sievers
2010-09-15 13:27               ` Henrique de Moraes Holschuh
2010-09-15 13:44                 ` Kay Sievers
2010-09-15 22:20                   ` Maxim Levitsky
2010-09-16  6:51                     ` Kay Sievers
2010-09-21 11:42                       ` Maxim Levitsky
2010-09-21 23:09                         ` Maxim Levitsky
2010-09-22  7:38                           ` Tejun Heo
2010-09-22 13:41                             ` Maxim Levitsky
2010-09-22 13:58                               ` Maxim Levitsky
2010-09-23  8:47                                 ` Tejun Heo [this message]
2010-09-23  9:21                                   ` Kay Sievers
2010-09-30  6:30                                     ` Florian Mickler
2010-09-30  7:48                                       ` Kay Sievers
2010-09-30 11:38                                         ` Florian Mickler
2010-09-30 14:17                                           ` Maxim Levitsky
2010-09-30 14:49                                             ` Florian Mickler
2010-09-30 19:27                                               ` Kay Sievers
2010-09-30 20:14                                                 ` Florian Mickler
2010-09-30 20:32                                                   ` Kay Sievers
2010-09-30 20:47                                                     ` Florian Mickler
2010-09-30 20:57                                                       ` Kay Sievers
2010-10-01  5:55                                               ` Tejun Heo
2010-10-01  7:54                                                 ` Florian Mickler

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=4C9B141F.3050908@kernel.org \
    --to=tj@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=hmh@hmh.eng.br \
    --cc=kay.sievers@vrfy.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maximlevitsky@gmail.com \
    /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