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

[Florian Mickler]

On Thu, 30 Sep 2010 21:27:52 +0200
Kay Sievers <kay.sievers@xxxxxxxx> wrote:

> On Thu, Sep 30, 2010 at 16:49, Florian Mickler <florian@xxxxxxxxxxx> wrote:
> > On Thu, 30 Sep 2010 16:17:32 +0200
> > Maxim Levitsky <maximlevitsky@xxxxxxxxx> 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@xxxxxxxx> 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.

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.

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?

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


> 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

I think we can close this, as soon as we have an acknowledged bug by
the udisks maintainer. But not earlier. 

At the moment, I don't see this issue as resolved. 

Regards,
Flo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/