Re: [REGRESSION] cdrom drive doesn't detect removal

[Florian Mickler <florian@mickler.org>]

On Thu, 23 Sep 2010 11:21:08 +0200
Kay Sievers <kay.sievers@vrfy.org> wrote:

> On Thu, Sep 23, 2010 at 10:47, Tejun Heo <tj@kernel.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.
> 
> Kay

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... 

Regards,
Flo