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: <AANLkTim_ZW6D6TKNh9W5Qn2biC0_BQcPuMKKKS6_X-bp@mail.gmail.com>
Date:	Thu, 30 Sep 2010 21:27:52 +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 16:49, Florian Mickler <florian@...kler.org> wrote:
> On Thu, 30 Sep 2010 16:17:32 +0200
> Maxim Levitsky <maximlevitsky@...il.com> wrote:
>> On Thu, 2010-09-30 at 13:38 +0200, Florian Mickler wrote:
>> > On Thu, 30 Sep 2010 09:48:50 +0200
>> > Kay Sievers <kay.sievers@...y.org> wrote:
>> > > >
>> > > > 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.
>> >
>> > So I'm gonna close this as invalid then. Please shout, if that's
>> > not ok.
>> Its not invalid at all.
>>
>> Let me explain again the problem:
>>
>> Indeed cdrom drivers need to be polled.
>> And yes, both udisks and hal _do_ poll the drive.
>>
>> However, udisks uses O_EXCL, when it opens the drive, and that fails s
>> soon as filesystem is mounted, therefore effectively, as soon as disk is
>> inserted, polling stops.
>>
>> Without the bisected commit, O_EXCL would still fail, however due to the
>> bug that commit fixed, the drive will still be polled.
>>
>> Hal also polls the drive, but it has a workaround, that is if open with
>> O_EXCL fails, it retries the open without it.
>>
>> This is pretty much all, there are no unknowns left.
>>
>>
>> However the reason behind O_EXCL is that we don't want polling while a
>> disk is being written (burned), but we do want polling while disk is
>> mounted.
>>
>> So just 'fixing' udisk to not take O_EXCL will bring us to square one,
>> as well as reverting the commit.
>>
>> Therefore this problem doesn't have a simple solution.
>> I think that the best solution is to move polling to the kernel, and
>> introduce a way for burning application to take absolute exclusive
>> access to the device and as a part of that disable that in-kernel
>> polling.
>> A new ioctl will suffice, or the meaning of O_EXCL can be changed for
>> cdrom driver only (if somebody has it open with O_EXCL, fail all opens,
>> including the ones that don't have O_EXCL).

> Ok. I will reopen then. Is someone working on fixing this issue?
>
> If we leave it open, we wanna have an ETA for the fix so that people
> trolling the bugzilla know for how long they have to let this report
> simmer.

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.

The current state is the expected behavior. 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.

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/