From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A68F8C83F19 for ; Mon, 28 Aug 2023 14:23:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231267AbjH1OWn (ORCPT ); Mon, 28 Aug 2023 10:22:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40572 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231808AbjH1OWb (ORCPT ); Mon, 28 Aug 2023 10:22:31 -0400 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6E341C7; Mon, 28 Aug 2023 07:22:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=9E44iiUNdZH1ZPxuMNvAhOTWH2tumtFNFWSYch117Sg=; b=nSz5L3dUuVsvh674z9OKAS8bJp zYSu+GQXXg9k+ExZpIBbHRWqabXZwd02n9vS97tlwdx5M9rbbC+J+KEnpZl7StHzVI1lt44f9QJWZ RhCLKSbzGCi4P76AWaT4yrVyFudAE8f1mHvZ/9LKJK5CDCAoQ07psSi8X80pfTQ2D+AXZbR9MC8+S wR1nAR5ReTWrG92vtaPega/Mum3q/1hkkMbL2GzcSxnC+t33sPMa720/D25kUK/+Hg62OBp9KLF6I aTXMdhkDY6yJQndP4Hyxm4zXDD+MmNGYu1+zD8ZvsnvzkuVZZ62wZGz7/VRA0T/x0Dhn8TItnvE/O R0TRfFaA==; Received: from hch by bombadil.infradead.org with local (Exim 4.96 #2 (Red Hat Linux)) id 1qad8H-009hsP-1H; Mon, 28 Aug 2023 14:22:21 +0000 Date: Mon, 28 Aug 2023 07:22:21 -0700 From: Christoph Hellwig To: Jan Kara Cc: Al Viro , linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org, Christoph Hellwig , Alasdair Kergon , Andrew Morton , Anna Schumaker , Chao Yu , Christian Borntraeger , "Darrick J. Wong" , Dave Kleikamp , David Sterba , dm-devel@redhat.com, drbd-dev@lists.linbit.com, Gao Xiang , Jack Wang , Jaegeuk Kim , jfs-discussion@lists.sourceforge.net, Joern Engel , Joseph Qi , Kent Overstreet , linux-bcache@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-erofs@lists.ozlabs.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-mm@kvack.org, linux-mtd@lists.infradead.org, linux-nfs@vger.kernel.org, linux-nilfs@vger.kernel.org, linux-nvme@lists.infradead.org, linux-pm@vger.kernel.org, linux-raid@vger.kernel.org, linux-s390@vger.kernel.org, linux-scsi@vger.kernel.org, linux-xfs@vger.kernel.org, "Md. Haris Iqbal" , Mike Snitzer , Minchan Kim , ocfs2-devel@oss.oracle.com, reiserfs-devel@vger.kernel.org, Sergey Senozhatsky , Song Liu , Sven Schnelle , target-devel@vger.kernel.org, Ted Tso , Trond Myklebust , xen-devel@lists.xenproject.org, Jens Axboe , Christian Brauner Subject: Re: [PATCH v2 0/29] block: Make blkdev_get_by_*() return handle Message-ID: References: <20230810171429.31759-1-jack@suse.cz> <20230825015843.GB95084@ZenIV> <20230825134756.o3wpq6bogndukn53@quack3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230825134756.o3wpq6bogndukn53@quack3> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Precedence: bulk List-ID: X-Mailing-List: linux-bcache@vger.kernel.org On Fri, Aug 25, 2023 at 03:47:56PM +0200, Jan Kara wrote: > I can see the appeal of not having to introduce the new bdev_handle type > and just using struct file which unifies in-kernel and userspace block > device opens. But I can see downsides too - the last fput() happening from > task work makes me a bit nervous whether it will not break something > somewhere with exclusive bdev opens. Getting from struct file to bdev is > somewhat harder but I guess a helper like F_BDEV() would solve that just > fine. > > So besides my last fput() worry about I think this could work and would be > probably a bit nicer than what I have. But before going and redoing the whole > series let me gather some more feedback so that we don't go back and forth. > Christoph, Christian, Jens, any opinion? I did think about the file a bit. The fact that we'd need something like an anon_file for the by_dev open was always a huge turn off for me, but maybe my concern is overblown. Having a struct file would actually be really useful for a bunch of users.