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: <1285162900.3335.15.camel@maxim-laptop>
Date:	Wed, 22 Sep 2010 15:41:40 +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 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.

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/