From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753240Ab0IVHgf (ORCPT ); Wed, 22 Sep 2010 03:36:35 -0400 Received: from hera.kernel.org ([140.211.167.34]:52125 "EHLO hera.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753016Ab0IVHge (ORCPT ); Wed, 22 Sep 2010 03:36:34 -0400 Message-ID: <4C99B25D.20805@kernel.org> Date: Wed, 22 Sep 2010 09:38:05 +0200 From: Tejun Heo User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Maxim Levitsky CC: Kay Sievers , Henrique de Moraes Holschuh , linux-kernel , Jens Axboe Subject: Re: [REGRESSION] cdrom drive doesn't detect removal References: <1284284969.2928.18.camel@maxim-laptop> <1284427621.4127.7.camel@maxim-laptop> <4C8F2699.3020509@kernel.org> <1284507516.4963.2.camel@maxim-laptop> <1284511071.3551.1.camel@maxim-laptop> <20100915132731.GA20558@khazad-dum.debian.net> <1284589207.4672.3.camel@maxim-laptop> <1285069338.3124.4.camel@maxim-laptop> <1285110590.2822.9.camel@maxim-laptop> In-Reply-To: <1285110590.2822.9.camel@maxim-laptop> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (hera.kernel.org [127.0.0.1]); Wed, 22 Sep 2010 07:36:27 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? Thanks. -- tejun