Message-ID: <AANLkTi=G42-0X0MWsgTaDKEnHocFEa+9Cmw4pfCMAk5=@mail.gmail.com>
Date:	Thu, 30 Sep 2010 09:48:50 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Florian Mickler <florian@...kler.org>
Cc:	Maxim Levitsky <maximlevitsky@...il.com>,
	Tejun Heo <tj@...nel.org>,
	Henrique de Moraes Holschuh <hmh@....eng.br>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Jens Axboe <axboe@...nel.dk>
Subject: Re: [REGRESSION] cdrom drive doesn't detect removal

On Thu, Sep 30, 2010 at 08:30, Florian Mickler <florian@...kler.org> wrote:
> On Thu, 23 Sep 2010 11:21:08 +0200
> Kay Sievers <kay.sievers@...y.org> wrote:
>> On Thu, Sep 23, 2010 at 10:47, Tejun Heo <tj@...nel.org> wrote:
>>
>> > 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?
>>
>> We don't support unlocked cd doors. Currently eject/umount of optical
>> media has to be initiated by the user.
>>
>> HAL checked if the device was mounted, and if it was, it dropped the
>> O_EXCL. This was to support polling of the eject-button state, which
>> worked on a few drives. That's no longer cecked with udisks, it does
>> O_EXCL only for optical media.
>>
>> >> 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?
>>
>> >> 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.
>>
>> That would surely need a new flag like O_REALLYEXCL. :)
>>
>> > 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?
>>
>> Non-optical devices should not be a problem, and can be always polled,
>> as it seems. We do this without O_EXCL since forever.
>>
>> For optical drives I would never ever bypass O_EXCL, like udisks is
>> doing it. There are far too many problems with burning, which never
>> got really solved.
>>
>> Force-removed media (not recommended unlocked doors) might not be
>> detected until the filesystem is cleaned-up/umounted, but that's
>> probably the better compromise than fiddling with the broken drives
>> during burning sessions.
>
> So, is the $subject problem solved now? Normally, we shouldn't break
> stuff with new kernels... If this is only a temporary breakage on
> the other hand, we should keep track of it...
> I ask, because this is listed as https://bugzilla.kernel.org/show_bug.cgi?id=18522.
> If it should stay listed, we may need an ETA for the fix...

Hmm, I still don't think that's a bug or regression.

Optical drives are not supposed to report media changes without
constantly being polled. Why Tejun's seems to have an influence in
Maxim's setup, is likely more a timing-related issue, or some other
thing, we never really got an idea why it could change anything.

The current behavior is the expected and correct behavior, and for me
also the older kernels behave like this.

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

Powered by blists - more mailing lists