From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753949Ab0IVNvy (ORCPT ); Wed, 22 Sep 2010 09:51:54 -0400 Received: from mail-fx0-f46.google.com ([209.85.161.46]:34382 "EHLO mail-fx0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752543Ab0IVNvw (ORCPT ); Wed, 22 Sep 2010 09:51:52 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=RrpH29QgjnENEHwd3JUYN0dUmWLdND4l9x+XRZTbn0Rdn7vcakRoDWOk0kFk4AImPH F8Qp50rqm2ssJ/iteBu32JPDsoXhrxe7IdbjCcfK8dtJJCmUlNeNzfR0JdfbBnRIeNbi jsxYS+frSjImeqrb32V6c/Q8rwVnO4+3x1FJ4= Subject: Re: [REGRESSION] cdrom drive doesn't detect removal From: Maxim Levitsky To: Tejun Heo Cc: Kay Sievers , Henrique de Moraes Holschuh , linux-kernel , Jens Axboe In-Reply-To: <4C99B25D.20805@kernel.org> 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> <4C99B25D.20805@kernel.org> Content-Type: text/plain; charset="UTF-8" Date: Wed, 22 Sep 2010 15:41:40 +0200 Message-ID: <1285162900.3335.15.camel@maxim-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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