udev git head: cdrom_id regression

[Martin Pitt <martin.pitt@ubuntu.com>]

[-- Attachment #1: Type: text/plain, Size: 1971 bytes --]

Hello,

We got a report in Ubuntu [1] that CDs recently stopped being
recognized after insertion. I did some tests, and can reproduce this
perfectly on my wife's computer (which is of slightly older vintage).
It doesn't happen on my notebook with an USB CD drive, though.

The culprit was found quickly, udev does not get any ID_CDROM_*
properties after insertion (the change event triggered by udisks'
poller or the eject button). This bug was introduced with the recent
cdrom_id change to open the drive with O_EXCL [2]. Several people
(including me) confirmed that things work perfectly again after
reverting this.

The drive seems to be busy quite often, when I strace the udisks
poller process, I regularly get

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)

and I suppose the same fate also happens to cdrom_id when being
triggered by udev rules.

gvfs' cdda backend seems to keep an open fd, which explains the -EBUSY:

$ sudo fuser /dev/sr0
/dev/sr0:            14821
$ ps aux|grep 14821
martin   14821  0.0  0.1  60956  2784 ?        S    14:15   0:00 /usr/lib/gvfs/gvfsd-cdda --spawner :1.7 /org/gtk/gvfs/exec_spaw/7

So this looks like a race condition between gvfs and udev? But then
again, calling it manually has always worked for me:

$ sudo strace -e open /lib/udev/cdrom_id /dev/sr0
[...]
open("/dev/sr0", O_RDONLY|O_EXCL|O_NONBLOCK) = 3

Kay, do you know why [2] was done in the first place? Do you happen to
have a pointer to a bug etc. which describes the problems with CD
burning sessions?

Thanks,

Martin

[1] https://launchpad.net/bugs/554433
[2] http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=38a3cde11bc77af49a96245b8a8a0f2b583a344c
-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]