Message-ID: <1285163911.3159.5.camel@maxim-laptop>
Date:	Wed, 22 Sep 2010 15:58:31 +0200
From:	Maxim Levitsky <maximlevitsky@...il.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	Kay Sievers <kay.sievers@...y.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 Wed, 2010-09-22 at 15:41 +0200, Maxim Levitsky wrote: 
> On Wed, 2010-09-22 at 09:38 +0200, Tejun Heo wrote: 
> > Hello,
> > 
> > On 09/22/2010 01:09 AM, Maxim Levitsky wrote:
> > > I just did a strace on udisks, and it is pretty much self explanatory.
> > > (While CD is mounted).
> > > 
> > > open("/dev/sr0", O_RDONLY|O_EXCL|O_NONBLOCK) = -1 EBUSY (Device or resource busy)
> > > poll([{fd=5, events=POLLIN}, {fd=3, events=POLLIN}], 2, 1997) = 0 (Timeout)
> > > open("/dev/sr0", O_RDONLY|O_EXCL|O_NONBLOCK) = -1 EBUSY (Device or resource busy)
> > > poll([{fd=5, events=POLLIN}, {fd=3, events=POLLIN}], 2, 1997) = 0 (Timeout)
> > > open("/dev/sr0", O_RDONLY|O_EXCL|O_NONBLOCK) = -1 EBUSY (Device or resource busy)
> > > poll([{fd=5, events=POLLIN}, {fd=3, events=POLLIN}], 2, 1997) = 0 (Timeout)
> > > open("/dev/sr0", O_RDONLY|O_EXCL|O_NONBLOCK) = -1 EBUSY (Device or resource busy)
> > > 
> > > Sure, a filesystem is mounted, so exclusive access fails...
> > > 
> > > So, we end up with impossible to solve problem.  We want on one hand
> > > to guard the burner against polling programs that disturb it, but
> > > one the other hand we must do polling to check CD status.
> > >
> > > Unless the kernel does the polling, but then we also must stop it
> > > when burning is done.  I think that we need new ioctl in the CD
> > > driver that would give absolute access to the burning application,
> > > and lock it fully.
> > 
> > One thing I don't get is why the behavior changed after the claiming
> > block patch.  Can you please trace udisks from a previous working
> > kernel?
> 
> It shows pretty much same output.
> The difference here is, even though open fails, it still has a side
> effect of polling the driver, a bug that bisected commit fixed.
> 
> So problem is clear, but how to fix it, I don't know...
> 
> Also about the exclusive mode, how exactly is it defined?
> open manpage is somewhat sparse about it.
> 
> Regardless of the above a complete solution is:
> 
> 1. Make exclusive opens really exclusive.
> That is if someone opens a device with exclusive access, no more opens
> will succeed.
And as a follow-up, indeed hal first tries exclusive open, and if it
fails, it retries with non-exclusive open, and it succeeds.
And that somewhat makes me think that exclusive open is pretty much
useless.
Look if it fails. sure the device is open, but if doesn't fail, nothing
prevents a bit less honest clients (that don't use exclusive open) to
open the device. How exclusive such an open is then?

So I mean exclusive open should really block _all_ following opens of
the device, exclusive or not.
Btw I had few failed dual layer disk burns that failed just after write
of few MBs. I wouldn't be surprised if this was the cause.


> 
> 2. Add in-kernel polling, and stop it as as soon as an exclusive open is
> done.
> 
> 3. Make sure that userspace doesn't touch the cdrom device anymore.
> Few patches to udisks and hal will do.
> 

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/

Powered by blists - more mailing lists