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: <1285856252.26846.12.camel@maxim-laptop>
Date:	Thu, 30 Sep 2010 16:17:32 +0200
From:	Maxim Levitsky <maximlevitsky@...il.com>
To:	Florian Mickler <florian@...kler.org>
Cc:	Kay Sievers <kay.sievers@...y.org>, 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, 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.
> > 
> > Kay
> 
> 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).

Best regards,
	Maxim Levitsky

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