Message-ID: <20100930164918.22f40a83@schatten.dmk.lab>
Date:	Thu, 30 Sep 2010 16:49:18 +0200
From:	Florian Mickler <florian@...kler.org>
To:	Maxim Levitsky <maximlevitsky@...il.com>
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, 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.
> > > 
> > > 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
> 

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.

Regards,
Flo


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

Powered by blists - more mailing lists