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: <1285110590.2822.9.camel@maxim-laptop>
Date:	Wed, 22 Sep 2010 01:09:50 +0200
From:	Maxim Levitsky <maximlevitsky@...il.com>
To:	Kay Sievers <kay.sievers@...y.org>
Cc:	Henrique de Moraes Holschuh <hmh@....eng.br>,
	Tejun Heo <tj@...nel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Jens Axboe <axboe@...nel.dk>
Subject: Re: [REGRESSION] cdrom drive doesn't detect removal

On Tue, 2010-09-21 at 13:42 +0200, Maxim Levitsky wrote: 
> On Thu, 2010-09-16 at 08:51 +0200, Kay Sievers wrote: 
> > On Thu, Sep 16, 2010 at 00:20, Maxim Levitsky <maximlevitsky@...il.com> wrote:
> > > So it makes the sense.
> > > It turns out that hal is still running on ubuntu systems, and yes, it
> > > still polls the drives, and yes I disabled that feature....
> > > So restoring that polling feature indeed fixes that problem for now.
> > > Yet, why without that commit detection did work?
> > 
> > Really, I have no idea how this can happen. You could only find out
> > with blocktrace, if something else is trying to open the device. The
> > state change in the drive should not be able to get known to the host
> > unless something is causing i/o with open().
> > 
> > Kay
> 
> Due to some unexplained laziness, I didn't put a printk to cdrom_open to
> figure out if drive is polled or not without hal.
> Today I finally found why kgdb didn't work (it was conflict with nmi
> watchdog), and just for fun I have put a breakpoint to cdrom_open.
> Well udisks *does* poll the drive, every few seconds, and therefore this
> is a regression.
> I will soon look at udisk source to see how it polls the drive.
> (Maybe it uses exclusive open and hal doesn't or something like that.)

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.

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