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 X-Spam-Level: X-Spam-Status: No, score=-15.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 445C3C56201 for ; Wed, 25 Nov 2020 16:29:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CAA1920857 for ; Wed, 25 Nov 2020 16:29:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CAA1920857 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 482AE6B0070; Wed, 25 Nov 2020 11:29:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 40D6B6B0072; Wed, 25 Nov 2020 11:29:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2FBD36B0073; Wed, 25 Nov 2020 11:29:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0031.hostedemail.com [216.40.44.31]) by kanga.kvack.org (Postfix) with ESMTP id 1607F6B0070 for ; Wed, 25 Nov 2020 11:29:31 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id A9147363D for ; Wed, 25 Nov 2020 16:29:30 +0000 (UTC) X-FDA: 77523476100.30.boy77_600775327378 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin30.hostedemail.com (Postfix) with ESMTP id 87378180B3C83 for ; Wed, 25 Nov 2020 16:29:30 +0000 (UTC) X-HE-Tag: boy77_600775327378 X-Filterd-Recvd-Size: 3230 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Wed, 25 Nov 2020 16:29:29 +0000 (UTC) Received: by verein.lst.de (Postfix, from userid 2407) id 948AB68B02; Wed, 25 Nov 2020 17:29:26 +0100 (CET) Date: Wed, 25 Nov 2020 17:29:26 +0100 From: Christoph Hellwig To: Tejun Heo Cc: Christoph Hellwig , Jens Axboe , Josef Bacik , Konrad Rzeszutek Wilk , Coly Li , Mike Snitzer , Greg Kroah-Hartman , Jan Kara , Johannes Thumshirn , dm-devel@redhat.com, Richard Weinberger , Jan Kara , linux-block@vger.kernel.org, xen-devel@lists.xenproject.org, linux-bcache@vger.kernel.org, linux-mtd@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 23/45] block: remove i_bdev Message-ID: <20201125162926.GA1024@lst.de> References: <20201124132751.3747337-1-hch@lst.de> <20201124132751.3747337-24-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Nov 24, 2020 at 02:37:05PM -0500, Tejun Heo wrote: > On Tue, Nov 24, 2020 at 02:27:29PM +0100, Christoph Hellwig wrote: > > Switch the block device lookup interfaces to directly work with a dev_t > > so that struct block_device references are only acquired by the > > blkdev_get variants (and the blk-cgroup special case). This means that > > we not don't need an extra reference in the inode and can generally > ^ > now > > simplify handling of struct block_device to keep the lookups contained > > in the core block layer code. > > > > Signed-off-by: Christoph Hellwig > ... > > @@ -1689,14 +1599,12 @@ static int blkdev_open(struct inode * inode, struct file * filp) > > if ((filp->f_flags & O_ACCMODE) == 3) > > filp->f_mode |= FMODE_WRITE_IOCTL; > > > > - bdev = bd_acquire(inode); > > - if (bdev == NULL) > > - return -ENOMEM; > > - > > + bdev = blkdev_get_by_dev(inode->i_rdev, filp->f_mode, filp); > > + if (IS_ERR(bdev)) > > + return PTR_ERR(bdev); > > filp->f_mapping = bdev->bd_inode->i_mapping; > > filp->f_wb_err = filemap_sample_wb_err(filp->f_mapping); > > - > > - return blkdev_get(bdev, filp->f_mode, filp); > > + return 0; > > } > > I was wondering whether losing the stale bdev flushing in bd_acquire() would > cause user-visible behavior changes but can't see how it would given that > userland has no way of holding onto a specific instance of block inode. > Maybe it's something worth mentioning in the commit message? With stale bdev flushing do you mean the call to bd_forget if i_bdev exists but is unhashed? It doesn't actually flush anything but just detaches the old bdev from the inode so that the new one can be attached. That problem goes away by definition if we don't attach the bdev to the inode.