From: Jan Kara <jack@suse.cz>
To: Christoph Hellwig <hch@lst.de>
Cc: Jan Kara <jack@suse.cz>, Jens Axboe <axboe@kernel.dk>,
Tejun Heo <tj@kernel.org>, Josef Bacik <josef@toxicpanda.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Coly Li <colyli@suse.de>, Mike Snitzer <snitzer@redhat.com>,
dm-devel@redhat.com, Richard Weinberger <richard@nod.at>,
Jan Kara <jack@suse.com>,
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
Date: Fri, 20 Nov 2020 12:21:21 +0100 [thread overview]
Message-ID: <20201120112121.GB15537@quack2.suse.cz> (raw)
In-Reply-To: <20201120090820.GD21715@lst.de>
On Fri 20-11-20 10:08:20, Christoph Hellwig wrote:
> On Thu, Nov 19, 2020 at 01:05:25PM +0100, Jan Kara wrote:
> > > @@ -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?
>
> get_capacity/set_capacity are the existing unchanged interfaces that
> work on struct gendisk, and unchanged from what we had before. They also
> have lots of users which makes them kinda awkward to touch.
>
> bdev_nr_sectors is the public interface to query the size for any
> kind of struct block device, to be used by consumers of the block
> device interface.
>
> bdev_set_nr_sectors is a private helper for the partitions core that
> avoids duplicating a bit of code, and works on partitions.
OK, I guess I'll get used to this...
> > > @@ -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?
>
> I don't think it is, as reuqiring bd_mutex for size updates leads to
> rather awkward lock ordering problems.
OK, let me ask differently: What is bd_size_lock protecting now? Ah, I see,
on 32-bit it is needed to prevent torn writes to i_size, right?
> > > 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...
>
> True, I guess we should keep the messages for that case at least under
> some circumstances. Let me take a closer look at what could make sense.
>
> > Also what about GENHD_FL_HIDDEN devices? Are we sure we never set capacity
> > for them?
>
> We absolutely set the capacity for them, as we have to. And even use
> this interface. But yes, I think we should skip sending the uevent for
> them.
Also previously we were not printing any messages for hidden devices and
now we do. I'm not sure whether that's intended or not.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2020-11-20 11:21 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-18 8:47 merge struct block_device and " Christoph Hellwig
2020-11-18 8:47 ` [PATCH 01/20] blk-cgroup: fix a hd_struct leak in blkcg_fill_root_iostats Christoph Hellwig
2020-11-18 14:09 ` Jan Kara
2020-11-19 8:37 ` Johannes Thumshirn
2020-11-24 12:26 ` Tejun Heo
2020-11-18 8:47 ` [PATCH 02/20] block: remove a duplicate __disk_get_part prototype Christoph Hellwig
2020-11-18 14:10 ` Jan Kara
2020-11-19 8:37 ` Johannes Thumshirn
2020-11-18 8:47 ` [PATCH 03/20] block: add a bdev_kobj helper Christoph Hellwig
2020-11-18 14:18 ` Jan Kara
2020-11-19 8:37 ` Johannes Thumshirn
2020-11-18 8:47 ` [PATCH 04/20] block: use disk_part_iter_exit in disk_part_iter_next Christoph Hellwig
2020-11-18 14:19 ` Jan Kara
2020-11-19 8:37 ` Johannes Thumshirn
2020-11-18 8:47 ` [PATCH 05/20] block: use put_device in put_disk Christoph Hellwig
2020-11-18 14:20 ` Jan Kara
2020-11-19 8:38 ` Johannes Thumshirn
2020-11-18 8:47 ` [PATCH 06/20] block: change the hash used for looking up block devices Christoph Hellwig
2020-11-18 14:22 ` Jan Kara
2020-11-18 8:47 ` [PATCH 07/20] init: refactor name_to_dev_t Christoph Hellwig
2020-11-18 14:37 ` Jan Kara
2020-11-19 7:52 ` Christoph Hellwig
2020-11-19 8:25 ` Jan Kara
2020-11-20 8:49 ` Christoph Hellwig
2020-11-19 8:38 ` Johannes Thumshirn
2020-11-18 8:47 ` [PATCH 08/20] init: refactor devt_from_partuuid Christoph Hellwig
2020-11-18 14:41 ` Jan Kara
2020-11-18 8:47 ` [PATCH 09/20] init: cleanup match_dev_by_uuid and match_dev_by_label Christoph Hellwig
2020-11-18 14:42 ` Jan Kara
2020-11-19 8:38 ` Johannes Thumshirn
2020-11-18 8:47 ` [PATCH 10/20] block: refactor __blkdev_put Christoph Hellwig
2020-11-18 14:46 ` Jan Kara
2020-11-18 8:47 ` [PATCH 11/20] block: reference struct block_device from struct hd_struct Christoph Hellwig
2020-11-19 9:41 ` Jan Kara
2020-11-20 8:56 ` Christoph Hellwig
2020-11-24 16:59 ` Tejun Heo
2020-11-25 11:40 ` Jan Kara
2020-11-25 12:09 ` Tejun Heo
2020-11-18 8:47 ` [PATCH 12/20] block: simplify the block device claiming interface Christoph Hellwig
2020-11-19 10:07 ` Jan Kara
2020-11-18 8:47 ` [PATCH 13/20] block: remove ->bd_contains Christoph Hellwig
2020-11-19 10:32 ` Jan Kara
2020-11-20 9:01 ` Christoph Hellwig
2020-11-18 8:47 ` [PATCH 14/20] block: remove the nr_sects field in struct hd_struct Christoph Hellwig
2020-11-19 12:05 ` Jan Kara
2020-11-20 9:08 ` Christoph Hellwig
2020-11-20 11:21 ` Jan Kara [this message]
2020-11-20 15:32 ` Christoph Hellwig
2020-11-20 15:59 ` Matthew Wilcox
2020-11-20 16:01 ` Christoph Hellwig
2020-11-20 20:05 ` Jan Kara
2020-11-21 16:24 ` Christoph Hellwig
2020-11-18 8:47 ` [PATCH 15/20] block: merge struct block_device and " Christoph Hellwig
2020-11-19 14:39 ` Jan Kara
2020-11-20 9:15 ` Christoph Hellwig
2020-11-20 10:53 ` Jan Kara
2020-11-18 8:47 ` [PATCH 16/20] block: stop using bdget_disk for partition 0 Christoph Hellwig
2020-11-19 14:43 ` Jan Kara
2020-11-18 8:47 ` [PATCH 17/20] filemap: consistently use ->f_mapping over ->i_mapping Christoph Hellwig
2020-11-19 14:53 ` Jan Kara
2020-11-19 15:13 ` Matthew Wilcox
2020-11-20 9:17 ` Christoph Hellwig
2020-11-18 8:47 ` [PATCH 18/20] fs: remove get_super_thawed and get_super_exclusive_thawed Christoph Hellwig
2020-11-19 14:59 ` Jan Kara
2020-11-18 8:47 ` [PATCH 19/20] bcache: remove a superflous lookup_bdev all Christoph Hellwig
2020-11-18 8:54 ` Coly Li
2020-11-18 9:10 ` Greg KH
2020-11-18 9:55 ` Coly Li
2020-11-18 16:24 ` Christoph Hellwig
2020-11-18 8:48 ` [PATCH 20/20] block: remove i_bdev Christoph Hellwig
2020-11-18 8:56 ` merge struct block_device and struct hd_struct Jan Beulich
2020-11-18 8:58 ` Christoph Hellwig
2020-11-18 9:04 ` Jan Beulich
2020-11-18 9:08 ` Christoph Hellwig
2020-11-18 9:09 ` Greg KH
2020-11-18 9:23 ` Jan Beulich
2020-11-18 9:32 ` Greg KH
2020-11-18 12:50 ` Matthew Wilcox
2020-11-18 9:13 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201120112121.GB15537@quack2.suse.cz \
--to=jack@suse.cz \
--cc=axboe@kernel.dk \
--cc=colyli@suse.de \
--cc=dm-devel@redhat.com \
--cc=hch@lst.de \
--cc=jack@suse.com \
--cc=josef@toxicpanda.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-bcache@vger.kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
--cc=snitzer@redhat.com \
--cc=tj@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox