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=-10.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,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 B8411C63777 for ; Fri, 20 Nov 2020 09:01:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 448B022255 for ; Fri, 20 Nov 2020 09:01:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 448B022255 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 86E5E6B0068; Fri, 20 Nov 2020 04:01:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 81EA26B006C; Fri, 20 Nov 2020 04:01:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 733C76B006E; Fri, 20 Nov 2020 04:01:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0148.hostedemail.com [216.40.44.148]) by kanga.kvack.org (Postfix) with ESMTP id 38C986B0068 for ; Fri, 20 Nov 2020 04:01:46 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id BB0B4824999B for ; Fri, 20 Nov 2020 09:01:45 +0000 (UTC) X-FDA: 77504203770.21.need32_35040d12734a Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin21.hostedemail.com (Postfix) with ESMTP id 9DA981803671B for ; Fri, 20 Nov 2020 09:01:45 +0000 (UTC) X-HE-Tag: need32_35040d12734a X-Filterd-Recvd-Size: 2682 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf22.hostedemail.com (Postfix) with ESMTP for ; Fri, 20 Nov 2020 09:01:45 +0000 (UTC) Received: by verein.lst.de (Postfix, from userid 2407) id 4C98067373; Fri, 20 Nov 2020 10:01:42 +0100 (CET) Date: Fri, 20 Nov 2020 10:01:42 +0100 From: Christoph Hellwig To: Jan Kara Cc: Christoph Hellwig , Jens Axboe , Tejun Heo , Josef Bacik , Konrad Rzeszutek Wilk , Coly Li , Mike Snitzer , 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 13/20] block: remove ->bd_contains Message-ID: <20201120090142.GC21715@lst.de> References: <20201118084800.2339180-1-hch@lst.de> <20201118084800.2339180-14-hch@lst.de> <20201119103253.GV1981@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201119103253.GV1981@quack2.suse.cz> 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 Thu, Nov 19, 2020 at 11:32:53AM +0100, Jan Kara wrote: > > @@ -1521,7 +1510,7 @@ static int __blkdev_get(struct block_device *bdev, fmode_t mode, void *holder, > > if (bdev->bd_bdi == &noop_backing_dev_info) > > bdev->bd_bdi = bdi_get(disk->queue->backing_dev_info); > > } else { > > - if (bdev->bd_contains == bdev) { > > + if (!bdev->bd_partno) { > > This should be !bdev_is_partition(bdev) for consistency, right? Yes. Same for the same check further up for the !bdev->bd_openers case. > > +#define bdev_whole(_bdev) \ > > + ((_bdev)->bd_disk->part0.bdev) > > + > > #define bdev_kobj(_bdev) \ > > (&part_to_dev((_bdev)->bd_part)->kobj) > > I'd somewhat prefer if these helpers could actually be inline functions and > not macros. I guess they are macros because hd_struct isn't in blk_types.h. > But if we moved helpers to blkdev.h, we'd have all definitions we need... > Is that a problem for some users? As you pointed out the reason these are macros is that the obvious placement doesn't work. My plan was to look into cleaning up the block headers, which are a complete mess between blk_types.h, bio.h, blkdev.h and genhd.h after I'm done making sense of the data structures, so for now I didn't want to move too much around. Hopefully we'll be able to convert these helpers to inlines once I'm done.