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=-15.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,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 6B05AC388F9 for ; Thu, 19 Nov 2020 12:05:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B0E732469D for ; Thu, 19 Nov 2020 12:05:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B0E732469D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id DA91F6B0068; Thu, 19 Nov 2020 07:05:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D59AD6B006E; Thu, 19 Nov 2020 07:05:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C6F516B0070; Thu, 19 Nov 2020 07:05:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0125.hostedemail.com [216.40.44.125]) by kanga.kvack.org (Postfix) with ESMTP id 974A36B0068 for ; Thu, 19 Nov 2020 07:05:28 -0500 (EST) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 2E088824999B for ; Thu, 19 Nov 2020 12:05:28 +0000 (UTC) X-FDA: 77501037936.19.ghost70_540dd5827342 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin19.hostedemail.com (Postfix) with ESMTP id 0DE271ACEA4 for ; Thu, 19 Nov 2020 12:05:28 +0000 (UTC) X-HE-Tag: ghost70_540dd5827342 X-Filterd-Recvd-Size: 5665 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Thu, 19 Nov 2020 12:05:27 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id E1DC2AA4F; Thu, 19 Nov 2020 12:05:25 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 4E3FB1E130B; Thu, 19 Nov 2020 13:05:25 +0100 (CET) Date: Thu, 19 Nov 2020 13:05:25 +0100 From: Jan Kara To: Christoph Hellwig Cc: 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 14/20] block: remove the nr_sects field in struct hd_struct Message-ID: <20201119120525.GW1981@quack2.suse.cz> References: <20201118084800.2339180-1-hch@lst.de> <20201118084800.2339180-15-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201118084800.2339180-15-hch@lst.de> User-Agent: Mutt/1.10.1 (2018-07-13) 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 Wed 18-11-20 09:47:54, Christoph Hellwig wrote: > Now that the hd_struct always has a block device attached to it, there is > no need for having two size field that just get out of sync. > > Additional the field in hd_struct did not use proper serializiation, > possibly allowing for torn writes. By only using the block_device field > this problem also gets fixed. > > Signed-off-by: Christoph Hellwig Overall the patch looks good but I have a couple of comments below. > diff --git a/block/bio.c b/block/bio.c > index fa01bef35bb1fe..0c5269997434d6 100644 > --- a/block/bio.c > +++ b/block/bio.c > @@ -613,7 +613,7 @@ void guard_bio_eod(struct bio *bio) > rcu_read_lock(); > part = __disk_get_part(bio->bi_disk, bio->bi_partno); > if (part) > - maxsector = part_nr_sects_read(part); > + maxsector = bdev_nr_sectors(part->bdev); > else > maxsector = get_capacity(bio->bi_disk); I have to say that after these changes I find it a bit confusing that we have get/set_capacity() and bdev_nr_sectors() / bdev_set_nr_sectors() and they are all the same thing (i_size of the bdev). Is there a reason for the distinction? > diff --git a/block/genhd.c b/block/genhd.c > index 94de95287a6370..e101b6843f7437 100644 > --- a/block/genhd.c > +++ b/block/genhd.c > @@ -38,6 +38,16 @@ static void disk_add_events(struct gendisk *disk); > static void disk_del_events(struct gendisk *disk); > static void disk_release_events(struct gendisk *disk); > > +void set_capacity(struct gendisk *disk, sector_t sectors) > +{ > + struct block_device *bdev = disk->part0.bdev; > + > + spin_lock(&bdev->bd_size_lock); > + i_size_write(bdev->bd_inode, (loff_t)sectors << SECTOR_SHIFT); > + spin_unlock(&bdev->bd_size_lock); AFAICT bd_size_lock is pointless after these changes so we can just remove it? > +} > +EXPORT_SYMBOL(set_capacity); > + > /* > * Set disk capacity and notify if the size is not currently zero and will not > * be set to zero. Returns true if a uevent was sent, otherwise false. > @@ -47,11 +57,12 @@ bool set_capacity_and_notify(struct gendisk *disk, sector_t size) > sector_t capacity = get_capacity(disk); > > set_capacity(disk, size); > - revalidate_disk_size(disk, true); > > if (capacity != size && capacity != 0 && size != 0) { > char *envp[] = { "RESIZE=1", NULL }; > > + pr_info("%s: detected capacity change from %lld to %lld\n", > + disk->disk_name, size, capacity); So we are now missing above message for transitions from / to 0 capacity? Is there any other notification in the kernel log when e.g. media is inserted into a CD-ROM drive? I remember using these messages for detecting that... Also what about GENHD_FL_HIDDEN devices? Are we sure we never set capacity for them? > kobject_uevent_env(&disk_to_dev(disk)->kobj, KOBJ_CHANGE, envp); > return true; > } ... > @@ -983,7 +994,7 @@ void __init printk_all_partitions(void) > > printk("%s%s %10llu %s %s", is_part0 ? "" : " ", > bdevt_str(part_devt(part), devt_buf), > - (unsigned long long)part_nr_sects_read(part) >> 1 > + bdev_nr_sectors(part->bdev) >> 1 > , disk_name(disk, part->partno, name_buf), > part->info ? part->info->uuid : ""); > if (is_part0) { > @@ -1076,7 +1087,7 @@ static int show_partition(struct seq_file *seqf, void *v) > while ((part = disk_part_iter_next(&piter))) > seq_printf(seqf, "%4d %7d %10llu %s\n", > MAJOR(part_devt(part)), MINOR(part_devt(part)), > - (unsigned long long)part_nr_sects_read(part) >> 1, > + bdev_nr_sectors(part->bdev) >> 1, > disk_name(sgp, part->partno, buf)); > disk_part_iter_exit(&piter); > > @@ -1158,8 +1169,7 @@ ssize_t part_size_show(struct device *dev, > { > struct hd_struct *p = dev_to_part(dev); > > - return sprintf(buf, "%llu\n", > - (unsigned long long)part_nr_sects_read(p)); > + return sprintf(buf, "%llu\n", bdev_nr_sectors(p->bdev)); Is sector_t really guaranteed to be unsigned long long? Honza -- Jan Kara SUSE Labs, CR