Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp4316992pxb; Thu, 14 Oct 2021 02:53:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwl73jYQrkxFSHyfcqcgtV9xM1PLSPQk86JquJalUB+b3l7y5++1RE+2Vgr7rA3UYNEcG2b X-Received: by 2002:a50:a2a5:: with SMTP id 34mr7348592edm.180.1634205230138; Thu, 14 Oct 2021 02:53:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634205230; cv=none; d=google.com; s=arc-20160816; b=hGgJze5c1hhuIjNEinUl9KOQ24DpGpiuJDnMUsD9DBRjIa37vEc6Yv592keHV5qVch J9oAKZHVQncJcnDKr+3t8xJ27paVQ11+0ifZvBy3tIgFSjMJ4u5BuAqP3xbKP+Ova68Y lFemB8ZN1SykkkTupsv2f/CaplPdDu8ghjwJHYtP/GTrgeknFhif6BTuDfgGfI4Hk5Rj HNFS5K9WKIVbS9Ppz27GSsYIMX8GuAwfkyfrwPCa77OUmkDaqCAyhjazDSt8GmBJDNnK TeatRv0cII0SHHpiknJA3SmFW3QZaayO3uL2gUC87jv4egRCHY7OJcc1iQTaNvyfcVv7 2O7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:content-transfer-encoding :content-id:content-language:accept-language:in-reply-to:references :message-id:date:thread-index:thread-topic:subject:cc:to:from; bh=2a3X1LkrU1JGDY0vox97GeX0Sp+NA4/GolX7mW/5vso=; b=NtCeFuKDSuEED26PmIaxzJXnsW1IGF6b4gPj+Fuz81Nw6ctAghyfuVMwc0yEo+gmzF taF1kiDzgbRw4sqlmQA+xuYYUM6xR8SWP80eXrKaS8VAC/a7OTBTj45VFO4Kca14hFqK eqV7SxaPAMqJdgGxifN+LlXsnRRyj/OVjY93itPpqbo72f+xD+xcURyq8Lqu5JupFhlM UOELgt726+Xqg7E6gvCiKAoLp9bcurshfQgtGw7v9dxGukhfCrdyDjZZCBFWbCFOBopn jjdAvAqpgtwGAop8UGkMLkKmWL8E+MYIia75JVRqrxrgGweI2Um/Ii0Qgfi5fSKWT1/y fkLw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id sd37si4133923ejc.13.2021.10.14.02.53.15; Thu, 14 Oct 2021 02:53:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230051AbhJNJzR convert rfc822-to-8bit (ORCPT + 99 others); Thu, 14 Oct 2021 05:55:17 -0400 Received: from mgw-01.mpynet.fi ([82.197.21.90]:60924 "EHLO mgw-01.mpynet.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229468AbhJNJzQ (ORCPT ); Thu, 14 Oct 2021 05:55:16 -0400 X-Greylist: delayed 1139 seconds by postgrey-1.27 at vger.kernel.org; Thu, 14 Oct 2021 05:55:13 EDT Received: from pps.filterd (mgw-01.mpynet.fi [127.0.0.1]) by mgw-01.mpynet.fi (8.16.0.43/8.16.0.43) with SMTP id 19E9Pj42091529; Thu, 14 Oct 2021 12:32:59 +0300 Received: from ex13.tuxera.com (ex13.tuxera.com [178.16.184.72]) by mgw-01.mpynet.fi with ESMTP id 3bphjf80v4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 14 Oct 2021 12:32:59 +0300 Received: from tuxera-exch.ad.tuxera.com (10.20.48.11) by tuxera-exch.ad.tuxera.com (10.20.48.11) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Thu, 14 Oct 2021 12:32:59 +0300 Received: from tuxera-exch.ad.tuxera.com ([fe80::552a:f9f0:68c3:d789]) by tuxera-exch.ad.tuxera.com ([fe80::552a:f9f0:68c3:d789%12]) with mapi id 15.00.1497.023; Thu, 14 Oct 2021 12:32:59 +0300 From: Anton Altaparmakov To: Christoph Hellwig CC: Jens Axboe , Coly Li , Mike Snitzer , Song Liu , David Sterba , Josef Bacik , Theodore Ts'o , OGAWA Hirofumi , Dave Kleikamp , Ryusuke Konishi , "Konstantin Komarov" , Kees Cook , Phillip Lougher , Jan Kara , "linux-block@vger.kernel.org" , "dm-devel@redhat.com" , "drbd-dev@lists.linbit.com" , "linux-bcache@vger.kernel.org" , "linux-raid@vger.kernel.org" , "linux-mtd@lists.infradead.org" , "linux-nvme@lists.infradead.org" , "linux-scsi@vger.kernel.org" , "target-devel@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-btrfs@vger.kernel.org" , "linux-ext4@vger.kernel.org" , "jfs-discussion@lists.sourceforge.net" , "linux-nfs@vger.kernel.org" , "linux-nilfs@vger.kernel.org" , "linux-ntfs-dev@lists.sourceforge.net" , "ntfs3@lists.linux.dev" , "reiserfs-devel@vger.kernel.org" Subject: Re: don't use ->bd_inode to access the block device size Thread-Topic: don't use ->bd_inode to access the block device size Thread-Index: AQHXv/D8RnQWsWSgAkyxOdAYku+41KvR10wAgAAzeIA= Date: Thu, 14 Oct 2021 09:32:58 +0000 Message-ID: <3AB8052D-DD45-478B-85F2-BFBEC1C7E9DF@tuxera.com> References: <20211013051042.1065752-1-hch@lst.de> <20211014062844.GA25448@lst.de> In-Reply-To: <20211014062844.GA25448@lst.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [109.154.241.177] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Proofpoint-ORIG-GUID: itBrsNbhZ2FR6MA_DlXhPV1L0UjW3zcs X-Proofpoint-GUID: itBrsNbhZ2FR6MA_DlXhPV1L0UjW3zcs X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425,18.0.790 definitions=2021-10-14_02:2021-10-14,2021-10-14 signatures=0 X-Proofpoint-Spam-Details: rule=mpy_notspam policy=mpy score=0 spamscore=0 mlxlogscore=453 bulkscore=0 malwarescore=0 phishscore=0 mlxscore=0 adultscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110140057 Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Hi Christoph, > On 14 Oct 2021, at 07:28, Christoph Hellwig wrote: > > On Wed, Oct 13, 2021 at 07:10:13AM +0200, Christoph Hellwig wrote: >> I wondered about adding a helper for looking at the size in byte units >> to avoid the SECTOR_SHIFT shifts in various places. But given that >> I could not come up with a good name and block devices fundamentally >> work in sector size granularity I decided against that. > > So it seems like the biggest review feedback is that we should have > such a helper. I think the bdev_size name is the worst as size does > not imply a particular unit. bdev_nr_bytes is a little better but I'm > not too happy. Any other suggestions or strong opinions? bdev_byte_size() would seem to address your concerns? bdev_nr_bytes() would work though - it is analogous to bdev_nr_sectors() after all. No strong opinion here but I do agree with you that bdev_size() is a bad choice for sure. It is bound to cause bugs down the line when people forget what unit it is in. Best regards, Anton -- Anton Altaparmakov (replace at with @) Lead in File System Development, Tuxera Inc., http://www.tuxera.com/ Linux NTFS maintainer