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

[Florian Mickler <florian@mickler.org>]

On Thu, 30 Sep 2010 22:32:33 +0200
Kay Sievers <kay.sievers@vrfy.org> wrote:

> On Thu, Sep 30, 2010 at 22:14, Florian Mickler <florian@mickler.org> wrote:
> > On Thu, 30 Sep 2010 21:27:52 +0200 Kay Sievers <kay.sievers@vrfy.org> wrote:
> 
> >> I don't think anything needs to be or can really be fixed in the
> >> kernel. We need a working O_EXCL, and before Tejun's patch it was
> >> broken. That the broken behavior seemed to have some wanted effects on
> >> some boxes can't the reason to leave O_EXCL broken.
> >
> > Ack on this on the technical side.
> >
> > But we have to look from the user side at this, as bug tracking is
> > mostly a tool to get feedback from the users. So if we close this bug,
> > we loose valuable feedback on the functioning of the kernel.
> >
> > So, I can't really close the report if it is not resolved in any way.
> 
> As said, it can't be resolved. That it seemed to work was a buggy
> O_EXCL, which let stuff through the O_EXCL barrier, which was never
> supposed to reach the drive. I can't even reproduce that on older
> kernels. It seems like a specific timing problem.

Yes I see this from the changelog of Tejuns commit. It shure looks like
it all works just fine... 

Aren't cdrom devices physically locked while mounted? How could this be
a problem then? Is it about force-opening the device?

And what are the symptoms when the cd is removed while mounted? Are
there horrible timeouts when accessing the file system?


> > The issue is that the cdrom drive does not detect removal while it is
> > mounted.
> >
> > Do you see any way, how userspace can change this without kernel help?
> 
> Sure, it can open the device without O_EXCL like HAL. But successors
> of HAL stopped doing that because it broke too many burning sessions.

...seems sensible...

> >> The current state is the expected behavior.
> >
> > Expected for a kernel developer who understands the inner workings of
> > his system. For a user, I'd argue, this is not expected.
> 
> Yeah, might be. There is still nothing I think we can do at the moment
> at the kernel side.

I'm shure, there are ways to make this happen. And I don't think there
is any solution that doesn't involve the kernel.
 
> >> It all seems more like an
> >> issue with current udisks which should be discussed at the freedesktop
> >> bugzilla. Udisk's behavior is intended, but there might be no specific
> >> reason not to change it to what HAL did.
> >
> > I think we can close this, as soon as we have an acknowledged bug by
> > the udisks maintainer. But not earlier.
> 
> It's not a bug of udisks, it's decided to do it that way. It can be
> discussed though.
> 
> > At the moment, I don't see this issue as resolved.
> 
> Sure, no problem. I'm just saying that nobody can fix the problem in
> the kernel without adding something completely new like in-kernel
> polling. And that might take a longer time to get actually enabled by
> default. :)
> 
> Kay

I don't think we pay rent in the bugzilla yet... So this can just stay
open, until the necessary infrastructure is in place.. 
But I'm wondering if it is futile or not.

Regards,
Flo