All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Christoph Hellwig <hch@lst.de>
Cc: 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: Thu, 19 Nov 2020 13:05:25 +0100	[thread overview]
Message-ID: <20201119120525.GW1981@quack2.suse.cz> (raw)
In-Reply-To: <20201118084800.2339180-15-hch@lst.de>

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 <hch@lst.de>

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 <jack@suse.com>
SUSE Labs, CR

WARNING: multiple messages have this Message-ID (diff)
From: Jan Kara <jack@suse.cz>
To: Christoph Hellwig <hch@lst.de>
Cc: Jens Axboe <axboe@kernel.dk>, Mike Snitzer <snitzer@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Richard Weinberger <richard@nod.at>,
	Josef Bacik <josef@toxicpanda.com>, Coly Li <colyli@suse.de>,
	linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	dm-devel@redhat.com, linux-mtd@lists.infradead.org,
	Jan Kara <jack@suse.com>, Tejun Heo <tj@kernel.org>,
	xen-devel@lists.xenproject.org, linux-bcache@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [PATCH 14/20] block: remove the nr_sects field in struct hd_struct
Date: Thu, 19 Nov 2020 13:05:25 +0100	[thread overview]
Message-ID: <20201119120525.GW1981@quack2.suse.cz> (raw)
In-Reply-To: <20201118084800.2339180-15-hch@lst.de>

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 <hch@lst.de>

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 <jack@suse.com>
SUSE Labs, CR

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Jan Kara <jack@suse.cz>
To: Christoph Hellwig <hch@lst.de>
Cc: Jens Axboe <axboe@kernel.dk>, Mike Snitzer <snitzer@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Richard Weinberger <richard@nod.at>,
	Josef Bacik <josef@toxicpanda.com>, Coly Li <colyli@suse.de>,
	linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	dm-devel@redhat.com, linux-mtd@lists.infradead.org,
	Jan Kara <jack@suse.com>, Tejun Heo <tj@kernel.org>,
	xen-devel@lists.xenproject.org, linux-bcache@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [dm-devel] [PATCH 14/20] block: remove the nr_sects field in struct hd_struct
Date: Thu, 19 Nov 2020 13:05:25 +0100	[thread overview]
Message-ID: <20201119120525.GW1981@quack2.suse.cz> (raw)
In-Reply-To: <20201118084800.2339180-15-hch@lst.de>

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 <hch@lst.de>

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 <jack@suse.com>
SUSE Labs, CR

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


  reply	other threads:[~2020-11-19 12:05 UTC|newest]

Thread overview: 237+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-18  8:47 merge struct block_device and struct hd_struct Christoph Hellwig
2020-11-18  8:47 ` [dm-devel] " Christoph Hellwig
2020-11-18  8:47 ` 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  8:47   ` [dm-devel] " Christoph Hellwig
2020-11-18  8:47   ` Christoph Hellwig
2020-11-18 14:09   ` Jan Kara
2020-11-18 14:09     ` [dm-devel] " Jan Kara
2020-11-18 14:09     ` Jan Kara
2020-11-19  8:37   ` Johannes Thumshirn
2020-11-19  8:37     ` [dm-devel] " Johannes Thumshirn
2020-11-19  8:37     ` Johannes Thumshirn
2020-11-24 12:26   ` Tejun Heo
2020-11-24 12:26     ` [dm-devel] " Tejun Heo
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  8:47   ` [dm-devel] " Christoph Hellwig
2020-11-18  8:47   ` Christoph Hellwig
2020-11-18 14:10   ` Jan Kara
2020-11-18 14:10     ` [dm-devel] " Jan Kara
2020-11-18 14:10     ` Jan Kara
2020-11-19  8:37   ` Johannes Thumshirn
2020-11-19  8:37     ` [dm-devel] " Johannes Thumshirn
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  8:47   ` [dm-devel] " Christoph Hellwig
2020-11-18  8:47   ` Christoph Hellwig
2020-11-18 14:18   ` Jan Kara
2020-11-18 14:18     ` [dm-devel] " Jan Kara
2020-11-18 14:18     ` Jan Kara
2020-11-19  8:37   ` Johannes Thumshirn
2020-11-19  8:37     ` [dm-devel] " Johannes Thumshirn
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  8:47   ` [dm-devel] " Christoph Hellwig
2020-11-18  8:47   ` Christoph Hellwig
2020-11-18 14:19   ` Jan Kara
2020-11-18 14:19     ` [dm-devel] " Jan Kara
2020-11-18 14:19     ` Jan Kara
2020-11-19  8:37   ` Johannes Thumshirn
2020-11-19  8:37     ` [dm-devel] " Johannes Thumshirn
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  8:47   ` [dm-devel] " Christoph Hellwig
2020-11-18  8:47   ` Christoph Hellwig
2020-11-18 14:20   ` Jan Kara
2020-11-18 14:20     ` [dm-devel] " Jan Kara
2020-11-18 14:20     ` Jan Kara
2020-11-19  8:38   ` Johannes Thumshirn
2020-11-19  8:38     ` [dm-devel] " Johannes Thumshirn
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  8:47   ` [dm-devel] " Christoph Hellwig
2020-11-18  8:47   ` Christoph Hellwig
2020-11-18 14:22   ` Jan Kara
2020-11-18 14:22     ` [dm-devel] " Jan Kara
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  8:47   ` [dm-devel] " Christoph Hellwig
2020-11-18  8:47   ` Christoph Hellwig
2020-11-18 14:37   ` Jan Kara
2020-11-18 14:37     ` [dm-devel] " Jan Kara
2020-11-18 14:37     ` Jan Kara
2020-11-19  7:52     ` Christoph Hellwig
2020-11-19  7:52       ` [dm-devel] " Christoph Hellwig
2020-11-19  7:52       ` Christoph Hellwig
2020-11-19  8:25       ` Jan Kara
2020-11-19  8:25         ` [dm-devel] " Jan Kara
2020-11-19  8:25         ` Jan Kara
2020-11-20  8:49         ` Christoph Hellwig
2020-11-20  8:49           ` [dm-devel] " Christoph Hellwig
2020-11-20  8:49           ` Christoph Hellwig
2020-11-19  8:38   ` Johannes Thumshirn
2020-11-19  8:38     ` [dm-devel] " Johannes Thumshirn
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  8:47   ` [dm-devel] " Christoph Hellwig
2020-11-18  8:47   ` Christoph Hellwig
2020-11-18 14:41   ` Jan Kara
2020-11-18 14:41     ` [dm-devel] " Jan Kara
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  8:47   ` [dm-devel] " Christoph Hellwig
2020-11-18  8:47   ` Christoph Hellwig
2020-11-18 14:42   ` Jan Kara
2020-11-18 14:42     ` [dm-devel] " Jan Kara
2020-11-18 14:42     ` Jan Kara
2020-11-19  8:38   ` Johannes Thumshirn
2020-11-19  8:38     ` [dm-devel] " Johannes Thumshirn
2020-11-19  8:38     ` Johannes Thumshirn
2020-11-18  8:47 ` [PATCH 10/20] block: refactor __blkdev_put Christoph Hellwig
2020-11-18  8:47   ` [dm-devel] " Christoph Hellwig
2020-11-18  8:47   ` Christoph Hellwig
2020-11-18 14:46   ` Jan Kara
2020-11-18 14:46     ` [dm-devel] " Jan Kara
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-18  8:47   ` [dm-devel] " Christoph Hellwig
2020-11-18  8:47   ` Christoph Hellwig
2020-11-19  9:41   ` Jan Kara
2020-11-19  9:41     ` [dm-devel] " Jan Kara
2020-11-19  9:41     ` Jan Kara
2020-11-20  8:56     ` Christoph Hellwig
2020-11-20  8:56       ` [dm-devel] " Christoph Hellwig
2020-11-20  8:56       ` Christoph Hellwig
2020-11-24 16:59   ` Tejun Heo
2020-11-24 16:59     ` [dm-devel] " Tejun Heo
2020-11-24 16:59     ` Tejun Heo
2020-11-25 11:40     ` Jan Kara
2020-11-25 11:40       ` [dm-devel] " Jan Kara
2020-11-25 11:40       ` Jan Kara
2020-11-25 12:09       ` Tejun Heo
2020-11-25 12:09         ` [dm-devel] " Tejun Heo
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-18  8:47   ` [dm-devel] " Christoph Hellwig
2020-11-18  8:47   ` Christoph Hellwig
2020-11-19 10:07   ` Jan Kara
2020-11-19 10:07     ` [dm-devel] " Jan Kara
2020-11-19 10:07     ` Jan Kara
2020-11-18  8:47 ` [PATCH 13/20] block: remove ->bd_contains Christoph Hellwig
2020-11-18  8:47   ` [dm-devel] " Christoph Hellwig
2020-11-18  8:47   ` Christoph Hellwig
2020-11-19 10:32   ` Jan Kara
2020-11-19 10:32     ` [dm-devel] " Jan Kara
2020-11-19 10:32     ` Jan Kara
2020-11-20  9:01     ` Christoph Hellwig
2020-11-20  9:01       ` [dm-devel] " Christoph Hellwig
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-18  8:47   ` [dm-devel] " Christoph Hellwig
2020-11-18  8:47   ` Christoph Hellwig
2020-11-19 12:05   ` Jan Kara [this message]
2020-11-19 12:05     ` [dm-devel] " Jan Kara
2020-11-19 12:05     ` Jan Kara
2020-11-20  9:08     ` Christoph Hellwig
2020-11-20  9:08       ` [dm-devel] " Christoph Hellwig
2020-11-20  9:08       ` Christoph Hellwig
2020-11-20 11:21       ` Jan Kara
2020-11-20 11:21         ` [dm-devel] " Jan Kara
2020-11-20 11:21         ` Jan Kara
2020-11-20 15:32         ` Christoph Hellwig
2020-11-20 15:32           ` [dm-devel] " Christoph Hellwig
2020-11-20 15:32           ` Christoph Hellwig
2020-11-20 15:59           ` Matthew Wilcox
2020-11-20 15:59             ` [dm-devel] " Matthew Wilcox
2020-11-20 15:59             ` Matthew Wilcox
2020-11-20 16:01             ` Christoph Hellwig
2020-11-20 16:01               ` [dm-devel] " Christoph Hellwig
2020-11-20 16:01               ` Christoph Hellwig
2020-11-20 20:05             ` Jan Kara
2020-11-20 20:05               ` [dm-devel] " Jan Kara
2020-11-20 20:05               ` Jan Kara
2020-11-21 16:24               ` Christoph Hellwig
2020-11-21 16:24                 ` [dm-devel] " Christoph Hellwig
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-18  8:47   ` [dm-devel] " Christoph Hellwig
2020-11-18  8:47   ` Christoph Hellwig
2020-11-19 14:39   ` Jan Kara
2020-11-19 14:39     ` [dm-devel] " Jan Kara
2020-11-19 14:39     ` Jan Kara
2020-11-20  9:15     ` Christoph Hellwig
2020-11-20  9:15       ` [dm-devel] " Christoph Hellwig
2020-11-20  9:15       ` Christoph Hellwig
2020-11-20 10:53       ` Jan Kara
2020-11-20 10:53         ` [dm-devel] " Jan Kara
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-18  8:47   ` [dm-devel] " Christoph Hellwig
2020-11-18  8:47   ` Christoph Hellwig
2020-11-19 14:43   ` Jan Kara
2020-11-19 14:43     ` [dm-devel] " Jan Kara
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-18  8:47   ` [dm-devel] " Christoph Hellwig
2020-11-18  8:47   ` Christoph Hellwig
2020-11-19 14:53   ` Jan Kara
2020-11-19 14:53     ` [dm-devel] " Jan Kara
2020-11-19 14:53     ` Jan Kara
2020-11-19 15:13   ` Matthew Wilcox
2020-11-19 15:13     ` [dm-devel] " Matthew Wilcox
2020-11-19 15:13     ` Matthew Wilcox
2020-11-20  9:17     ` Christoph Hellwig
2020-11-20  9:17       ` [dm-devel] " Christoph Hellwig
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-18  8:47   ` [dm-devel] " Christoph Hellwig
2020-11-18  8:47   ` Christoph Hellwig
2020-11-19 14:59   ` Jan Kara
2020-11-19 14:59     ` [dm-devel] " Jan Kara
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:47   ` [dm-devel] " Christoph Hellwig
2020-11-18  8:47   ` Christoph Hellwig
2020-11-18  8:54   ` Coly Li
2020-11-18  8:54     ` [dm-devel] " Coly Li
2020-11-18  8:54     ` Coly Li
2020-11-18  9:10     ` Greg KH
2020-11-18  9:10       ` [dm-devel] " Greg KH
2020-11-18  9:10       ` Greg KH
2020-11-18  9:55       ` Coly Li
2020-11-18  9:55         ` [dm-devel] " Coly Li
2020-11-18  9:55         ` Coly Li
2020-11-18 16:24     ` Christoph Hellwig
2020-11-18 16:24       ` [dm-devel] " Christoph Hellwig
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:48   ` [dm-devel] " Christoph Hellwig
2020-11-18  8:48   ` Christoph Hellwig
2020-11-18  8:56 ` merge struct block_device and struct hd_struct Jan Beulich
2020-11-18  8:56   ` [dm-devel] " Jan Beulich
2020-11-18  8:56   ` Jan Beulich
2020-11-18  8:58   ` Christoph Hellwig
2020-11-18  8:58     ` [dm-devel] " Christoph Hellwig
2020-11-18  8:58     ` Christoph Hellwig
2020-11-18  9:04     ` Jan Beulich
2020-11-18  9:04       ` [dm-devel] " Jan Beulich
2020-11-18  9:04       ` Jan Beulich
2020-11-18  9:08       ` Christoph Hellwig
2020-11-18  9:08         ` [dm-devel] " Christoph Hellwig
2020-11-18  9:08         ` Christoph Hellwig
2020-11-18  9:09       ` Greg KH
2020-11-18  9:09         ` [dm-devel] " Greg KH
2020-11-18  9:09         ` Greg KH
2020-11-18  9:23         ` Jan Beulich
2020-11-18  9:23           ` [dm-devel] " Jan Beulich
2020-11-18  9:23           ` Jan Beulich
2020-11-18  9:32           ` Greg KH
2020-11-18  9:32             ` [dm-devel] " Greg KH
2020-11-18  9:32             ` Greg KH
2020-11-18 12:50           ` Matthew Wilcox
2020-11-18 12:50             ` [dm-devel] " Matthew Wilcox
2020-11-18 12:50             ` Matthew Wilcox
2020-11-18  9:13 ` Greg KH
2020-11-18  9:13   ` [dm-devel] " Greg KH
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=20201119120525.GW1981@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.