From: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
To: Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>
Cc: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
KAMEZAWA Hiroyuki
<kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>,
Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
Subject: Re: [PATCH] memcg: fix memcg_cache_name() to use cgroup_name()
Date: Fri, 22 Mar 2013 16:17:12 +0800 [thread overview]
Message-ID: <514C1388.6090909@huawei.com> (raw)
In-Reply-To: <20130322080749.GB31457-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
>>>>> @@ -3217,17 +3217,16 @@ void mem_cgroup_destroy_cache(struct kmem_cache *cachep)
>>>>> static char *memcg_cache_name(struct mem_cgroup *memcg, struct kmem_cache *s)
>>>>> {
>>>>> char *name;
>>>>> - struct dentry *dentry;
>>>>> +
>>>>> + name = (char *)__get_free_page(GFP_TEMPORARY);
>>>>
>>>> Ouch. Can we use a static temporary buffer instead?
>>>
>>>> This is called from workqueue context so we do not have to be afraid
>>>> of the deep call chain.
>>>
>>> Bahh, I was thinking about two things at the same time and that is how
>>> it ends... I meant a temporary buffer on the stack. But a separate
>>> allocation sounds even easier.
>>>
>>
>> Actually I don't care much about which way to take. Use on-stack buffer (if stack
>> usage is not a concern) or local static buffer (caller already held memcg_cache_mutex)
>> is simplest.
>>
>> But why it's bad to allocate a page for temp use?
>
> GFP_TEMPORARY groups short lived allocations but the mem cache is not
> an ideal candidate of this type of allocations..
>
I'm not sure I'm following you...
char *memcg_cache_name()
{
char *name = alloc();
return name;
}
kmem_cache_dup()
{
name = memcg_cache_name();
kmem_cache_create_memcg(name);
free(name);
}
Isn't this a short lived allocation?
>>>> It is also not a hot path AFAICS.
>>>>
>>>> Even GFP_ATOMIC for kasprintf would be an improvement IMO.
>>>
>>> What about the following (not even compile tested because I do not have
>>> cgroup_name in my tree yet):
>>
>> No, it won't compile. ;)
>
> Somehow expected so as this was just a quick hack to show what I meant.
> The full patch is bellow (compile time tested on top of for-3.10 branch
> this time :P)
> ---
>>From 7e1f6f0e266a230ced238a9bf2398b4069a6a764 Mon Sep 17 00:00:00 2001
> From: Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>
> Date: Fri, 22 Mar 2013 09:04:58 +0100
> Subject: [PATCH] memcg: fix memcg_cache_name() to use cgroup_name()
>
> As cgroup supports rename, it's unsafe to dereference dentry->d_name
> without proper vfs locks. Fix this by using cgroup_name().
>
> Signed-off-by: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>
> ---
> mm/memcontrol.c | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 53b8201..5741bf5 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -3220,13 +3220,18 @@ static char *memcg_cache_name(struct mem_cgroup *memcg, struct kmem_cache *s)
> struct dentry *dentry;
>
> rcu_read_lock();
> - dentry = rcu_dereference(memcg->css.cgroup->dentry);
> + name = kasprintf(GFP_ATOMIC, "%s(%d:%s)", s->name,
> + memcg_cache_id(memcg), dcgroup_name(memcg->css.cgroup));
> rcu_read_unlock();
>
> - BUG_ON(dentry == NULL);
> + if (!name) {
> + name = kmalloc(PAGE_SIZE, GFP_KERNEL);
> + rcu_read_lock();
> + name = snprintf(name, PAGE_SIZE, "%s(%d:%s)", s->name,
> + memcg_cache_id(memcg), dcgroup_name(memcg->css.cgroup));
> + rcu_read_unlock();
>
> - name = kasprintf(GFP_KERNEL, "%s(%d:%s)", s->name,
> - memcg_cache_id(memcg), dentry->d_name.name);
> + }
>
> return name;
> }
>
WARNING: multiple messages have this Message-ID (diff)
From: Li Zefan <lizefan@huawei.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: Tejun Heo <tj@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
Cgroups <cgroups@vger.kernel.org>,
linux-mm@kvack.org,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Glauber Costa <glommer@parallels.com>
Subject: Re: [PATCH] memcg: fix memcg_cache_name() to use cgroup_name()
Date: Fri, 22 Mar 2013 16:17:12 +0800 [thread overview]
Message-ID: <514C1388.6090909@huawei.com> (raw)
In-Reply-To: <20130322080749.GB31457@dhcp22.suse.cz>
>>>>> @@ -3217,17 +3217,16 @@ void mem_cgroup_destroy_cache(struct kmem_cache *cachep)
>>>>> static char *memcg_cache_name(struct mem_cgroup *memcg, struct kmem_cache *s)
>>>>> {
>>>>> char *name;
>>>>> - struct dentry *dentry;
>>>>> +
>>>>> + name = (char *)__get_free_page(GFP_TEMPORARY);
>>>>
>>>> Ouch. Can we use a static temporary buffer instead?
>>>
>>>> This is called from workqueue context so we do not have to be afraid
>>>> of the deep call chain.
>>>
>>> Bahh, I was thinking about two things at the same time and that is how
>>> it ends... I meant a temporary buffer on the stack. But a separate
>>> allocation sounds even easier.
>>>
>>
>> Actually I don't care much about which way to take. Use on-stack buffer (if stack
>> usage is not a concern) or local static buffer (caller already held memcg_cache_mutex)
>> is simplest.
>>
>> But why it's bad to allocate a page for temp use?
>
> GFP_TEMPORARY groups short lived allocations but the mem cache is not
> an ideal candidate of this type of allocations..
>
I'm not sure I'm following you...
char *memcg_cache_name()
{
char *name = alloc();
return name;
}
kmem_cache_dup()
{
name = memcg_cache_name();
kmem_cache_create_memcg(name);
free(name);
}
Isn't this a short lived allocation?
>>>> It is also not a hot path AFAICS.
>>>>
>>>> Even GFP_ATOMIC for kasprintf would be an improvement IMO.
>>>
>>> What about the following (not even compile tested because I do not have
>>> cgroup_name in my tree yet):
>>
>> No, it won't compile. ;)
>
> Somehow expected so as this was just a quick hack to show what I meant.
> The full patch is bellow (compile time tested on top of for-3.10 branch
> this time :P)
> ---
>>From 7e1f6f0e266a230ced238a9bf2398b4069a6a764 Mon Sep 17 00:00:00 2001
> From: Michal Hocko <mhocko@suse.cz>
> Date: Fri, 22 Mar 2013 09:04:58 +0100
> Subject: [PATCH] memcg: fix memcg_cache_name() to use cgroup_name()
>
> As cgroup supports rename, it's unsafe to dereference dentry->d_name
> without proper vfs locks. Fix this by using cgroup_name().
>
> Signed-off-by: Li Zefan <lizefan@huawei.com>
> Signed-off-by: Michal Hocko <mhocko@suse.cz>
> ---
> mm/memcontrol.c | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 53b8201..5741bf5 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -3220,13 +3220,18 @@ static char *memcg_cache_name(struct mem_cgroup *memcg, struct kmem_cache *s)
> struct dentry *dentry;
>
> rcu_read_lock();
> - dentry = rcu_dereference(memcg->css.cgroup->dentry);
> + name = kasprintf(GFP_ATOMIC, "%s(%d:%s)", s->name,
> + memcg_cache_id(memcg), dcgroup_name(memcg->css.cgroup));
> rcu_read_unlock();
>
> - BUG_ON(dentry == NULL);
> + if (!name) {
> + name = kmalloc(PAGE_SIZE, GFP_KERNEL);
> + rcu_read_lock();
> + name = snprintf(name, PAGE_SIZE, "%s(%d:%s)", s->name,
> + memcg_cache_id(memcg), dcgroup_name(memcg->css.cgroup));
> + rcu_read_unlock();
>
> - name = kasprintf(GFP_KERNEL, "%s(%d:%s)", s->name,
> - memcg_cache_id(memcg), dentry->d_name.name);
> + }
>
> return name;
> }
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Li Zefan <lizefan@huawei.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: Tejun Heo <tj@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
Cgroups <cgroups@vger.kernel.org>, <linux-mm@kvack.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Glauber Costa <glommer@parallels.com>
Subject: Re: [PATCH] memcg: fix memcg_cache_name() to use cgroup_name()
Date: Fri, 22 Mar 2013 16:17:12 +0800 [thread overview]
Message-ID: <514C1388.6090909@huawei.com> (raw)
In-Reply-To: <20130322080749.GB31457@dhcp22.suse.cz>
>>>>> @@ -3217,17 +3217,16 @@ void mem_cgroup_destroy_cache(struct kmem_cache *cachep)
>>>>> static char *memcg_cache_name(struct mem_cgroup *memcg, struct kmem_cache *s)
>>>>> {
>>>>> char *name;
>>>>> - struct dentry *dentry;
>>>>> +
>>>>> + name = (char *)__get_free_page(GFP_TEMPORARY);
>>>>
>>>> Ouch. Can we use a static temporary buffer instead?
>>>
>>>> This is called from workqueue context so we do not have to be afraid
>>>> of the deep call chain.
>>>
>>> Bahh, I was thinking about two things at the same time and that is how
>>> it ends... I meant a temporary buffer on the stack. But a separate
>>> allocation sounds even easier.
>>>
>>
>> Actually I don't care much about which way to take. Use on-stack buffer (if stack
>> usage is not a concern) or local static buffer (caller already held memcg_cache_mutex)
>> is simplest.
>>
>> But why it's bad to allocate a page for temp use?
>
> GFP_TEMPORARY groups short lived allocations but the mem cache is not
> an ideal candidate of this type of allocations..
>
I'm not sure I'm following you...
char *memcg_cache_name()
{
char *name = alloc();
return name;
}
kmem_cache_dup()
{
name = memcg_cache_name();
kmem_cache_create_memcg(name);
free(name);
}
Isn't this a short lived allocation?
>>>> It is also not a hot path AFAICS.
>>>>
>>>> Even GFP_ATOMIC for kasprintf would be an improvement IMO.
>>>
>>> What about the following (not even compile tested because I do not have
>>> cgroup_name in my tree yet):
>>
>> No, it won't compile. ;)
>
> Somehow expected so as this was just a quick hack to show what I meant.
> The full patch is bellow (compile time tested on top of for-3.10 branch
> this time :P)
> ---
>>From 7e1f6f0e266a230ced238a9bf2398b4069a6a764 Mon Sep 17 00:00:00 2001
> From: Michal Hocko <mhocko@suse.cz>
> Date: Fri, 22 Mar 2013 09:04:58 +0100
> Subject: [PATCH] memcg: fix memcg_cache_name() to use cgroup_name()
>
> As cgroup supports rename, it's unsafe to dereference dentry->d_name
> without proper vfs locks. Fix this by using cgroup_name().
>
> Signed-off-by: Li Zefan <lizefan@huawei.com>
> Signed-off-by: Michal Hocko <mhocko@suse.cz>
> ---
> mm/memcontrol.c | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 53b8201..5741bf5 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -3220,13 +3220,18 @@ static char *memcg_cache_name(struct mem_cgroup *memcg, struct kmem_cache *s)
> struct dentry *dentry;
>
> rcu_read_lock();
> - dentry = rcu_dereference(memcg->css.cgroup->dentry);
> + name = kasprintf(GFP_ATOMIC, "%s(%d:%s)", s->name,
> + memcg_cache_id(memcg), dcgroup_name(memcg->css.cgroup));
> rcu_read_unlock();
>
> - BUG_ON(dentry == NULL);
> + if (!name) {
> + name = kmalloc(PAGE_SIZE, GFP_KERNEL);
> + rcu_read_lock();
> + name = snprintf(name, PAGE_SIZE, "%s(%d:%s)", s->name,
> + memcg_cache_id(memcg), dcgroup_name(memcg->css.cgroup));
> + rcu_read_unlock();
>
> - name = kasprintf(GFP_KERNEL, "%s(%d:%s)", s->name,
> - memcg_cache_id(memcg), dentry->d_name.name);
> + }
>
> return name;
> }
>
next prev parent reply other threads:[~2013-03-22 8:17 UTC|newest]
Thread overview: 110+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-21 1:22 [PATCH] memcg: fix memcg_cache_name() to use cgroup_name() Li Zefan
2013-03-21 1:22 ` Li Zefan
2013-03-21 9:08 ` Michal Hocko
2013-03-21 9:08 ` Michal Hocko
[not found] ` <20130321090849.GF6094-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-03-21 10:22 ` Michal Hocko
2013-03-21 10:22 ` Michal Hocko
2013-03-21 10:22 ` Michal Hocko
2013-03-22 1:22 ` Li Zefan
2013-03-22 1:22 ` Li Zefan
[not found] ` <514BB23E.70908-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-03-22 8:07 ` Michal Hocko
2013-03-22 8:07 ` Michal Hocko
2013-03-22 8:07 ` Michal Hocko
[not found] ` <20130322080749.GB31457-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-03-22 8:17 ` Li Zefan [this message]
2013-03-22 8:17 ` Li Zefan
2013-03-22 8:17 ` Li Zefan
[not found] ` <514C1388.6090909-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-03-22 8:22 ` Glauber Costa
2013-03-22 8:22 ` Glauber Costa
2013-03-22 8:22 ` Glauber Costa
2013-03-22 9:31 ` Michal Hocko
2013-03-22 9:31 ` Michal Hocko
2013-03-22 9:31 ` Michal Hocko
2013-03-22 9:41 ` Glauber Costa
2013-03-22 9:41 ` Glauber Costa
[not found] ` <514C2754.4080701-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2013-03-22 9:48 ` Michal Hocko
2013-03-22 9:48 ` Michal Hocko
2013-03-22 9:48 ` Michal Hocko
[not found] ` <20130322094832.GG31457-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-03-22 10:03 ` Glauber Costa
2013-03-22 10:03 ` Glauber Costa
2013-03-22 10:03 ` Glauber Costa
2013-03-22 10:06 ` Michal Hocko
2013-03-22 10:06 ` Michal Hocko
[not found] ` <20130322100609.GI31457-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-03-22 10:25 ` Glauber Costa
2013-03-22 10:25 ` Glauber Costa
2013-03-22 10:25 ` Glauber Costa
[not found] ` <514C3193.9010609-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2013-03-22 10:56 ` Michal Hocko
2013-03-22 10:56 ` Michal Hocko
2013-03-22 10:56 ` Michal Hocko
2013-03-24 7:34 ` Li Zefan
2013-03-24 7:34 ` Li Zefan
2013-03-25 8:20 ` Michal Hocko
2013-03-25 8:20 ` Michal Hocko
2013-03-24 7:33 ` Li Zefan
2013-03-24 7:33 ` Li Zefan
[not found] ` <514EAC41.5050700-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-03-25 9:06 ` Michal Hocko
2013-03-25 9:06 ` Michal Hocko
2013-03-25 9:06 ` Michal Hocko
[not found] ` <20130325090629.GN2154-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-03-26 7:52 ` Li Zefan
2013-03-26 7:52 ` Li Zefan
2013-03-26 7:52 ` Li Zefan
[not found] ` <515153C0.5070908-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-03-26 8:10 ` Michal Hocko
2013-03-26 8:10 ` Michal Hocko
2013-03-26 8:10 ` Michal Hocko
2013-03-26 8:35 ` Glauber Costa
2013-03-26 8:35 ` Glauber Costa
2013-03-26 8:35 ` Glauber Costa
[not found] ` <51515DEE.70105-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2013-03-26 8:43 ` Michal Hocko
2013-03-26 8:43 ` Michal Hocko
2013-03-26 8:43 ` Michal Hocko
[not found] ` <20130326084348.GJ2295-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-03-26 9:02 ` Glauber Costa
2013-03-26 9:02 ` Glauber Costa
2013-03-26 9:02 ` Glauber Costa
[not found] ` <51516410.2000007-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2013-03-27 1:15 ` Li Zefan
2013-03-27 1:15 ` Li Zefan
2013-03-27 1:15 ` Li Zefan
2013-03-27 8:37 ` Michal Hocko
2013-03-27 8:37 ` Michal Hocko
-- strict thread matches above, loose matches on Subject: below --
2013-03-27 8:36 Michal Hocko
2013-03-27 8:36 ` Michal Hocko
2013-03-27 8:36 ` Michal Hocko
2013-03-27 14:58 ` Johannes Weiner
2013-03-27 14:58 ` Johannes Weiner
[not found] ` <20130327145727.GD29052-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2013-03-27 15:11 ` Michal Hocko
2013-03-27 15:11 ` Michal Hocko
2013-03-27 15:11 ` Michal Hocko
[not found] ` <20130327151104.GK16579-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-03-27 15:19 ` Glauber Costa
2013-03-27 15:19 ` Glauber Costa
2013-03-27 15:19 ` Glauber Costa
2013-03-27 15:32 ` Michal Hocko
2013-03-27 15:32 ` Michal Hocko
[not found] ` <20130327153220.GL16579-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-03-27 17:32 ` Michal Hocko
2013-03-27 17:32 ` Michal Hocko
2013-03-27 17:32 ` Michal Hocko
[not found] ` <20130327173223.GQ16579-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-03-28 7:48 ` Michal Hocko
2013-03-28 7:48 ` Michal Hocko
2013-03-28 7:48 ` Michal Hocko
2013-04-02 8:26 ` Michal Hocko
2013-04-02 8:26 ` Michal Hocko
[not found] ` <20130402082648.GB24345-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-04-03 21:33 ` Tejun Heo
2013-04-03 21:33 ` Tejun Heo
2013-04-03 21:33 ` Tejun Heo
2013-04-04 7:06 ` Michal Hocko
2013-04-04 7:06 ` Michal Hocko
2013-03-27 15:32 ` Johannes Weiner
2013-03-27 15:32 ` Johannes Weiner
2013-03-27 15:47 ` Michal Hocko
2013-03-27 15:47 ` Michal Hocko
[not found] ` <1364373399-17397-1-git-send-email-mhocko-AlSwsSmVLrQ@public.gmane.org>
2013-03-27 16:15 ` Tejun Heo
2013-03-27 16:15 ` Tejun Heo
2013-03-27 16:15 ` Tejun Heo
2013-03-27 16:19 ` Michal Hocko
2013-03-27 16:19 ` Michal Hocko
[not found] ` <20130327161905.GN16579-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-03-27 16:21 ` Tejun Heo
2013-03-27 16:21 ` Tejun Heo
2013-03-27 16:21 ` Tejun Heo
[not found] ` <CAOS58YPsrZNU9qDeMgJG3-Hkn0cBaigz16eTS5M57G95E8fxUQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-03-27 16:27 ` Michal Hocko
2013-03-27 16:27 ` Michal Hocko
2013-03-27 16:27 ` Michal Hocko
2013-03-28 7:22 ` Glauber Costa
2013-03-28 7:22 ` Glauber Costa
2013-03-28 7:22 ` Glauber Costa
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=514C1388.6090909@huawei.com \
--to=lizefan-hv44wf8li93qt0dzr+alfa@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org \
--cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
--cc=kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=mhocko-AlSwsSmVLrQ@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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.