From: Mike Rapoport <rppt@kernel.org>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: David Hildenbrand <david@redhat.com>,
Catalin Marinas <catalin.marinas@arm.com>,
linux-kernel@vger.kernel.org, Mike Rapoport <rppt@linux.ibm.com>,
linux-mm@kvack.org, kvmarm@lists.cs.columbia.edu,
Marc Zyngier <maz@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 4/4] arm64: drop pfn_valid_within() and simplify pfn_valid()
Date: Wed, 21 Apr 2021 15:24:01 +0300 [thread overview]
Message-ID: <YIAZYVI/HZWBr7BI@kernel.org> (raw)
In-Reply-To: <66d50afe-77e6-70ee-6b51-5db28a086c68@arm.com>
On Wed, Apr 21, 2021 at 04:36:46PM +0530, Anshuman Khandual wrote:
>
> On 4/21/21 12:21 PM, Mike Rapoport wrote:
> > From: Mike Rapoport <rppt@linux.ibm.com>
> >
> > The arm64's version of pfn_valid() differs from the generic because of two
> > reasons:
> >
> > * Parts of the memory map are freed during boot. This makes it necessary to
> > verify that there is actual physical memory that corresponds to a pfn
> > which is done by querying memblock.
> >
> > * There are NOMAP memory regions. These regions are not mapped in the
> > linear map and until the previous commit the struct pages representing
> > these areas had default values.
> >
> > As the consequence of absence of the special treatment of NOMAP regions in
> > the memory map it was necessary to use memblock_is_map_memory() in
> > pfn_valid() and to have pfn_valid_within() aliased to pfn_valid() so that
> > generic mm functionality would not treat a NOMAP page as a normal page.
> >
> > Since the NOMAP regions are now marked as PageReserved(), pfn walkers and
> > the rest of core mm will treat them as unusable memory and thus
> > pfn_valid_within() is no longer required at all and can be disabled by
> > removing CONFIG_HOLES_IN_ZONE on arm64.
>
> This makes sense.
>
> >
> > pfn_valid() can be slightly simplified by replacing
> > memblock_is_map_memory() with memblock_is_memory().
> >
> > Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> > ---
> > arch/arm64/Kconfig | 3 ---
> > arch/arm64/mm/init.c | 4 ++--
> > 2 files changed, 2 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index e4e1b6550115..58e439046d05 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -1040,9 +1040,6 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
> > def_bool y
> > depends on NUMA
> >
> > -config HOLES_IN_ZONE
> > - def_bool y
> > -
>
> Right.
>
> > source "kernel/Kconfig.hz"
> >
> > config ARCH_SPARSEMEM_ENABLE
> > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > index dc03bdc12c0f..eb3f56fb8c7c 100644
> > --- a/arch/arm64/mm/init.c
> > +++ b/arch/arm64/mm/init.c
> > @@ -243,7 +243,7 @@ int pfn_valid(unsigned long pfn)
> >
> > /*
> > * ZONE_DEVICE memory does not have the memblock entries.
> > - * memblock_is_map_memory() check for ZONE_DEVICE based
> > + * memblock_is_memory() check for ZONE_DEVICE based
> > * addresses will always fail. Even the normal hotplugged
> > * memory will never have MEMBLOCK_NOMAP flag set in their
> > * memblock entries. Skip memblock search for all non early
> > @@ -254,7 +254,7 @@ int pfn_valid(unsigned long pfn)
> > return pfn_section_valid(ms, pfn);
> > }
> > #endif
> > - return memblock_is_map_memory(addr);
> > + return memblock_is_memory(addr);
>
> Wondering if MEMBLOCK_NOMAP is now being treated similarly to other
> memory pfns for page table walking purpose but with PageReserved(),
> why memblock_is_memory() is still required ? At this point, should
> not we just return valid for early_section() memory. As pfn_valid()
> now just implies that pfn has a struct page backing which has been
> already verified with valid_section() etc.
memblock_is_memory() is required because arm64 frees unused parts of the
memory map. So, for instance, if we have 64M out of 128M populated in a
section the section based calculation would return 1 for a pfn in the
second half of the section, but there would be no memory map there.
> > }
> > EXPORT_SYMBOL(pfn_valid);
> >
> >
--
Sincerely yours,
Mike.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@kernel.org>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
Andrew Morton <akpm@linux-foundation.org>,
Ard Biesheuvel <ardb@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
David Hildenbrand <david@redhat.com>,
Marc Zyngier <maz@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Mike Rapoport <rppt@linux.ibm.com>, Will Deacon <will@kernel.org>,
kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH v2 4/4] arm64: drop pfn_valid_within() and simplify pfn_valid()
Date: Wed, 21 Apr 2021 15:24:01 +0300 [thread overview]
Message-ID: <YIAZYVI/HZWBr7BI@kernel.org> (raw)
In-Reply-To: <66d50afe-77e6-70ee-6b51-5db28a086c68@arm.com>
On Wed, Apr 21, 2021 at 04:36:46PM +0530, Anshuman Khandual wrote:
>
> On 4/21/21 12:21 PM, Mike Rapoport wrote:
> > From: Mike Rapoport <rppt@linux.ibm.com>
> >
> > The arm64's version of pfn_valid() differs from the generic because of two
> > reasons:
> >
> > * Parts of the memory map are freed during boot. This makes it necessary to
> > verify that there is actual physical memory that corresponds to a pfn
> > which is done by querying memblock.
> >
> > * There are NOMAP memory regions. These regions are not mapped in the
> > linear map and until the previous commit the struct pages representing
> > these areas had default values.
> >
> > As the consequence of absence of the special treatment of NOMAP regions in
> > the memory map it was necessary to use memblock_is_map_memory() in
> > pfn_valid() and to have pfn_valid_within() aliased to pfn_valid() so that
> > generic mm functionality would not treat a NOMAP page as a normal page.
> >
> > Since the NOMAP regions are now marked as PageReserved(), pfn walkers and
> > the rest of core mm will treat them as unusable memory and thus
> > pfn_valid_within() is no longer required at all and can be disabled by
> > removing CONFIG_HOLES_IN_ZONE on arm64.
>
> This makes sense.
>
> >
> > pfn_valid() can be slightly simplified by replacing
> > memblock_is_map_memory() with memblock_is_memory().
> >
> > Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> > ---
> > arch/arm64/Kconfig | 3 ---
> > arch/arm64/mm/init.c | 4 ++--
> > 2 files changed, 2 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index e4e1b6550115..58e439046d05 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -1040,9 +1040,6 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
> > def_bool y
> > depends on NUMA
> >
> > -config HOLES_IN_ZONE
> > - def_bool y
> > -
>
> Right.
>
> > source "kernel/Kconfig.hz"
> >
> > config ARCH_SPARSEMEM_ENABLE
> > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > index dc03bdc12c0f..eb3f56fb8c7c 100644
> > --- a/arch/arm64/mm/init.c
> > +++ b/arch/arm64/mm/init.c
> > @@ -243,7 +243,7 @@ int pfn_valid(unsigned long pfn)
> >
> > /*
> > * ZONE_DEVICE memory does not have the memblock entries.
> > - * memblock_is_map_memory() check for ZONE_DEVICE based
> > + * memblock_is_memory() check for ZONE_DEVICE based
> > * addresses will always fail. Even the normal hotplugged
> > * memory will never have MEMBLOCK_NOMAP flag set in their
> > * memblock entries. Skip memblock search for all non early
> > @@ -254,7 +254,7 @@ int pfn_valid(unsigned long pfn)
> > return pfn_section_valid(ms, pfn);
> > }
> > #endif
> > - return memblock_is_map_memory(addr);
> > + return memblock_is_memory(addr);
>
> Wondering if MEMBLOCK_NOMAP is now being treated similarly to other
> memory pfns for page table walking purpose but with PageReserved(),
> why memblock_is_memory() is still required ? At this point, should
> not we just return valid for early_section() memory. As pfn_valid()
> now just implies that pfn has a struct page backing which has been
> already verified with valid_section() etc.
memblock_is_memory() is required because arm64 frees unused parts of the
memory map. So, for instance, if we have 64M out of 128M populated in a
section the section based calculation would return 1 for a pfn in the
second half of the section, but there would be no memory map there.
> > }
> > EXPORT_SYMBOL(pfn_valid);
> >
> >
--
Sincerely yours,
Mike.
_______________________________________________
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: Mike Rapoport <rppt@kernel.org>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
Andrew Morton <akpm@linux-foundation.org>,
Ard Biesheuvel <ardb@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
David Hildenbrand <david@redhat.com>,
Marc Zyngier <maz@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Mike Rapoport <rppt@linux.ibm.com>, Will Deacon <will@kernel.org>,
kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH v2 4/4] arm64: drop pfn_valid_within() and simplify pfn_valid()
Date: Wed, 21 Apr 2021 15:24:01 +0300 [thread overview]
Message-ID: <YIAZYVI/HZWBr7BI@kernel.org> (raw)
In-Reply-To: <66d50afe-77e6-70ee-6b51-5db28a086c68@arm.com>
On Wed, Apr 21, 2021 at 04:36:46PM +0530, Anshuman Khandual wrote:
>
> On 4/21/21 12:21 PM, Mike Rapoport wrote:
> > From: Mike Rapoport <rppt@linux.ibm.com>
> >
> > The arm64's version of pfn_valid() differs from the generic because of two
> > reasons:
> >
> > * Parts of the memory map are freed during boot. This makes it necessary to
> > verify that there is actual physical memory that corresponds to a pfn
> > which is done by querying memblock.
> >
> > * There are NOMAP memory regions. These regions are not mapped in the
> > linear map and until the previous commit the struct pages representing
> > these areas had default values.
> >
> > As the consequence of absence of the special treatment of NOMAP regions in
> > the memory map it was necessary to use memblock_is_map_memory() in
> > pfn_valid() and to have pfn_valid_within() aliased to pfn_valid() so that
> > generic mm functionality would not treat a NOMAP page as a normal page.
> >
> > Since the NOMAP regions are now marked as PageReserved(), pfn walkers and
> > the rest of core mm will treat them as unusable memory and thus
> > pfn_valid_within() is no longer required at all and can be disabled by
> > removing CONFIG_HOLES_IN_ZONE on arm64.
>
> This makes sense.
>
> >
> > pfn_valid() can be slightly simplified by replacing
> > memblock_is_map_memory() with memblock_is_memory().
> >
> > Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> > ---
> > arch/arm64/Kconfig | 3 ---
> > arch/arm64/mm/init.c | 4 ++--
> > 2 files changed, 2 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index e4e1b6550115..58e439046d05 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -1040,9 +1040,6 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
> > def_bool y
> > depends on NUMA
> >
> > -config HOLES_IN_ZONE
> > - def_bool y
> > -
>
> Right.
>
> > source "kernel/Kconfig.hz"
> >
> > config ARCH_SPARSEMEM_ENABLE
> > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > index dc03bdc12c0f..eb3f56fb8c7c 100644
> > --- a/arch/arm64/mm/init.c
> > +++ b/arch/arm64/mm/init.c
> > @@ -243,7 +243,7 @@ int pfn_valid(unsigned long pfn)
> >
> > /*
> > * ZONE_DEVICE memory does not have the memblock entries.
> > - * memblock_is_map_memory() check for ZONE_DEVICE based
> > + * memblock_is_memory() check for ZONE_DEVICE based
> > * addresses will always fail. Even the normal hotplugged
> > * memory will never have MEMBLOCK_NOMAP flag set in their
> > * memblock entries. Skip memblock search for all non early
> > @@ -254,7 +254,7 @@ int pfn_valid(unsigned long pfn)
> > return pfn_section_valid(ms, pfn);
> > }
> > #endif
> > - return memblock_is_map_memory(addr);
> > + return memblock_is_memory(addr);
>
> Wondering if MEMBLOCK_NOMAP is now being treated similarly to other
> memory pfns for page table walking purpose but with PageReserved(),
> why memblock_is_memory() is still required ? At this point, should
> not we just return valid for early_section() memory. As pfn_valid()
> now just implies that pfn has a struct page backing which has been
> already verified with valid_section() etc.
memblock_is_memory() is required because arm64 frees unused parts of the
memory map. So, for instance, if we have 64M out of 128M populated in a
section the section based calculation would return 1 for a pfn in the
second half of the section, but there would be no memory map there.
> > }
> > EXPORT_SYMBOL(pfn_valid);
> >
> >
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2021-04-21 12:24 UTC|newest]
Thread overview: 143+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-21 6:51 [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid() Mike Rapoport
2021-04-21 6:51 ` Mike Rapoport
2021-04-21 6:51 ` Mike Rapoport
2021-04-21 6:51 ` [PATCH v2 1/4] include/linux/mmzone.h: add documentation for pfn_valid() Mike Rapoport
2021-04-21 6:51 ` Mike Rapoport
2021-04-21 6:51 ` Mike Rapoport
2021-04-21 10:49 ` Anshuman Khandual
2021-04-21 10:49 ` Anshuman Khandual
2021-04-21 10:49 ` Anshuman Khandual
2021-04-21 6:51 ` [PATCH v2 2/4] memblock: update initialization of reserved pages Mike Rapoport
2021-04-21 6:51 ` Mike Rapoport
2021-04-21 6:51 ` Mike Rapoport
2021-04-21 7:49 ` David Hildenbrand
2021-04-21 7:49 ` David Hildenbrand
2021-04-21 7:49 ` David Hildenbrand
2021-04-21 10:51 ` Anshuman Khandual
2021-04-21 10:51 ` Anshuman Khandual
2021-04-21 10:51 ` Anshuman Khandual
2021-04-21 6:51 ` [PATCH v2 3/4] arm64: decouple check whether pfn is in linear map from pfn_valid() Mike Rapoport
2021-04-21 6:51 ` Mike Rapoport
2021-04-21 6:51 ` Mike Rapoport
2021-04-21 10:59 ` Anshuman Khandual
2021-04-21 10:59 ` Anshuman Khandual
2021-04-21 10:59 ` Anshuman Khandual
2021-04-21 12:19 ` Mike Rapoport
2021-04-21 12:19 ` Mike Rapoport
2021-04-21 12:19 ` Mike Rapoport
2021-04-21 13:13 ` Anshuman Khandual
2021-04-21 13:13 ` Anshuman Khandual
2021-04-21 13:13 ` Anshuman Khandual
2021-04-21 6:51 ` [PATCH v2 4/4] arm64: drop pfn_valid_within() and simplify pfn_valid() Mike Rapoport
2021-04-21 6:51 ` Mike Rapoport
2021-04-21 6:51 ` Mike Rapoport
2021-04-21 7:49 ` David Hildenbrand
2021-04-21 7:49 ` David Hildenbrand
2021-04-21 7:49 ` David Hildenbrand
2021-04-21 11:06 ` Anshuman Khandual
2021-04-21 11:06 ` Anshuman Khandual
2021-04-21 11:06 ` Anshuman Khandual
2021-04-21 12:24 ` Mike Rapoport [this message]
2021-04-21 12:24 ` Mike Rapoport
2021-04-21 12:24 ` Mike Rapoport
2021-04-21 13:15 ` Anshuman Khandual
2021-04-21 13:15 ` Anshuman Khandual
2021-04-21 13:15 ` Anshuman Khandual
2021-04-22 7:00 ` [PATCH v2 0/4] " Kefeng Wang
2021-04-22 7:00 ` Kefeng Wang
2021-04-22 7:00 ` Kefeng Wang
2021-04-22 7:29 ` Mike Rapoport
2021-04-22 7:29 ` Mike Rapoport
2021-04-22 7:29 ` Mike Rapoport
2021-04-22 15:28 ` Kefeng Wang
2021-04-22 15:28 ` Kefeng Wang
2021-04-22 15:28 ` Kefeng Wang
2021-04-23 8:11 ` Kefeng Wang
2021-04-23 8:11 ` Kefeng Wang
2021-04-23 8:11 ` Kefeng Wang
2021-04-25 7:19 ` arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid()) Mike Rapoport
2021-04-25 7:19 ` Mike Rapoport
2021-04-25 7:19 ` Mike Rapoport
2021-04-25 7:51 ` Kefeng Wang
2021-04-25 7:51 ` Kefeng Wang
2021-04-26 5:20 ` Mike Rapoport
2021-04-26 5:20 ` Mike Rapoport
2021-04-26 5:20 ` Mike Rapoport
2021-04-26 15:26 ` Kefeng Wang
2021-04-26 15:26 ` Kefeng Wang
2021-04-26 15:26 ` Kefeng Wang
2021-04-27 6:23 ` Mike Rapoport
2021-04-27 6:23 ` Mike Rapoport
2021-04-27 6:23 ` Mike Rapoport
2021-04-27 11:08 ` Kefeng Wang
2021-04-27 11:08 ` Kefeng Wang
2021-04-27 11:08 ` Kefeng Wang
2021-04-28 5:59 ` Mike Rapoport
2021-04-28 5:59 ` Mike Rapoport
2021-04-28 5:59 ` Mike Rapoport
2021-04-29 0:48 ` Kefeng Wang
2021-04-29 0:48 ` Kefeng Wang
2021-04-29 0:48 ` Kefeng Wang
2021-04-29 6:57 ` Mike Rapoport
2021-04-29 6:57 ` Mike Rapoport
2021-04-29 6:57 ` Mike Rapoport
2021-04-29 10:22 ` Kefeng Wang
2021-04-29 10:22 ` Kefeng Wang
2021-04-29 10:22 ` Kefeng Wang
2021-04-30 9:51 ` Mike Rapoport
2021-04-30 9:51 ` Mike Rapoport
2021-04-30 9:51 ` Mike Rapoport
2021-04-30 11:24 ` Kefeng Wang
2021-04-30 11:24 ` Kefeng Wang
2021-04-30 11:24 ` Kefeng Wang
2021-05-03 6:26 ` Mike Rapoport
2021-05-03 6:26 ` Mike Rapoport
2021-05-03 6:26 ` Mike Rapoport
2021-05-03 8:07 ` David Hildenbrand
2021-05-03 8:07 ` David Hildenbrand
2021-05-03 8:07 ` David Hildenbrand
2021-05-03 8:44 ` Mike Rapoport
2021-05-03 8:44 ` Mike Rapoport
2021-05-03 8:44 ` Mike Rapoport
2021-05-06 12:47 ` Kefeng Wang
2021-05-06 12:47 ` Kefeng Wang
2021-05-06 12:47 ` Kefeng Wang
2021-05-07 7:17 ` Kefeng Wang
2021-05-07 7:17 ` Kefeng Wang
2021-05-07 7:17 ` Kefeng Wang
2021-05-07 10:30 ` Mike Rapoport
2021-05-07 10:30 ` Mike Rapoport
2021-05-07 10:30 ` Mike Rapoport
2021-05-07 12:34 ` Kefeng Wang
2021-05-07 12:34 ` Kefeng Wang
2021-05-07 12:34 ` Kefeng Wang
2021-05-09 5:59 ` Mike Rapoport
2021-05-09 5:59 ` Mike Rapoport
2021-05-09 5:59 ` Mike Rapoport
2021-05-10 3:10 ` Kefeng Wang
2021-05-10 3:10 ` Kefeng Wang
2021-05-10 3:10 ` Kefeng Wang
2021-05-11 8:48 ` Mike Rapoport
2021-05-11 8:48 ` Mike Rapoport
2021-05-11 8:48 ` Mike Rapoport
2021-05-12 3:08 ` Kefeng Wang
2021-05-12 3:08 ` Kefeng Wang
2021-05-12 3:08 ` Kefeng Wang
2021-05-12 8:26 ` Mike Rapoport
2021-05-12 8:26 ` Mike Rapoport
2021-05-12 8:26 ` Mike Rapoport
2021-05-13 3:44 ` Kefeng Wang
2021-05-13 3:44 ` Kefeng Wang
2021-05-13 3:44 ` Kefeng Wang
2021-05-13 10:55 ` Mike Rapoport
2021-05-13 10:55 ` Mike Rapoport
2021-05-13 10:55 ` Mike Rapoport
2021-05-14 2:18 ` Kefeng Wang
2021-05-14 2:18 ` Kefeng Wang
2021-05-14 2:18 ` Kefeng Wang
2021-05-12 3:50 ` Matthew Wilcox
2021-05-12 3:50 ` Matthew Wilcox
2021-05-12 3:50 ` Matthew Wilcox
2021-04-25 6:59 ` [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid() Mike Rapoport
2021-04-25 6:59 ` Mike Rapoport
2021-04-25 6:59 ` Mike Rapoport
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=YIAZYVI/HZWBr7BI@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=catalin.marinas@arm.com \
--cc=david@redhat.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=maz@kernel.org \
--cc=rppt@linux.ibm.com \
--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.