All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: Chen Zhou <chenzhou10@huawei.com>
Cc: tglx@linutronix.de, mingo@redhat.com, catalin.marinas@arm.com,
	will@kernel.org, dyoung@redhat.com, robh+dt@kernel.org,
	John.p.donnelly@oracle.com, arnd@arndb.de,
	devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	horms@verge.net.au, guohanjun@huawei.com, pkushwaha@marvell.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v8 2/5] arm64: kdump: reserve crashkenel above 4G for crash dump kernel
Date: Tue, 26 May 2020 08:59:04 +0800	[thread overview]
Message-ID: <20200526005904.GE20045@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20200521093805.64398-3-chenzhou10@huawei.com>

On 05/21/20 at 05:38pm, Chen Zhou wrote:
> Crashkernel=X tries to reserve memory for the crash dump kernel under
> 4G. If crashkernel=X,low is specified simultaneously, reserve spcified
> size low memory for crash kdump kernel devices firstly and then reserve
> memory above 4G.

Wondering why crashkernel=,high is not introduced to arm64 to be
consistent with x86_64, to make the behaviour be the same on all
architecutres. 

> 
> Signed-off-by: Chen Zhou <chenzhou10@huawei.com>
> Tested-by: John Donnelly <John.p.donnelly@oracle.com>
> Tested-by: Prabhakar Kushwaha <pkushwaha@marvell.com>
> ---
>  arch/arm64/kernel/setup.c |  8 +++++++-
>  arch/arm64/mm/init.c      | 31 +++++++++++++++++++++++++++++--
>  2 files changed, 36 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index 3fd2c11c09fc..a8487e4d3e5a 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -238,7 +238,13 @@ static void __init request_standard_resources(void)
>  		    kernel_data.end <= res->end)
>  			request_resource(res, &kernel_data);
>  #ifdef CONFIG_KEXEC_CORE
> -		/* Userspace will find "Crash kernel" region in /proc/iomem. */
> +		/*
> +		 * Userspace will find "Crash kernel" region in /proc/iomem.
> +		 * Note: the low region is renamed as Crash kernel (low).
> +		 */
> +		if (crashk_low_res.end && crashk_low_res.start >= res->start &&
> +				crashk_low_res.end <= res->end)
> +			request_resource(res, &crashk_low_res);
>  		if (crashk_res.end && crashk_res.start >= res->start &&
>  		    crashk_res.end <= res->end)
>  			request_resource(res, &crashk_res);
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index e42727e3568e..71498acf0cd8 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -81,6 +81,7 @@ static void __init reserve_crashkernel(void)
>  {
>  	unsigned long long crash_base, crash_size;
>  	int ret;
> +	phys_addr_t crash_max = arm64_dma32_phys_limit;
>  
>  	ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
>  				&crash_size, &crash_base);
> @@ -88,12 +89,38 @@ static void __init reserve_crashkernel(void)
>  	if (ret || !crash_size)
>  		return;
>  
> +	ret = reserve_crashkernel_low();
> +	if (!ret && crashk_low_res.end) {
> +		/*
> +		 * If crashkernel=X,low specified, there may be two regions,
> +		 * we need to make some changes as follows:
> +		 *
> +		 * 1. rename the low region as "Crash kernel (low)"
> +		 * In order to distinct from the high region and make no effect
> +		 * to the use of existing kexec-tools, rename the low region as
> +		 * "Crash kernel (low)".
> +		 *
> +		 * 2. change the upper bound for crash memory
> +		 * Set MEMBLOCK_ALLOC_ACCESSIBLE upper bound for crash memory.
> +		 *
> +		 * 3. mark the low region as "nomap"
> +		 * The low region is intended to be used for crash dump kernel
> +		 * devices, just mark the low region as "nomap" simply.
> +		 */
> +		const char *rename = "Crash kernel (low)";
> +
> +		crashk_low_res.name = rename;
> +		crash_max = MEMBLOCK_ALLOC_ACCESSIBLE;
> +		memblock_mark_nomap(crashk_low_res.start,
> +				    resource_size(&crashk_low_res));
> +	}
> +
>  	crash_size = PAGE_ALIGN(crash_size);
>  
>  	if (crash_base == 0) {
>  		/* Current arm64 boot protocol requires 2MB alignment */
> -		crash_base = memblock_find_in_range(0, arm64_dma32_phys_limit,
> -				crash_size, SZ_2M);
> +		crash_base = memblock_find_in_range(0, crash_max, crash_size,
> +				SZ_2M);
>  		if (crash_base == 0) {
>  			pr_warn("cannot allocate crashkernel (size:0x%llx)\n",
>  				crash_size);
> -- 
> 2.20.1
> 
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 


WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Chen Zhou <chenzhou10@huawei.com>
Cc: horms@verge.net.au, John.p.donnelly@oracle.com, arnd@arndb.de,
	will@kernel.org, devicetree@vger.kernel.org,
	catalin.marinas@arm.com, linux-doc@vger.kernel.org,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	robh+dt@kernel.org, mingo@redhat.com, guohanjun@huawei.com,
	tglx@linutronix.de, pkushwaha@marvell.com, dyoung@redhat.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v8 2/5] arm64: kdump: reserve crashkenel above 4G for crash dump kernel
Date: Tue, 26 May 2020 08:59:04 +0800	[thread overview]
Message-ID: <20200526005904.GE20045@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20200521093805.64398-3-chenzhou10@huawei.com>

On 05/21/20 at 05:38pm, Chen Zhou wrote:
> Crashkernel=X tries to reserve memory for the crash dump kernel under
> 4G. If crashkernel=X,low is specified simultaneously, reserve spcified
> size low memory for crash kdump kernel devices firstly and then reserve
> memory above 4G.

Wondering why crashkernel=,high is not introduced to arm64 to be
consistent with x86_64, to make the behaviour be the same on all
architecutres. 

> 
> Signed-off-by: Chen Zhou <chenzhou10@huawei.com>
> Tested-by: John Donnelly <John.p.donnelly@oracle.com>
> Tested-by: Prabhakar Kushwaha <pkushwaha@marvell.com>
> ---
>  arch/arm64/kernel/setup.c |  8 +++++++-
>  arch/arm64/mm/init.c      | 31 +++++++++++++++++++++++++++++--
>  2 files changed, 36 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index 3fd2c11c09fc..a8487e4d3e5a 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -238,7 +238,13 @@ static void __init request_standard_resources(void)
>  		    kernel_data.end <= res->end)
>  			request_resource(res, &kernel_data);
>  #ifdef CONFIG_KEXEC_CORE
> -		/* Userspace will find "Crash kernel" region in /proc/iomem. */
> +		/*
> +		 * Userspace will find "Crash kernel" region in /proc/iomem.
> +		 * Note: the low region is renamed as Crash kernel (low).
> +		 */
> +		if (crashk_low_res.end && crashk_low_res.start >= res->start &&
> +				crashk_low_res.end <= res->end)
> +			request_resource(res, &crashk_low_res);
>  		if (crashk_res.end && crashk_res.start >= res->start &&
>  		    crashk_res.end <= res->end)
>  			request_resource(res, &crashk_res);
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index e42727e3568e..71498acf0cd8 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -81,6 +81,7 @@ static void __init reserve_crashkernel(void)
>  {
>  	unsigned long long crash_base, crash_size;
>  	int ret;
> +	phys_addr_t crash_max = arm64_dma32_phys_limit;
>  
>  	ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
>  				&crash_size, &crash_base);
> @@ -88,12 +89,38 @@ static void __init reserve_crashkernel(void)
>  	if (ret || !crash_size)
>  		return;
>  
> +	ret = reserve_crashkernel_low();
> +	if (!ret && crashk_low_res.end) {
> +		/*
> +		 * If crashkernel=X,low specified, there may be two regions,
> +		 * we need to make some changes as follows:
> +		 *
> +		 * 1. rename the low region as "Crash kernel (low)"
> +		 * In order to distinct from the high region and make no effect
> +		 * to the use of existing kexec-tools, rename the low region as
> +		 * "Crash kernel (low)".
> +		 *
> +		 * 2. change the upper bound for crash memory
> +		 * Set MEMBLOCK_ALLOC_ACCESSIBLE upper bound for crash memory.
> +		 *
> +		 * 3. mark the low region as "nomap"
> +		 * The low region is intended to be used for crash dump kernel
> +		 * devices, just mark the low region as "nomap" simply.
> +		 */
> +		const char *rename = "Crash kernel (low)";
> +
> +		crashk_low_res.name = rename;
> +		crash_max = MEMBLOCK_ALLOC_ACCESSIBLE;
> +		memblock_mark_nomap(crashk_low_res.start,
> +				    resource_size(&crashk_low_res));
> +	}
> +
>  	crash_size = PAGE_ALIGN(crash_size);
>  
>  	if (crash_base == 0) {
>  		/* Current arm64 boot protocol requires 2MB alignment */
> -		crash_base = memblock_find_in_range(0, arm64_dma32_phys_limit,
> -				crash_size, SZ_2M);
> +		crash_base = memblock_find_in_range(0, crash_max, crash_size,
> +				SZ_2M);
>  		if (crash_base == 0) {
>  			pr_warn("cannot allocate crashkernel (size:0x%llx)\n",
>  				crash_size);
> -- 
> 2.20.1
> 
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Chen Zhou <chenzhou10@huawei.com>
Cc: horms@verge.net.au, John.p.donnelly@oracle.com, arnd@arndb.de,
	will@kernel.org, devicetree@vger.kernel.org,
	catalin.marinas@arm.com, linux-doc@vger.kernel.org,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	robh+dt@kernel.org, mingo@redhat.com, guohanjun@huawei.com,
	tglx@linutronix.de, pkushwaha@marvell.com, dyoung@redhat.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v8 2/5] arm64: kdump: reserve crashkenel above 4G for crash dump kernel
Date: Tue, 26 May 2020 08:59:04 +0800	[thread overview]
Message-ID: <20200526005904.GE20045@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20200521093805.64398-3-chenzhou10@huawei.com>

On 05/21/20 at 05:38pm, Chen Zhou wrote:
> Crashkernel=X tries to reserve memory for the crash dump kernel under
> 4G. If crashkernel=X,low is specified simultaneously, reserve spcified
> size low memory for crash kdump kernel devices firstly and then reserve
> memory above 4G.

Wondering why crashkernel=,high is not introduced to arm64 to be
consistent with x86_64, to make the behaviour be the same on all
architecutres. 

> 
> Signed-off-by: Chen Zhou <chenzhou10@huawei.com>
> Tested-by: John Donnelly <John.p.donnelly@oracle.com>
> Tested-by: Prabhakar Kushwaha <pkushwaha@marvell.com>
> ---
>  arch/arm64/kernel/setup.c |  8 +++++++-
>  arch/arm64/mm/init.c      | 31 +++++++++++++++++++++++++++++--
>  2 files changed, 36 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index 3fd2c11c09fc..a8487e4d3e5a 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -238,7 +238,13 @@ static void __init request_standard_resources(void)
>  		    kernel_data.end <= res->end)
>  			request_resource(res, &kernel_data);
>  #ifdef CONFIG_KEXEC_CORE
> -		/* Userspace will find "Crash kernel" region in /proc/iomem. */
> +		/*
> +		 * Userspace will find "Crash kernel" region in /proc/iomem.
> +		 * Note: the low region is renamed as Crash kernel (low).
> +		 */
> +		if (crashk_low_res.end && crashk_low_res.start >= res->start &&
> +				crashk_low_res.end <= res->end)
> +			request_resource(res, &crashk_low_res);
>  		if (crashk_res.end && crashk_res.start >= res->start &&
>  		    crashk_res.end <= res->end)
>  			request_resource(res, &crashk_res);
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index e42727e3568e..71498acf0cd8 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -81,6 +81,7 @@ static void __init reserve_crashkernel(void)
>  {
>  	unsigned long long crash_base, crash_size;
>  	int ret;
> +	phys_addr_t crash_max = arm64_dma32_phys_limit;
>  
>  	ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
>  				&crash_size, &crash_base);
> @@ -88,12 +89,38 @@ static void __init reserve_crashkernel(void)
>  	if (ret || !crash_size)
>  		return;
>  
> +	ret = reserve_crashkernel_low();
> +	if (!ret && crashk_low_res.end) {
> +		/*
> +		 * If crashkernel=X,low specified, there may be two regions,
> +		 * we need to make some changes as follows:
> +		 *
> +		 * 1. rename the low region as "Crash kernel (low)"
> +		 * In order to distinct from the high region and make no effect
> +		 * to the use of existing kexec-tools, rename the low region as
> +		 * "Crash kernel (low)".
> +		 *
> +		 * 2. change the upper bound for crash memory
> +		 * Set MEMBLOCK_ALLOC_ACCESSIBLE upper bound for crash memory.
> +		 *
> +		 * 3. mark the low region as "nomap"
> +		 * The low region is intended to be used for crash dump kernel
> +		 * devices, just mark the low region as "nomap" simply.
> +		 */
> +		const char *rename = "Crash kernel (low)";
> +
> +		crashk_low_res.name = rename;
> +		crash_max = MEMBLOCK_ALLOC_ACCESSIBLE;
> +		memblock_mark_nomap(crashk_low_res.start,
> +				    resource_size(&crashk_low_res));
> +	}
> +
>  	crash_size = PAGE_ALIGN(crash_size);
>  
>  	if (crash_base == 0) {
>  		/* Current arm64 boot protocol requires 2MB alignment */
> -		crash_base = memblock_find_in_range(0, arm64_dma32_phys_limit,
> -				crash_size, SZ_2M);
> +		crash_base = memblock_find_in_range(0, crash_max, crash_size,
> +				SZ_2M);
>  		if (crash_base == 0) {
>  			pr_warn("cannot allocate crashkernel (size:0x%llx)\n",
>  				crash_size);
> -- 
> 2.20.1
> 
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2020-05-26  0:59 UTC|newest]

Thread overview: 102+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-21  9:38 [PATCH v8 0/5] support reserving crashkernel above 4G on arm64 kdump Chen Zhou
2020-05-21  9:38 ` Chen Zhou
2020-05-21  9:38 ` Chen Zhou
2020-05-21  9:38 ` [PATCH v8 1/5] x86: kdump: move reserve_crashkernel_low() into crash_core.c Chen Zhou
2020-05-21  9:38   ` Chen Zhou
2020-05-21  9:38   ` Chen Zhou
2020-05-26  0:56   ` Baoquan He
2020-05-26  0:56     ` Baoquan He
2020-05-26  0:56     ` Baoquan He
2020-05-21  9:38 ` [PATCH v8 2/5] arm64: kdump: reserve crashkenel above 4G for crash dump kernel Chen Zhou
2020-05-21  9:38   ` Chen Zhou
2020-05-21  9:38   ` Chen Zhou
2020-05-26  0:59   ` Baoquan He [this message]
2020-05-26  0:59     ` Baoquan He
2020-05-26  0:59     ` Baoquan He
2020-05-21  9:38 ` [PATCH v8 3/5] arm64: kdump: add memory for devices by DT property, low-memory-range Chen Zhou
2020-05-21  9:38   ` Chen Zhou
2020-05-21  9:38   ` Chen Zhou
2020-05-21  9:38 ` [PATCH v8 4/5] kdump: update Documentation about crashkernel on arm64 Chen Zhou
2020-05-21  9:38   ` Chen Zhou
2020-05-21  9:38   ` Chen Zhou
2020-05-21  9:38 ` [PATCH v8 5/5] dt-bindings: chosen: Document linux,low-memory-range for arm64 kdump Chen Zhou
2020-05-21  9:38   ` [PATCH v8 5/5] dt-bindings: chosen: Document linux, low-memory-range " Chen Zhou
2020-05-21  9:38   ` Chen Zhou
2020-05-21 13:29   ` [PATCH v8 5/5] dt-bindings: chosen: Document linux,low-memory-range " Rob Herring
2020-05-21 13:29     ` [PATCH v8 5/5] dt-bindings: chosen: Document linux, low-memory-range " Rob Herring
2020-05-21 13:29     ` Rob Herring
2020-05-22  3:24     ` [PATCH v8 5/5] dt-bindings: chosen: Document linux,low-memory-range " chenzhou
2020-05-22  3:24       ` chenzhou
2020-05-22  3:24       ` chenzhou
2020-05-26 21:18       ` Rob Herring
2020-05-26 21:18         ` Rob Herring
2020-05-26 21:18         ` Rob Herring
2020-05-29 16:11         ` James Morse
2020-05-29 16:11           ` James Morse
2020-05-29 16:11           ` James Morse
2020-06-20  3:54           ` chenzhou
2020-06-20  3:54             ` chenzhou
2020-06-20  3:54             ` chenzhou
2020-05-26  1:42 ` [PATCH v8 0/5] support reserving crashkernel above 4G on " Baoquan He
2020-05-26  1:42   ` Baoquan He
2020-05-26  1:42   ` Baoquan He
2020-05-26  2:28   ` chenzhou
2020-05-26  2:28     ` chenzhou
2020-05-26  2:28     ` chenzhou
2020-05-28 22:20   ` John Donnelly
2020-05-28 22:20     ` John Donnelly
2020-05-28 22:20     ` John Donnelly
2020-05-29  8:05     ` Will Deacon
2020-05-29  8:05       ` Will Deacon
2020-05-29  8:05       ` Will Deacon
2020-06-01 12:02 ` Prabhakar Kushwaha
2020-06-01 12:02   ` Prabhakar Kushwaha
2020-06-01 12:02   ` Prabhakar Kushwaha
2020-06-01 19:30   ` John Donnelly
2020-06-01 19:30     ` John Donnelly
2020-06-01 19:30     ` John Donnelly
2020-06-01 21:02     ` Bhupesh Sharma
2020-06-01 21:02       ` Bhupesh Sharma
2020-06-01 21:02       ` Bhupesh Sharma
2020-06-01 21:59       ` John Donnelly
2020-06-01 21:59         ` John Donnelly
2020-06-01 21:59         ` John Donnelly
2020-06-02  5:38         ` Prabhakar Kushwaha
2020-06-02  5:38           ` Prabhakar Kushwaha
2020-06-02  5:38           ` Prabhakar Kushwaha
2020-06-02 14:41           ` John Donnelly
2020-06-02 14:41             ` John Donnelly
2020-06-02 14:41             ` John Donnelly
2020-06-03 11:47             ` Prabhakar Kushwaha
2020-06-03 11:47               ` Prabhakar Kushwaha
2020-06-03 11:47               ` Prabhakar Kushwaha
2020-06-03 13:20               ` chenzhou
2020-06-03 13:20                 ` chenzhou
2020-06-03 13:20                 ` chenzhou
2020-06-03 15:30                 ` John Donnelly
2020-06-03 15:30                   ` John Donnelly
2020-06-03 15:30                   ` John Donnelly
2020-06-03 19:47                   ` Bhupesh Sharma
2020-06-03 19:47                     ` Bhupesh Sharma
2020-06-03 19:47                     ` Bhupesh Sharma
2020-06-04  7:14                     ` Will Deacon
2020-06-04  7:14                       ` Will Deacon
2020-06-04  7:14                       ` Will Deacon
2020-06-04 17:01                     ` Nicolas Saenz Julienne
2020-06-04 17:01                       ` Nicolas Saenz Julienne
2020-06-04 17:01                       ` Nicolas Saenz Julienne
2020-06-05  2:26                       ` John Donnelly
2020-06-05  2:26                         ` John Donnelly
2020-06-05  2:26                         ` John Donnelly
2020-06-05  8:21                         ` Nicolas Saenz Julienne
2020-06-05  8:21                           ` Nicolas Saenz Julienne
2020-06-05  8:21                           ` Nicolas Saenz Julienne
2020-06-19  2:32                       ` John Donnelly
2020-06-19  2:32                         ` John Donnelly
2020-06-19  2:32                         ` John Donnelly
2020-06-19  8:21                         ` chenzhou
2020-06-19  8:21                           ` chenzhou
2020-06-19  8:21                           ` chenzhou
2020-06-20  0:01                           ` John Donnelly
2020-06-20  0:01                             ` John Donnelly
2020-06-20  0:01                             ` John Donnelly

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=20200526005904.GE20045@MiWiFi-R3L-srv \
    --to=bhe@redhat.com \
    --cc=John.p.donnelly@oracle.com \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=chenzhou10@huawei.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dyoung@redhat.com \
    --cc=guohanjun@huawei.com \
    --cc=horms@verge.net.au \
    --cc=kexec@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pkushwaha@marvell.com \
    --cc=robh+dt@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.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.