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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B17E8C433EF for ; Thu, 14 Oct 2021 09:53:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 95A3C6101E for ; Thu, 14 Oct 2021 09:53:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229984AbhJNJzR convert rfc822-to-8bit (ORCPT ); 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-bcache@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