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

From: Maxim Levitsky <maximlevitsky@gmail.com>
To: Florian Mickler <florian@mickler.org>
Cc: Kay Sievers <kay.sievers@vrfy.org>, Tejun Heo <tj@kernel.org>,
	Henrique de Moraes Holschuh <hmh@hmh.eng.br>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Jens Axboe <axboe@kernel.dk>
Subject: Re: [REGRESSION] cdrom drive doesn't detect removal
Date: Thu, 30 Sep 2010 16:17:32 +0200	[thread overview]
Message-ID: <1285856252.26846.12.camel@maxim-laptop> (raw)
In-Reply-To: <20100930133823.39353d23@schatten.dmk.lab>

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