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: <1284507516.4963.2.camel@maxim-laptop>
Date:	Wed, 15 Sep 2010 01:38:35 +0200
From:	Maxim Levitsky <maximlevitsky@...il.com>
To:	Kay Sievers <kay.sievers@...y.org>
Cc:	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-14 at 10:07 +0200, Kay Sievers wrote: 
> On Tue, Sep 14, 2010 at 09:39, Tejun Heo <tj@...nel.org> wrote:
> > On 09/14/2010 03:27 AM, Maxim Levitsky wrote:
> >>> However 2.6.36 doesn't detect that removal.
> >>> According to udevadm monitor --property no uevents are send on removal.
> >> Correction, this is regression between 2.6.34 and 2.6.35. This shows how
> >> much I use cd these days...
> >>
> >> I bisected it down to this:
> >>
> >> 6b4517a7913a09d3259bb1d21c9cb300f12294bd is the first bad commit
> >> commit 6b4517a7913a09d3259bb1d21c9cb300f12294bd
> >> Author: Tejun Heo <tj@...nel.org>
> >> Date:   Wed Apr 7 18:53:59 2010 +0900
> >>
> >>     block: implement bd_claiming and claiming block
> >
> > Hmmm... weird.  This commit does change the open behavior but
> > shouldn't change the end result.  Can someone please enlighten me how
> > udevadm is interacting with the device at system call level?
> 
> Not at all. Udev does not really touch it.
> 
> The cdrom drive isn't unlocked on usual systems, udisks polls the
> cdrom drive periodically just like HAL did. The only difference is
> that with the polling, the sr driver detects a media change and sends
> a uevent to udev, instead of HAL looking at the result of the open().
> 
> Are we sure, that there is something that still polls the drive?
> Udisks is only auto-started, when the desktop calls into some D-Bus
> methods, unlike HAL where it was an init script.


Note that on current vanilla head, I applied the attached manual revert
patch, and problem disappears (and probably introduces the same bug that
patch supposed to fix).


Best regards,
Maxim Levitsky

View attachment "test.patch" of type "text/x-patch" (2662 bytes)