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

[Kay Sievers]

On Thu, Sep 30, 2010 at 22:14, Florian Mickler <florian@xxxxxxxxxxx> wrote:
> On Thu, 30 Sep 2010 21:27:52 +0200 Kay Sievers <kay.sievers@xxxxxxxx> 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.

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

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

>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/