Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp3027876ybc; Thu, 21 Nov 2019 02:09:53 -0800 (PST) X-Google-Smtp-Source: APXvYqxIhRA+ltqioSRfaBMsq3X/yxwXl1akoOqZq1adHG5cGmj/8Pqglm4SUeeB2+qZA7Evfdct X-Received: by 2002:a17:907:206d:: with SMTP id qp13mr12319098ejb.92.1574330993819; Thu, 21 Nov 2019 02:09:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574330993; cv=none; d=google.com; s=arc-20160816; b=ipNj4Gdxc5jP8S8bONtgsTLohy1qjDqJAJNIrVY5qLT/LZeXdF6QbEva04uQ7PKQE9 lrgjer7DAluJrWDu0KEuDxsYVDTDOkcOorGQQsWvpz7/TYdX1z9r9NS7r1ls3x4xFCZQ Gpn8NLQjWwyPByakEt9j2Pl4rJN9CRbdF7g63zy5a+/6Zk+uf7zSO0CyWn/dvDnNdXvN Gfj90T6p5eGOcgbnTYTS61973HcqvEb/BUSPSYQFiVVklREGUNuEil2K4nCi2FzgjRvJ MyKDTxlAn10caDcLlt5c1ELC7igNUQurNSD/FFzDf8rVVoVdKjVVDGkznHXQkXJEsIKy SCug== 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=HzYwsXN1dv4PyhEUs7n5Twrn/SYrCsgo5lgcd6lmWNM=; b=0C6kMjXbVUu+/vGU34WS0mZV2oKk0sAoWRlg7XEgkcD8ZgU2HNs7+8JNMOGTOeq2vf ib0Vgc0N36lBAAC+2BD4E+vew9o7faZB4IJ0fib/o6dWU6ppghawz7MoMPsNwapijGaF E30QHwT3Pw2YoYwjhCRcnnYfHfCjkhr5BQBPaYsoj+4i6uT/y8r6Hlo+5yKEO3SQKWU0 PNpfEYy1kbanaZBBOZD9TuyGOiHy60RHuoGSP1dVMQ+QdueaumWSgmuyRMgB7IhVZ8yo 2fvy/C+GqA8ouoEtalSq2hqGlI6IHSUr8VOraMDoY/yXrEg93wAUjpfVEjWVb7zVbw9f iZFQ== 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 35si2413630edj.185.2019.11.21.02.09.29; Thu, 21 Nov 2019 02:09:53 -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 S1726722AbfKUKGS (ORCPT + 99 others); Thu, 21 Nov 2019 05:06:18 -0500 Received: from mx2.suse.de ([195.135.220.15]:49890 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726014AbfKUKGS (ORCPT ); Thu, 21 Nov 2019 05:06:18 -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 38FAEADC8; Thu, 21 Nov 2019 10:06:16 +0000 (UTC) Date: Thu, 21 Nov 2019 11:06:14 +0100 From: Michal =?iso-8859-1?Q?Such=E1nek?= To: Christoph Hellwig Cc: linux-scsi@vger.kernel.org, Matthew Wilcox , "Ewan D. Milne" , Jonathan Corbet , Jens Axboe , "James E.J. Bottomley" , "Martin K. Petersen" , Alexander Viro , "J. Bruce Fields" , Mauro Carvalho Chehab , Eric Biggers , Benjamin Coddington , Hannes Reinecke , Omar Sandoval , Ming Lei , Damien Le Moal , Bart Van Assche , Tejun Heo , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v3 5/7] bdev: add open_finish. Message-ID: <20191121100614.GH11661@kitsune.suse.cz> References: <31f640791d9cc20cdbbb3000dfcf8370cf3c6223.1572002144.git.msuchanek@suse.de> <20191105001727.GA29826@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191105001727.GA29826@infradead.org> 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 Mon, Nov 04, 2019 at 04:17:27PM -0800, Christoph Hellwig wrote: > Please make sure you CC linux-block if you add block device ops. > > On Fri, Oct 25, 2019 at 01:21:42PM +0200, Michal Suchanek wrote: > > Opening a block device may require a long operation such as waiting for > > the cdrom tray to close. Performing this operation with locks held locks > > out other attempts to open the device. These processes waiting to open > > the device are not killable. > > > > To avoid this issue and still be able to perform time-consuming checks > > at open() time the block device driver can provide open_finish(). If it > > does opening the device proceeds even when an error is returned from > > open(), bd_mutex is released and open_finish() is called. If > > open_finish() succeeds the device is now open, if it fails release() is > > called. > > > > When -ERESTARTSYS is returned from open() blkdev_get may loop without > > calling open_finish(). On -ERESTARTSYS open_finish() is not called. > > > > Move a ret = 0 assignment up in the if/else branching to avoid returning > > -ENXIO. Previously the return value was ignored on the unhandled branch. > > Still a complete nack for splitting a fundamental operation over two > ops, especially just for working around a piece of buggy software. Still did not provide an awesome alternative that does not sneed splitting the operation. What is it, specifically? Thanks Michal