All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Matthew Wilcox <willy@infradead.org>
Cc: Christoph Hellwig <hch@lst.de>, 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 21:05:48 +0100	[thread overview]
Message-ID: <20201120200548.GA27360@quack2.suse.cz> (raw)
In-Reply-To: <20201120155956.GB4327@casper.infradead.org>

On Fri 20-11-20 15:59:56, Matthew Wilcox wrote:
> On Fri, Nov 20, 2020 at 04:32:53PM +0100, Christoph Hellwig wrote:
> > On Fri, Nov 20, 2020 at 12:21:21PM +0100, Jan Kara wrote:
> > > > > 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?
> > 
> > Exactly.  In theory we could skip it for 64-bit, but as updating the
> > size isn't a fast path, and struct block_device isn't super size critical
> > I'd rather keep the same code for 32 vs 64-bit builds.
> 
> Is it better to switch to i_size_write() / i_size_read()?

The code is already switched to it AFAICT (the lock is really only used in
the two places that write i_size). But the problem is that in theory two
i_size_write() calls can race in a way that the resulting stored i_size is a
mix of two stored sizes. Now I have hard time imagining how this could
happen for a block device and if two reconfigurations of a block device
could race like that we'd have a large problems anyway...

								Honza

-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

WARNING: multiple messages have this Message-ID (diff)
From: Jan Kara <jack@suse.cz>
To: Matthew Wilcox <willy@infradead.org>
Cc: Jens Axboe <axboe@kernel.dk>, Jan Kara <jack@suse.cz>,
	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,
	linux-mm@kvack.org, Jan Kara <jack@suse.com>,
	Tejun Heo <tj@kernel.org>,
	xen-devel@lists.xenproject.org, linux-bcache@vger.kernel.org,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH 14/20] block: remove the nr_sects field in struct hd_struct
Date: Fri, 20 Nov 2020 21:05:48 +0100	[thread overview]
Message-ID: <20201120200548.GA27360@quack2.suse.cz> (raw)
In-Reply-To: <20201120155956.GB4327@casper.infradead.org>

On Fri 20-11-20 15:59:56, Matthew Wilcox wrote:
> On Fri, Nov 20, 2020 at 04:32:53PM +0100, Christoph Hellwig wrote:
> > On Fri, Nov 20, 2020 at 12:21:21PM +0100, Jan Kara wrote:
> > > > > 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?
> > 
> > Exactly.  In theory we could skip it for 64-bit, but as updating the
> > size isn't a fast path, and struct block_device isn't super size critical
> > I'd rather keep the same code for 32 vs 64-bit builds.
> 
> Is it better to switch to i_size_write() / i_size_read()?

The code is already switched to it AFAICT (the lock is really only used in
the two places that write i_size). But the problem is that in theory two
i_size_write() calls can race in a way that the resulting stored i_size is a
mix of two stored sizes. Now I have hard time imagining how this could
happen for a block device and if two reconfigurations of a block device
could race like that we'd have a large problems anyway...

								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: Matthew Wilcox <willy@infradead.org>
Cc: Jens Axboe <axboe@kernel.dk>, Jan Kara <jack@suse.cz>,
	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,
	linux-mm@kvack.org, Jan Kara <jack@suse.com>,
	Tejun Heo <tj@kernel.org>,
	xen-devel@lists.xenproject.org, linux-bcache@vger.kernel.org,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [dm-devel] [PATCH 14/20] block: remove the nr_sects field in struct hd_struct
Date: Fri, 20 Nov 2020 21:05:48 +0100	[thread overview]
Message-ID: <20201120200548.GA27360@quack2.suse.cz> (raw)
In-Reply-To: <20201120155956.GB4327@casper.infradead.org>

On Fri 20-11-20 15:59:56, Matthew Wilcox wrote:
> On Fri, Nov 20, 2020 at 04:32:53PM +0100, Christoph Hellwig wrote:
> > On Fri, Nov 20, 2020 at 12:21:21PM +0100, Jan Kara wrote:
> > > > > 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?
> > 
> > Exactly.  In theory we could skip it for 64-bit, but as updating the
> > size isn't a fast path, and struct block_device isn't super size critical
> > I'd rather keep the same code for 32 vs 64-bit builds.
> 
> Is it better to switch to i_size_write() / i_size_read()?

The code is already switched to it AFAICT (the lock is really only used in
the two places that write i_size). But the problem is that in theory two
i_size_write() calls can race in a way that the resulting stored i_size is a
mix of two stored sizes. Now I have hard time imagining how this could
happen for a block device and if two reconfigurations of a block device
could race like that we'd have a large problems anyway...

								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


  parent reply	other threads:[~2020-11-20 20:06 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
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 [this message]
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=20201120200548.GA27360@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=willy@infradead.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.