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=-13.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 7AFC1C63777 for ; Tue, 24 Nov 2020 19:37:31 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C859720C56 for ; Tue, 24 Nov 2020 19:37:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="F5LkT6+P" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C859720C56 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D15C26B006E; Tue, 24 Nov 2020 14:37:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CC7056B0070; Tue, 24 Nov 2020 14:37:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BB4646B0071; Tue, 24 Nov 2020 14:37:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0134.hostedemail.com [216.40.44.134]) by kanga.kvack.org (Postfix) with ESMTP id A207D6B006E for ; Tue, 24 Nov 2020 14:37:29 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 5EDA43635 for ; Tue, 24 Nov 2020 19:37:29 +0000 (UTC) X-FDA: 77520321018.28.ghost26_5b0c48d27370 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin28.hostedemail.com (Postfix) with ESMTP id 2C5C76D6E for ; Tue, 24 Nov 2020 19:37:29 +0000 (UTC) X-HE-Tag: ghost26_5b0c48d27370 X-Filterd-Recvd-Size: 4941 Received: from mail-qt1-f193.google.com (mail-qt1-f193.google.com [209.85.160.193]) by imf19.hostedemail.com (Postfix) with ESMTP for ; Tue, 24 Nov 2020 19:37:28 +0000 (UTC) Received: by mail-qt1-f193.google.com with SMTP id f15so13481033qto.13 for ; Tue, 24 Nov 2020 11:37:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=MOALJb5ZWPUh3aGAOfM0OVshborSGP7hJGfOxgGOGv8=; b=F5LkT6+P6W0m+3hlLX1OTdLAaWDWNPd5qU0zVXgoS6irqhQG1KPClCgLDacxdrz201 tuSkOD3Pi7npw/jwH1Nvh11d7rq8LRNxgjQNm41OqnMYV7uCJqaXEwyai41Uj47dAbX3 JK7du1QUlRFM6taLlQQ447SfHtDJsH8zezvU1GOUPlebgL174F6/7EsV7OtuCUoF3f9x Bkfc9gd/0KWs5FVV7usVufNl9+blVTvGwiyUy7osMlVAVbdFXgSTZohKeNl02jc4WQz4 A0OAp0Qtsho7RAxf4m3roj9E2ZLkZ4zwUy7kn8kRWPQltha8Qf/YzRNO/2ELqU44tB/d HyAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=MOALJb5ZWPUh3aGAOfM0OVshborSGP7hJGfOxgGOGv8=; b=OYOi+RtnCanzxmL5bp/ceMOhwmcJMc8ZDWI57N5W72sApnSMO5ZYCax3Yrr1YYxdYG WtxAdh57Yn8cKLUkNIAvIhqKKcQfEGWmEnYoT0A8b7kuq3GpKPfe80sbEEzI3/deMsAX KjOnlz3gabil38LHL0KcFcfT0lf0BSlJBsBNNiN5KgHyC+LUXIjGXXGALxVmNlgo7seS A8M9DRdcCnxhZiD6EpmXR8w5z3tQJohDjJHZEL6iPTY4xdmjWFF7Ey3mwjfzua5Mhnnf ssimVGDgTsX/rO7LQZnIeLffKctwkGThKp9HrVBbjs5bBp+sCs90CORvHjjWH3ULgfvW yZVQ== X-Gm-Message-State: AOAM530HKmMdBQa0Ok/L/14+0ryIe73mrlitg+nBnO/MKnKPMZf3VwVw eCn4MWmKA+/0B1wnHoOhAl4= X-Google-Smtp-Source: ABdhPJybxY5/E0+KDq94c9P/N9IKjFDU+Ct8NW6WiHsGOrtJ7iW5aHJE2Msrh+VJOHLo1ru6UJnxSg== X-Received: by 2002:ac8:7192:: with SMTP id w18mr6129290qto.149.1606246647881; Tue, 24 Nov 2020 11:37:27 -0800 (PST) Received: from localhost (dhcp-6c-ae-f6-dc-d8-61.cpe.echoes.net. [72.28.8.195]) by smtp.gmail.com with ESMTPSA id t126sm68819qkh.133.2020.11.24.11.37.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Nov 2020 11:37:27 -0800 (PST) Date: Tue, 24 Nov 2020 14:37:05 -0500 From: Tejun Heo To: Christoph Hellwig Cc: 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: 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: <20201124132751.3747337-24-hch@lst.de> 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: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? Other than that, for the block part: Acked-by: Tejun Heo Thanks. -- tejun