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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTinMuLUB-vsiecMYHWv4ZbWE6yGB_K-8XB6GmaOv@mail.gmail.com>
Date:	Thu, 30 Sep 2010 22:32:33 +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 22:14, Florian Mickler <florian@...kler.org> wrote:
> On Thu, 30 Sep 2010 21:27:52 +0200 Kay Sievers <kay.sievers@...y.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.

> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/