Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp4655483ybc; Tue, 26 Nov 2019 12:24:29 -0800 (PST) X-Google-Smtp-Source: APXvYqxfcr2gDez6uLTQX1t5uOoUG+mKCcMDaBjDACx08ekqvJZ5UkIkTzYzMB822TevftP87oYE X-Received: by 2002:a05:6402:1299:: with SMTP id w25mr27657415edv.10.1574799869224; Tue, 26 Nov 2019 12:24:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574799869; cv=none; d=google.com; s=arc-20160816; b=dR7gK+DTjfJRIZ5gF1sN9K8DDDrsA4XRyTiEsImS9Z5PxnD6OuPOIJAmmGeFW1HQSa M2PrQ4gnMjbx05ZIbJKLX9+wdujF/pFymNf9fete2bYfZdasott99p6adRn7UReBD8v5 Pl2v6WQLEMIEy5rBpbFUaN1Y/TfSpWKkDdhOoAFuohjph/jBfpg8pXCbvVhHT7wZ4Bfo i8AmpqcENRQogPNaCHUaWauz3YIyI5EQZzi07UdV+4St7Wq9wzzx/LoodbVmCXFcN5Bd mi5f4WWVtQeKybgvxEIhhVysxEfRVLCQ8xTKbGB0SOvNciEPvY1/+gqdDohOHvB3dwAT sTsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=06nhDbgP0pYgdnBIsewY5xLi+wT19EKfVEeUYpa0wWs=; b=nCpNRjRWTvJMm90swS1Rag7imA9tPjuPfFN3QkL6TAocYLmtLZhlG8q+4bD7hFv6ra N4053P7EYzXyminfm2YvKStIKs0Hf1R0VhTugjvwWEpHoBuOQwwDFcPCMgFFD/P0A4+w HJTUBY540Laoiq+2h4S0AhqDqLntoeGgce3vDzw3qaJSbSLVcaZfiRbctlv4UAUkrMlL 4Tp3wxOAm9ji59wm4avC7x1tq+e0cZj5wuyFz4oolbRiW5t1Jw4yYT/bPQ0wsFSvIhl8 dDWjGgx2FBZdL8u7DFO2jAUrQMJzfYroYCf/ExVjjTe2+XPchMEmr1Q4dMhL6yvh+Vf4 wWeA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o22si8367561edv.175.2019.11.26.12.24.04; Tue, 26 Nov 2019 12:24:29 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727073AbfKZUV4 (ORCPT + 99 others); Tue, 26 Nov 2019 15:21:56 -0500 Received: from mx2.suse.de ([195.135.220.15]:52240 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726036AbfKZUV4 (ORCPT ); Tue, 26 Nov 2019 15:21:56 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id D5F01B147; Tue, 26 Nov 2019 20:21:53 +0000 (UTC) Date: Tue, 26 Nov 2019 21:21:51 +0100 From: Michal =?iso-8859-1?Q?Such=E1nek?= To: Jens Axboe Cc: linux-scsi@vger.kernel.org, linux-block@vger.kernel.org, Jonathan Corbet , "James E.J. Bottomley" , "Martin K. Petersen" , Alexander Viro , Eric Biggers , "J. Bruce Fields" , Mauro Carvalho Chehab , Benjamin Coddington , Ming Lei , Chaitanya Kulkarni , Bart Van Assche , Damien Le Moal , Hou Tao , Pavel Begunkov , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Jan Kara , Hannes Reinecke , "Ewan D. Milne" , Christoph Hellwig , Matthew Wilcox Subject: Re: [PATCH v4 rebase 00/10] Fix cdrom autoclose Message-ID: <20191126202151.GY11661@kitsune.suse.cz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 26, 2019 at 01:01:42PM -0700, Jens Axboe wrote: > On 11/26/19 12:54 PM, Michal Suchanek wrote: > > Hello, > > > > there is cdrom autoclose feature that is supposed to close the tray, > > wait for the disc to become ready, and then open the device. > > > > This used to work in ancient times. Then in old times there was a hack > > in util-linux which worked around the breakage which probably resulted > > from switching to scsi emulation. > > > > Currently util-linux maintainer refuses to merge another hack on the > > basis that kernel still has the feature so it should be fixed there. > > The code needs not be replicated in every userspace utility like mount > > or dd which has no business knowing which devices are CD-roms and where > > the autoclose setting is in the kernel. > > > > This is rebase on top of current master. > > > > Also it seems that most people think that this is fix for WMware because > > there is one patch dealing with WMware. > > I think the main complaint with this is that it's kind of a stretch to > add core functionality for a device type that's barely being > manufactured anymore and is mostly used in a virtualized fashion. I > think it you could fix this without 10 patches of churn and without > adding a new ->open() addition to fops, then people would be a lot more > receptive to the idea of improving cdrom auto-close. I see no way to do that cleanly. There are two open modes for cdrom devices - blocking and non-blocking. In blocking mode open() should analyze the medium so that it's ready when it returns. In non-blocking mode it should return immediately so long as you can talk to the device. When waiting in open() with locks held the processes trying to open the device are locked out regradless of the mode they use. The only way to solve this is to pretend that the device is open and do the wait afterwards with the device unlocked. Thanks Michal