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 6A69FC63777 for ; Fri, 20 Nov 2020 09:02:07 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9B1A52224C for ; Fri, 20 Nov 2020 09:02:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9B1A52224C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: mail.kernel.org; spf=tempfail smtp.mailfrom=dm-devel-bounces@redhat.com Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-300-Iaei6A_9Mfq0uPg95gDXCA-1; Fri, 20 Nov 2020 04:02:03 -0500 X-MC-Unique: Iaei6A_9Mfq0uPg95gDXCA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B748B1005D5A; Fri, 20 Nov 2020 09:01:58 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 85EF619D9B; Fri, 20 Nov 2020 09:01:58 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 28C2A4BB7B; Fri, 20 Nov 2020 09:01:58 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 0AK91tQO018670 for ; Fri, 20 Nov 2020 04:01:55 -0500 Received: by smtp.corp.redhat.com (Postfix) id A66272166B2C; Fri, 20 Nov 2020 09:01:55 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast04.extmail.prod.ext.rdu2.redhat.com [10.11.55.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A188A2166B2B for ; Fri, 20 Nov 2020 09:01:50 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 0D533103B802 for ; Fri, 20 Nov 2020 09:01:50 +0000 (UTC) Received: from verein.lst.de (verein.lst.de [213.95.11.211]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-487-vMGHz0cLN6SfSoFQteU9dw-1; Fri, 20 Nov 2020 04:01:45 -0500 X-MC-Unique: vMGHz0cLN6SfSoFQteU9dw-1 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 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 In-Reply-To: <20201119103253.GV1981@quack2.suse.cz> User-Agent: Mutt/1.5.17 (2007-11-01) X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-loop: dm-devel@redhat.com Cc: Jens Axboe , Mike Snitzer , Konrad Rzeszutek Wilk , Richard Weinberger , Josef Bacik , Coly Li , linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, dm-devel@redhat.com, linux-mtd@lists.infradead.org, linux-mm@kvack.org, Jan Kara , Tejun Heo , xen-devel@lists.xenproject.org, linux-bcache@vger.kernel.org, Christoph Hellwig Subject: Re: [dm-devel] [PATCH 13/20] block: remove ->bd_contains X-BeenThere: dm-devel@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: device-mapper development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dm-devel-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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. -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel 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=unavailable 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 4FF3BC63798 for ; Fri, 20 Nov 2020 09:01:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0029822255 for ; Fri, 20 Nov 2020 09:01:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727311AbgKTJBr (ORCPT ); Fri, 20 Nov 2020 04:01:47 -0500 Received: from verein.lst.de ([213.95.11.211]:42034 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727286AbgKTJBq (ORCPT ); Fri, 20 Nov 2020 04:01:46 -0500 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) Precedence: bulk List-ID: X-Mailing-List: linux-bcache@vger.kernel.org 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. 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,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,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 CD532C63777 for ; Fri, 20 Nov 2020 09:02:15 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 54B312224C for ; Fri, 20 Nov 2020 09:02:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="wIcIFu2+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 54B312224C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Fl4xbKWFvveTPoG3/66xhYW58wUqTCs9Rak3kS2l4Tc=; b=wIcIFu2+uTeSPDHuhna8h10Hw IOOIZpXE0WL7/2yk0lB6RQ1k1dkm7/mkCn91i31D/+k1GRQy3lV9kPpBdh8QatFv4e4YgGcYju7qm vwaR4R+s5aY7S+Se9on+vU4Xo4hpvx4WLIo6uaHqodTiwNA9PZpokE570u0xprBNiMKSt02UyHPXi gEfK7ywTDw/CDtBwKD21ZMcchicOiIT7F2NYc0H9381zGMAWE4tNHN1den1BPnhipBdPJVWqzRZEf z6M8RItfA062GLron5gYd6vlq7U3jNbVyuIoZa938dBYdbMuCZ7+xW4PKMT/otlpwEhdIdlrOhSKO QN0NeLN8A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kg2Id-0003hV-VK; Fri, 20 Nov 2020 09:01:48 +0000 Received: from verein.lst.de ([213.95.11.211]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kg2Ia-0003gc-OX for linux-mtd@lists.infradead.org; Fri, 20 Nov 2020 09:01:45 +0000 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 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-Disposition: inline In-Reply-To: <20201119103253.GV1981@quack2.suse.cz> User-Agent: Mutt/1.5.17 (2007-11-01) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201120_040144_953541_F2F6B468 X-CRM114-Status: GOOD ( 16.44 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jens Axboe , Mike Snitzer , Konrad Rzeszutek Wilk , Richard Weinberger , Josef Bacik , Coly Li , linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, dm-devel@redhat.com, linux-mtd@lists.infradead.org, linux-mm@kvack.org, Jan Kara , Tejun Heo , xen-devel@lists.xenproject.org, linux-bcache@vger.kernel.org, Christoph Hellwig Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org 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. ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/