From: Vivek Goyal <vgoyal@redhat.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Toshi Kani <toshi.kani@hp.com>, Baoquan <bhe@redhat.com>,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
tangchen@cn.fujitsu.com, linux-acpi@vger.kernel.org,
zhangyanfei@cn.fujitsu.com, dyoung@redhat.com
Subject: Re: kdump failed because of hotplug memory adding in kdump kernel
Date: Thu, 9 Jan 2014 09:53:59 -0500 [thread overview]
Message-ID: <20140109145359.GC25897@redhat.com> (raw)
In-Reply-To: <1607377.rjs1kRTsnc@vostro.rjw.lan>
On Thu, Jan 09, 2014 at 02:10:26PM +0100, Rafael J. Wysocki wrote:
> On Wednesday, January 08, 2014 05:11:48 PM Toshi Kani wrote:
> > On Thu, 2014-01-09 at 00:07 +0100, Rafael J. Wysocki wrote:
> > > On Wednesday, January 08, 2014 10:58:29 AM Vivek Goyal wrote:
> > > > On Wed, Jan 08, 2014 at 11:26:43PM +0800, Baoquan wrote:
> > > >
> > > > [..]
> > > > > [ 1.592222] acpi PNP0A03:03: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge.
> > > > > [ 1.605045] PCI host bridge to bus 0000:ff
> > > > > [ 1.609615] pci_bus 0000:ff: root bus resource [bus ff]
> > > > > [ 1.632117] System RAM resource [mem 0x01000000-0x7bffffff] cannot be added
> > > > > [ 1.639892] init_memory_mapping: [mem 0x100000000-0x87fffffff]
> > > > > [ 1.717793] swapper/0: page allocation failure: order:9, mode:0x84d0
> > > > > [ 1.724884] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-59.el7.x86_64 #1
> > > > > [ 1.732842] Hardware name: QCI QSSC-S4R/QSSC-S4R, BIOS QSSC-S4R.QCI.01.00.S001.032520101647 03/25/2010
> > > > > [ 1.743224] 0000000000000000 ffff8800339878c8 ffffffff815b64ad ffff880033987950
> > > > > [ 1.751513] ffffffff8113a980 ffff88003673ab28 00000000000001fe 0000000000000001
> > > > > [ 1.759804] ffff880000000040 ffffffff810bc28a 0000000000000000 0000000000000200
> > > > > [ 1.768096] Call Trace: [348/1928]
> > > > > [ 1.770834] [<ffffffff815b64ad>] dump_stack+0x19/0x1b
> > > > > [ 1.776561] [<ffffffff8113a980>] warn_alloc_failed+0xf0/0x160
> > > > > [ 1.783076] [<ffffffff810bc28a>] ? on_each_cpu_mask+0x2a/0x60
> > > > > [ 1.789581] [<ffffffff8113e92f>] __alloc_pages_nodemask+0x7ff/0xa00
> > > > > [ 1.796672] [<ffffffff815ada2c>] vmemmap_alloc_block+0x62/0xba
> > > > > [ 1.803274] [<ffffffff815ada99>] vmemmap_alloc_block_buf+0x15/0x3b
> > > > > [ 1.810263] [<ffffffff815ab8a6>] vmemmap_populate+0xb4/0x21b
> > > > > [ 1.816673] [<ffffffff815adecd>] sparse_mem_map_populate+0x27/0x35
> > > > > [ 1.823665] [<ffffffff815ad8bf>] sparse_add_one_section+0x7a/0x185
> > > > > [ 1.830659] [<ffffffff8159b74f>] __add_pages+0xaf/0x240
> > > > > [ 1.836588] [<ffffffff81047359>] arch_add_memory+0x59/0xd0
> > > > > [ 1.842804] [<ffffffff8159ba89>] add_memory+0xb9/0x1b0
> > > > > [ 1.848638] [<ffffffff8132dd2c>] acpi_memory_device_add+0x18d/0x26d
> > > > > [ 1.855728] [<ffffffff81303b91>] acpi_bus_device_attach+0x7d/0xcd
> > > > > [ 1.862625] [<ffffffff8131d92d>] acpi_ns_walk_namespace+0xc8/0x17f
> > > > > [ 1.869616] [<ffffffff81303b14>] ? acpi_bus_type_and_status+0x90/0x90
> > > > > [ 1.876896] [<ffffffff81303b14>] ? acpi_bus_type_and_status+0x90/0x90
> > > > > [ 1.884177] [<ffffffff8131de1c>] acpi_walk_namespace+0x95/0xc5
> > > > > [ 1.890780] [<ffffffff81304866>] acpi_bus_scan+0x8b/0x9d
> > > > > [ 1.896805] [<ffffffff81a14a15>] acpi_scan_init+0x63/0x160
> > > > > [ 1.903021] [<ffffffff81a14830>] acpi_init+0x25d/0x2a6
> > > >
> > > > So basically acpi thinks that some memory block is a hot plug memory
> > > > and tries to add it. And that consumes lots of memory and we don't have
> > > > that memory in second kernel.
> > >
> > > That's not exactly the case. What seems to happen is that there is an ACPI
> > > memory object in the ACPI namespace and the ACPI memory hotplug driver
> > > attempts to bind to it. That driver attempts to find removable memory blocks
> > > associated with that object and to add them to the memory map.
> > >
> > > Why don't you simply append acpi=off to the kexec command line? That should
> > > make the problem go away.
> >
> > Yes, that should work, but Baoquan's approach makes sense to me. When
> > memmap=exactmap is specified, the kernel should ignore any memory
> > information from the firmware.
>
> OK
>
> Baoquan, please modify your patch to get rid of the #ifdef CONFIG_X86 in
> acpi_memory_hotplug_init(). For example, you can add a function returning true
> if use_exactmap is set and false otherwise and make acpi_memory_hotplug_init()
> call that function. Alternatively, you can define arch-independent
> no_memory_hotplug (instead of use_exactmap) and set if for memmap=exactmap.
>
Prarit sent a patch to introduce no_memory_hotplug command line. I still
think that memmap=exactmap does not necessarily mean that memory hotplug
is disabled.
What about mem= parameter. If somebody specifies mem=1G, should that mean
there can not be any hotplugged memory.
I think we should atleast define a new command line parameter to disable
memory hotplug. After that users can specify both memmap=exactmap and
"no_mem_hotplug" on command line and control the behavior of kernel.
Thanks
Vivek
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Vivek Goyal <vgoyal-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: "Rafael J. Wysocki" <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org>
Cc: Toshi Kani <toshi.kani-VXdhtT5mjnY@public.gmane.org>,
Baoquan <bhe-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
tangchen-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org,
linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
zhangyanfei-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org,
dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
Subject: Re: kdump failed because of hotplug memory adding in kdump kernel
Date: Thu, 9 Jan 2014 09:53:59 -0500 [thread overview]
Message-ID: <20140109145359.GC25897@redhat.com> (raw)
In-Reply-To: <1607377.rjs1kRTsnc-sKB8Sp2ER+y1GS7QM15AGw@public.gmane.org>
On Thu, Jan 09, 2014 at 02:10:26PM +0100, Rafael J. Wysocki wrote:
> On Wednesday, January 08, 2014 05:11:48 PM Toshi Kani wrote:
> > On Thu, 2014-01-09 at 00:07 +0100, Rafael J. Wysocki wrote:
> > > On Wednesday, January 08, 2014 10:58:29 AM Vivek Goyal wrote:
> > > > On Wed, Jan 08, 2014 at 11:26:43PM +0800, Baoquan wrote:
> > > >
> > > > [..]
> > > > > [ 1.592222] acpi PNP0A03:03: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge.
> > > > > [ 1.605045] PCI host bridge to bus 0000:ff
> > > > > [ 1.609615] pci_bus 0000:ff: root bus resource [bus ff]
> > > > > [ 1.632117] System RAM resource [mem 0x01000000-0x7bffffff] cannot be added
> > > > > [ 1.639892] init_memory_mapping: [mem 0x100000000-0x87fffffff]
> > > > > [ 1.717793] swapper/0: page allocation failure: order:9, mode:0x84d0
> > > > > [ 1.724884] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-59.el7.x86_64 #1
> > > > > [ 1.732842] Hardware name: QCI QSSC-S4R/QSSC-S4R, BIOS QSSC-S4R.QCI.01.00.S001.032520101647 03/25/2010
> > > > > [ 1.743224] 0000000000000000 ffff8800339878c8 ffffffff815b64ad ffff880033987950
> > > > > [ 1.751513] ffffffff8113a980 ffff88003673ab28 00000000000001fe 0000000000000001
> > > > > [ 1.759804] ffff880000000040 ffffffff810bc28a 0000000000000000 0000000000000200
> > > > > [ 1.768096] Call Trace: [348/1928]
> > > > > [ 1.770834] [<ffffffff815b64ad>] dump_stack+0x19/0x1b
> > > > > [ 1.776561] [<ffffffff8113a980>] warn_alloc_failed+0xf0/0x160
> > > > > [ 1.783076] [<ffffffff810bc28a>] ? on_each_cpu_mask+0x2a/0x60
> > > > > [ 1.789581] [<ffffffff8113e92f>] __alloc_pages_nodemask+0x7ff/0xa00
> > > > > [ 1.796672] [<ffffffff815ada2c>] vmemmap_alloc_block+0x62/0xba
> > > > > [ 1.803274] [<ffffffff815ada99>] vmemmap_alloc_block_buf+0x15/0x3b
> > > > > [ 1.810263] [<ffffffff815ab8a6>] vmemmap_populate+0xb4/0x21b
> > > > > [ 1.816673] [<ffffffff815adecd>] sparse_mem_map_populate+0x27/0x35
> > > > > [ 1.823665] [<ffffffff815ad8bf>] sparse_add_one_section+0x7a/0x185
> > > > > [ 1.830659] [<ffffffff8159b74f>] __add_pages+0xaf/0x240
> > > > > [ 1.836588] [<ffffffff81047359>] arch_add_memory+0x59/0xd0
> > > > > [ 1.842804] [<ffffffff8159ba89>] add_memory+0xb9/0x1b0
> > > > > [ 1.848638] [<ffffffff8132dd2c>] acpi_memory_device_add+0x18d/0x26d
> > > > > [ 1.855728] [<ffffffff81303b91>] acpi_bus_device_attach+0x7d/0xcd
> > > > > [ 1.862625] [<ffffffff8131d92d>] acpi_ns_walk_namespace+0xc8/0x17f
> > > > > [ 1.869616] [<ffffffff81303b14>] ? acpi_bus_type_and_status+0x90/0x90
> > > > > [ 1.876896] [<ffffffff81303b14>] ? acpi_bus_type_and_status+0x90/0x90
> > > > > [ 1.884177] [<ffffffff8131de1c>] acpi_walk_namespace+0x95/0xc5
> > > > > [ 1.890780] [<ffffffff81304866>] acpi_bus_scan+0x8b/0x9d
> > > > > [ 1.896805] [<ffffffff81a14a15>] acpi_scan_init+0x63/0x160
> > > > > [ 1.903021] [<ffffffff81a14830>] acpi_init+0x25d/0x2a6
> > > >
> > > > So basically acpi thinks that some memory block is a hot plug memory
> > > > and tries to add it. And that consumes lots of memory and we don't have
> > > > that memory in second kernel.
> > >
> > > That's not exactly the case. What seems to happen is that there is an ACPI
> > > memory object in the ACPI namespace and the ACPI memory hotplug driver
> > > attempts to bind to it. That driver attempts to find removable memory blocks
> > > associated with that object and to add them to the memory map.
> > >
> > > Why don't you simply append acpi=off to the kexec command line? That should
> > > make the problem go away.
> >
> > Yes, that should work, but Baoquan's approach makes sense to me. When
> > memmap=exactmap is specified, the kernel should ignore any memory
> > information from the firmware.
>
> OK
>
> Baoquan, please modify your patch to get rid of the #ifdef CONFIG_X86 in
> acpi_memory_hotplug_init(). For example, you can add a function returning true
> if use_exactmap is set and false otherwise and make acpi_memory_hotplug_init()
> call that function. Alternatively, you can define arch-independent
> no_memory_hotplug (instead of use_exactmap) and set if for memmap=exactmap.
>
Prarit sent a patch to introduce no_memory_hotplug command line. I still
think that memmap=exactmap does not necessarily mean that memory hotplug
is disabled.
What about mem= parameter. If somebody specifies mem=1G, should that mean
there can not be any hotplugged memory.
I think we should atleast define a new command line parameter to disable
memory hotplug. After that users can specify both memmap=exactmap and
"no_mem_hotplug" on command line and control the behavior of kernel.
Thanks
Vivek
WARNING: multiple messages have this Message-ID (diff)
From: Vivek Goyal <vgoyal@redhat.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Toshi Kani <toshi.kani@hp.com>, Baoquan <bhe@redhat.com>,
linux-acpi@vger.kernel.org, zhangyanfei@cn.fujitsu.com,
tangchen@cn.fujitsu.com, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org, dyoung@redhat.com
Subject: Re: kdump failed because of hotplug memory adding in kdump kernel
Date: Thu, 9 Jan 2014 09:53:59 -0500 [thread overview]
Message-ID: <20140109145359.GC25897@redhat.com> (raw)
In-Reply-To: <1607377.rjs1kRTsnc@vostro.rjw.lan>
On Thu, Jan 09, 2014 at 02:10:26PM +0100, Rafael J. Wysocki wrote:
> On Wednesday, January 08, 2014 05:11:48 PM Toshi Kani wrote:
> > On Thu, 2014-01-09 at 00:07 +0100, Rafael J. Wysocki wrote:
> > > On Wednesday, January 08, 2014 10:58:29 AM Vivek Goyal wrote:
> > > > On Wed, Jan 08, 2014 at 11:26:43PM +0800, Baoquan wrote:
> > > >
> > > > [..]
> > > > > [ 1.592222] acpi PNP0A03:03: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge.
> > > > > [ 1.605045] PCI host bridge to bus 0000:ff
> > > > > [ 1.609615] pci_bus 0000:ff: root bus resource [bus ff]
> > > > > [ 1.632117] System RAM resource [mem 0x01000000-0x7bffffff] cannot be added
> > > > > [ 1.639892] init_memory_mapping: [mem 0x100000000-0x87fffffff]
> > > > > [ 1.717793] swapper/0: page allocation failure: order:9, mode:0x84d0
> > > > > [ 1.724884] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-59.el7.x86_64 #1
> > > > > [ 1.732842] Hardware name: QCI QSSC-S4R/QSSC-S4R, BIOS QSSC-S4R.QCI.01.00.S001.032520101647 03/25/2010
> > > > > [ 1.743224] 0000000000000000 ffff8800339878c8 ffffffff815b64ad ffff880033987950
> > > > > [ 1.751513] ffffffff8113a980 ffff88003673ab28 00000000000001fe 0000000000000001
> > > > > [ 1.759804] ffff880000000040 ffffffff810bc28a 0000000000000000 0000000000000200
> > > > > [ 1.768096] Call Trace: [348/1928]
> > > > > [ 1.770834] [<ffffffff815b64ad>] dump_stack+0x19/0x1b
> > > > > [ 1.776561] [<ffffffff8113a980>] warn_alloc_failed+0xf0/0x160
> > > > > [ 1.783076] [<ffffffff810bc28a>] ? on_each_cpu_mask+0x2a/0x60
> > > > > [ 1.789581] [<ffffffff8113e92f>] __alloc_pages_nodemask+0x7ff/0xa00
> > > > > [ 1.796672] [<ffffffff815ada2c>] vmemmap_alloc_block+0x62/0xba
> > > > > [ 1.803274] [<ffffffff815ada99>] vmemmap_alloc_block_buf+0x15/0x3b
> > > > > [ 1.810263] [<ffffffff815ab8a6>] vmemmap_populate+0xb4/0x21b
> > > > > [ 1.816673] [<ffffffff815adecd>] sparse_mem_map_populate+0x27/0x35
> > > > > [ 1.823665] [<ffffffff815ad8bf>] sparse_add_one_section+0x7a/0x185
> > > > > [ 1.830659] [<ffffffff8159b74f>] __add_pages+0xaf/0x240
> > > > > [ 1.836588] [<ffffffff81047359>] arch_add_memory+0x59/0xd0
> > > > > [ 1.842804] [<ffffffff8159ba89>] add_memory+0xb9/0x1b0
> > > > > [ 1.848638] [<ffffffff8132dd2c>] acpi_memory_device_add+0x18d/0x26d
> > > > > [ 1.855728] [<ffffffff81303b91>] acpi_bus_device_attach+0x7d/0xcd
> > > > > [ 1.862625] [<ffffffff8131d92d>] acpi_ns_walk_namespace+0xc8/0x17f
> > > > > [ 1.869616] [<ffffffff81303b14>] ? acpi_bus_type_and_status+0x90/0x90
> > > > > [ 1.876896] [<ffffffff81303b14>] ? acpi_bus_type_and_status+0x90/0x90
> > > > > [ 1.884177] [<ffffffff8131de1c>] acpi_walk_namespace+0x95/0xc5
> > > > > [ 1.890780] [<ffffffff81304866>] acpi_bus_scan+0x8b/0x9d
> > > > > [ 1.896805] [<ffffffff81a14a15>] acpi_scan_init+0x63/0x160
> > > > > [ 1.903021] [<ffffffff81a14830>] acpi_init+0x25d/0x2a6
> > > >
> > > > So basically acpi thinks that some memory block is a hot plug memory
> > > > and tries to add it. And that consumes lots of memory and we don't have
> > > > that memory in second kernel.
> > >
> > > That's not exactly the case. What seems to happen is that there is an ACPI
> > > memory object in the ACPI namespace and the ACPI memory hotplug driver
> > > attempts to bind to it. That driver attempts to find removable memory blocks
> > > associated with that object and to add them to the memory map.
> > >
> > > Why don't you simply append acpi=off to the kexec command line? That should
> > > make the problem go away.
> >
> > Yes, that should work, but Baoquan's approach makes sense to me. When
> > memmap=exactmap is specified, the kernel should ignore any memory
> > information from the firmware.
>
> OK
>
> Baoquan, please modify your patch to get rid of the #ifdef CONFIG_X86 in
> acpi_memory_hotplug_init(). For example, you can add a function returning true
> if use_exactmap is set and false otherwise and make acpi_memory_hotplug_init()
> call that function. Alternatively, you can define arch-independent
> no_memory_hotplug (instead of use_exactmap) and set if for memmap=exactmap.
>
Prarit sent a patch to introduce no_memory_hotplug command line. I still
think that memmap=exactmap does not necessarily mean that memory hotplug
is disabled.
What about mem= parameter. If somebody specifies mem=1G, should that mean
there can not be any hotplugged memory.
I think we should atleast define a new command line parameter to disable
memory hotplug. After that users can specify both memmap=exactmap and
"no_mem_hotplug" on command line and control the behavior of kernel.
Thanks
Vivek
next prev parent reply other threads:[~2014-01-09 14:54 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-08 15:26 kdump failed because of hotplug memory adding in kdump kernel Baoquan
2014-01-08 15:26 ` Baoquan
2014-01-08 15:58 ` Vivek Goyal
2014-01-08 15:58 ` Vivek Goyal
2014-01-08 15:58 ` Vivek Goyal
2014-01-08 23:07 ` Rafael J. Wysocki
2014-01-08 23:07 ` Rafael J. Wysocki
2014-01-08 23:07 ` Rafael J. Wysocki
2014-01-09 0:11 ` Toshi Kani
2014-01-09 0:11 ` Toshi Kani
2014-01-09 13:10 ` Rafael J. Wysocki
2014-01-09 13:10 ` Rafael J. Wysocki
2014-01-09 14:53 ` Vivek Goyal [this message]
2014-01-09 14:53 ` Vivek Goyal
2014-01-09 14:53 ` Vivek Goyal
2014-01-09 16:15 ` Toshi Kani
2014-01-09 16:15 ` Toshi Kani
2014-01-09 16:15 ` Toshi Kani
2014-01-09 14:50 ` Vivek Goyal
2014-01-09 14:50 ` Vivek Goyal
2014-01-09 16:03 ` Toshi Kani
2014-01-09 16:03 ` Toshi Kani
2014-01-09 16:24 ` Vivek Goyal
2014-01-09 16:24 ` Vivek Goyal
2014-01-09 16:24 ` Vivek Goyal
2014-01-09 17:24 ` Toshi Kani
2014-01-09 17:24 ` Toshi Kani
2014-01-09 17:24 ` Toshi Kani
2014-01-09 18:23 ` Vivek Goyal
2014-01-09 18:23 ` Vivek Goyal
2014-01-09 18:23 ` Vivek Goyal
2014-01-09 18:34 ` Toshi Kani
2014-01-09 18:34 ` Toshi Kani
2014-01-09 21:27 ` Vivek Goyal
2014-01-09 21:27 ` Vivek Goyal
2014-01-09 21:27 ` Vivek Goyal
2014-01-09 21:56 ` Toshi Kani
2014-01-09 21:56 ` Toshi Kani
2014-01-10 7:11 ` Baoquan
2014-01-10 7:11 ` Baoquan
2014-01-10 8:06 ` Yasuaki Ishimatsu
2014-01-10 8:06 ` Yasuaki Ishimatsu
2014-01-10 8:06 ` Yasuaki Ishimatsu
2014-01-10 9:14 ` Baoquan
2014-01-10 9:14 ` Baoquan
2014-01-10 9:14 ` Baoquan
2014-01-10 9:35 ` Yasuaki Ishimatsu
2014-01-10 9:35 ` Yasuaki Ishimatsu
2014-01-10 9:35 ` Yasuaki Ishimatsu
2014-01-10 10:27 ` Baoquan
2014-01-10 10:27 ` Baoquan
2014-01-10 10:27 ` Baoquan
2014-01-10 15:19 ` Toshi Kani
2014-01-10 15:19 ` Toshi Kani
2014-01-10 15:56 ` Toshi Kani
2014-01-10 15:56 ` Toshi Kani
2014-01-10 1:40 ` Rafael J. Wysocki
2014-01-10 1:40 ` Rafael J. Wysocki
2014-01-09 3:22 ` Baoquan
2014-01-09 3:22 ` Baoquan
2014-01-09 14:48 ` Vivek Goyal
2014-01-09 14:48 ` Vivek Goyal
2014-01-09 14:48 ` Vivek Goyal
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=20140109145359.GC25897@redhat.com \
--to=vgoyal@redhat.com \
--cc=bhe@redhat.com \
--cc=dyoung@redhat.com \
--cc=kexec@lists.infradead.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=tangchen@cn.fujitsu.com \
--cc=toshi.kani@hp.com \
--cc=zhangyanfei@cn.fujitsu.com \
/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.