All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robin Holt <holt@sgi.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: Andrea Arcangeli <andrea@qumranet.com>, Robin Holt <holt@sgi.com>,
	Avi Kivity <avi@qumranet.com>, Izik Eidus <izike@qumranet.com>,
	Nick Piggin <npiggin@suse.de>,
	kvm-devel@lists.sourceforge.net,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	steiner@sgi.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, daniel.blueman@quadrics.com,
	Hugh Dickins <hugh@veritas.com>
Subject: Re: [patch 1/4] mmu_notifier: Core code
Date: Fri, 25 Jan 2008 12:39:34 -0600	[thread overview]
Message-ID: <20080125183934.GO26420@sgi.com> (raw)
In-Reply-To: <20080125055801.212744875@sgi.com>

> +#define mmu_notifier(function, mm, args...)				\
...
> +				if (__mn->ops->function)		\
> +					__mn->ops->function(__mn,	\
> +							    mm,		\
> +							    args);	\

					__mn->ops->function(__mn, mm, args);	\
I realize it is a minor nit, but since we put the continuation in column
81 in the next define, can we do the same here and make this more
readable?

> +			rcu_read_unlock();				\
...
> +#define mmu_rmap_notifier(function, args...)					\
> +	do {									\
> +		struct mmu_rmap_notifier *__mrn;				\
> +		struct hlist_node *__n;						\
> +										\



> +void mmu_notifier_release(struct mm_struct *mm)
> +{
> +	struct mmu_notifier *mn;
> +	struct hlist_node *n;
> +
> +	if (unlikely(!hlist_empty(&mm->mmu_notifier.head))) {
> +		rcu_read_lock();
> +		hlist_for_each_entry_rcu(mn, n,
> +					  &mm->mmu_notifier.head, hlist) {
> +			if (mn->ops->release)
> +				mn->ops->release(mn, mm);
> +			hlist_del(&mn->hlist);

I think the hlist_del needs to be before the function callout so we can free
the structure without a use-after-free issue.

		hlist_for_each_entry_rcu(mn, n,
					  &mm->mmu_notifier.head, hlist) {
			hlist_del_rcu(&mn->hlist);
			if (mn->ops->release)
				mn->ops->release(mn, mm);



> +static DEFINE_SPINLOCK(mmu_notifier_list_lock);

Remove

> +
> +void mmu_notifier_register(struct mmu_notifier *mn, struct mm_struct *mm)
> +{
> +	spin_lock(&mmu_notifier_list_lock);

Shouldn't this really be protected by the down_write(mmap_sem)?  Maybe:
	BUG_ON(!rwsem_is_write_locked(&mm->mmap_sem));

> +	hlist_add_head(&mn->hlist, &mm->mmu_notifier.head);
	hlist_add_head_rcu(&mn->hlist, &mm->mmu_notifier.head);

> +	spin_unlock(&mmu_notifier_list_lock);
> +}
> +EXPORT_SYMBOL_GPL(mmu_notifier_register);
> +
> +void mmu_notifier_unregister(struct mmu_notifier *mn, struct mm_struct *mm)
> +{
> +	spin_lock(&mmu_notifier_list_lock);
> +	hlist_del(&mn->hlist);

hlist_del_rcu?  Ditto on the lock.

> +	spin_unlock(&mmu_notifier_list_lock);
> +}
> +EXPORT_SYMBOL_GPL(mmu_notifier_unregister);
> +
> +HLIST_HEAD(mmu_rmap_notifier_list);

static DEFINE_SPINLOCK(mmu_rmap_notifier_list_lock);

> +
> +void mmu_rmap_notifier_register(struct mmu_rmap_notifier *mrn)
> +{
> +	spin_lock(&mmu_notifier_list_lock);
> +	hlist_add_head_rcu(&mrn->hlist, &mmu_rmap_notifier_list);
> +	spin_unlock(&mmu_notifier_list_lock);

	spin_lock(&mmu_rmap_notifier_list_lock);
	hlist_add_head_rcu(&mrn->hlist, &mmu_rmap_notifier_list);
	spin_unlock(&mmu_rmap_notifier_list_lock);

> +}
> +EXPORT_SYMBOL(mmu_rmap_notifier_register);
> +
> +void mmu_rmap_notifier_unregister(struct mmu_rmap_notifier *mrn)
> +{
> +	spin_lock(&mmu_notifier_list_lock);
> +	hlist_del_rcu(&mrn->hlist);
> +	spin_unlock(&mmu_notifier_list_lock);

	spin_lock(&mmu_rmap_notifier_list_lock);
	hlist_del_rcu(&mrn->hlist);
	spin_unlock(&mmu_rmap_notifier_list_lock);


> @@ -2043,6 +2044,7 @@ void exit_mmap(struct mm_struct *mm)
>  	vm_unacct_memory(nr_accounted);
>  	free_pgtables(&tlb, vma, FIRST_USER_ADDRESS, 0);
>  	tlb_finish_mmu(tlb, 0, end);
> +	mmu_notifier_release(mm);

Can we consider moving this notifier or introducing an additional notifier
in the release or a flag to this one indicating early/late.

The GRU that Jack is concerned with would benefit from the early in
that it could just invalidate the GRU context and immediately all GRU
TLB entries are invalid.  I believe Jack would like to also be able to
remove his entry from the mmu_notifier list in an effort to avoid the
page and range callouts.

XPMEM, would also benefit from a call early.  We could make all the
segments as being torn down and start the recalls.  We already have
this code in and working (have since it was first written 6 years ago).
In this case, all segments are torn down with a single message to each
of the importing partitions.  In contrast, the teardown code which would
happen now would be one set of messages for each vma.

Thanks,
Robin

WARNING: multiple messages have this Message-ID (diff)
From: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
To: Christoph Lameter <clameter-sJ/iWh9BUns@public.gmane.org>
Cc: Nick Piggin <npiggin-l3A5Bk7waGM@public.gmane.org>,
	Andrea Arcangeli <andrea-atKUWr5tajBWk0Htik3J/w@public.gmane.org>,
	Peter Zijlstra
	<a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org>,
	linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
	Benjamin Herrenschmidt
	<benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>,
	steiner-sJ/iWh9BUns@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>,
	kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
	daniel.blueman-xqY44rlHlBpWk0Htik3J/w@public.gmane.org,
	Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>,
	Hugh Dickins <hugh-DTz5qymZ9yRBDgjK7y7TUQ@public.gmane.org>
Subject: Re: [patch 1/4] mmu_notifier: Core code
Date: Fri, 25 Jan 2008 12:39:34 -0600	[thread overview]
Message-ID: <20080125183934.GO26420@sgi.com> (raw)
In-Reply-To: <20080125055801.212744875-sJ/iWh9BUns@public.gmane.org>

> +#define mmu_notifier(function, mm, args...)				\
...
> +				if (__mn->ops->function)		\
> +					__mn->ops->function(__mn,	\
> +							    mm,		\
> +							    args);	\

					__mn->ops->function(__mn, mm, args);	\
I realize it is a minor nit, but since we put the continuation in column
81 in the next define, can we do the same here and make this more
readable?

> +			rcu_read_unlock();				\
...
> +#define mmu_rmap_notifier(function, args...)					\
> +	do {									\
> +		struct mmu_rmap_notifier *__mrn;				\
> +		struct hlist_node *__n;						\
> +										\



> +void mmu_notifier_release(struct mm_struct *mm)
> +{
> +	struct mmu_notifier *mn;
> +	struct hlist_node *n;
> +
> +	if (unlikely(!hlist_empty(&mm->mmu_notifier.head))) {
> +		rcu_read_lock();
> +		hlist_for_each_entry_rcu(mn, n,
> +					  &mm->mmu_notifier.head, hlist) {
> +			if (mn->ops->release)
> +				mn->ops->release(mn, mm);
> +			hlist_del(&mn->hlist);

I think the hlist_del needs to be before the function callout so we can free
the structure without a use-after-free issue.

		hlist_for_each_entry_rcu(mn, n,
					  &mm->mmu_notifier.head, hlist) {
			hlist_del_rcu(&mn->hlist);
			if (mn->ops->release)
				mn->ops->release(mn, mm);



> +static DEFINE_SPINLOCK(mmu_notifier_list_lock);

Remove

> +
> +void mmu_notifier_register(struct mmu_notifier *mn, struct mm_struct *mm)
> +{
> +	spin_lock(&mmu_notifier_list_lock);

Shouldn't this really be protected by the down_write(mmap_sem)?  Maybe:
	BUG_ON(!rwsem_is_write_locked(&mm->mmap_sem));

> +	hlist_add_head(&mn->hlist, &mm->mmu_notifier.head);
	hlist_add_head_rcu(&mn->hlist, &mm->mmu_notifier.head);

> +	spin_unlock(&mmu_notifier_list_lock);
> +}
> +EXPORT_SYMBOL_GPL(mmu_notifier_register);
> +
> +void mmu_notifier_unregister(struct mmu_notifier *mn, struct mm_struct *mm)
> +{
> +	spin_lock(&mmu_notifier_list_lock);
> +	hlist_del(&mn->hlist);

hlist_del_rcu?  Ditto on the lock.

> +	spin_unlock(&mmu_notifier_list_lock);
> +}
> +EXPORT_SYMBOL_GPL(mmu_notifier_unregister);
> +
> +HLIST_HEAD(mmu_rmap_notifier_list);

static DEFINE_SPINLOCK(mmu_rmap_notifier_list_lock);

> +
> +void mmu_rmap_notifier_register(struct mmu_rmap_notifier *mrn)
> +{
> +	spin_lock(&mmu_notifier_list_lock);
> +	hlist_add_head_rcu(&mrn->hlist, &mmu_rmap_notifier_list);
> +	spin_unlock(&mmu_notifier_list_lock);

	spin_lock(&mmu_rmap_notifier_list_lock);
	hlist_add_head_rcu(&mrn->hlist, &mmu_rmap_notifier_list);
	spin_unlock(&mmu_rmap_notifier_list_lock);

> +}
> +EXPORT_SYMBOL(mmu_rmap_notifier_register);
> +
> +void mmu_rmap_notifier_unregister(struct mmu_rmap_notifier *mrn)
> +{
> +	spin_lock(&mmu_notifier_list_lock);
> +	hlist_del_rcu(&mrn->hlist);
> +	spin_unlock(&mmu_notifier_list_lock);

	spin_lock(&mmu_rmap_notifier_list_lock);
	hlist_del_rcu(&mrn->hlist);
	spin_unlock(&mmu_rmap_notifier_list_lock);


> @@ -2043,6 +2044,7 @@ void exit_mmap(struct mm_struct *mm)
>  	vm_unacct_memory(nr_accounted);
>  	free_pgtables(&tlb, vma, FIRST_USER_ADDRESS, 0);
>  	tlb_finish_mmu(tlb, 0, end);
> +	mmu_notifier_release(mm);

Can we consider moving this notifier or introducing an additional notifier
in the release or a flag to this one indicating early/late.

The GRU that Jack is concerned with would benefit from the early in
that it could just invalidate the GRU context and immediately all GRU
TLB entries are invalid.  I believe Jack would like to also be able to
remove his entry from the mmu_notifier list in an effort to avoid the
page and range callouts.

XPMEM, would also benefit from a call early.  We could make all the
segments as being torn down and start the recalls.  We already have
this code in and working (have since it was first written 6 years ago).
In this case, all segments are torn down with a single message to each
of the importing partitions.  In contrast, the teardown code which would
happen now would be one set of messages for each vma.

Thanks,
Robin

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

WARNING: multiple messages have this Message-ID (diff)
From: Robin Holt <holt@sgi.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: Andrea Arcangeli <andrea@qumranet.com>, Robin Holt <holt@sgi.com>,
	Avi Kivity <avi@qumranet.com>, Izik Eidus <izike@qumranet.com>,
	Nick Piggin <npiggin@suse.de>,
	kvm-devel@lists.sourceforge.net,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	steiner@sgi.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, daniel.blueman@quadrics.com,
	Hugh Dickins <hugh@veritas.com>
Subject: Re: [patch 1/4] mmu_notifier: Core code
Date: Fri, 25 Jan 2008 12:39:34 -0600	[thread overview]
Message-ID: <20080125183934.GO26420@sgi.com> (raw)
In-Reply-To: <20080125055801.212744875@sgi.com>

> +#define mmu_notifier(function, mm, args...)				\
...
> +				if (__mn->ops->function)		\
> +					__mn->ops->function(__mn,	\
> +							    mm,		\
> +							    args);	\

					__mn->ops->function(__mn, mm, args);	\
I realize it is a minor nit, but since we put the continuation in column
81 in the next define, can we do the same here and make this more
readable?

> +			rcu_read_unlock();				\
...
> +#define mmu_rmap_notifier(function, args...)					\
> +	do {									\
> +		struct mmu_rmap_notifier *__mrn;				\
> +		struct hlist_node *__n;						\
> +										\



> +void mmu_notifier_release(struct mm_struct *mm)
> +{
> +	struct mmu_notifier *mn;
> +	struct hlist_node *n;
> +
> +	if (unlikely(!hlist_empty(&mm->mmu_notifier.head))) {
> +		rcu_read_lock();
> +		hlist_for_each_entry_rcu(mn, n,
> +					  &mm->mmu_notifier.head, hlist) {
> +			if (mn->ops->release)
> +				mn->ops->release(mn, mm);
> +			hlist_del(&mn->hlist);

I think the hlist_del needs to be before the function callout so we can free
the structure without a use-after-free issue.

		hlist_for_each_entry_rcu(mn, n,
					  &mm->mmu_notifier.head, hlist) {
			hlist_del_rcu(&mn->hlist);
			if (mn->ops->release)
				mn->ops->release(mn, mm);



> +static DEFINE_SPINLOCK(mmu_notifier_list_lock);

Remove

> +
> +void mmu_notifier_register(struct mmu_notifier *mn, struct mm_struct *mm)
> +{
> +	spin_lock(&mmu_notifier_list_lock);

Shouldn't this really be protected by the down_write(mmap_sem)?  Maybe:
	BUG_ON(!rwsem_is_write_locked(&mm->mmap_sem));

> +	hlist_add_head(&mn->hlist, &mm->mmu_notifier.head);
	hlist_add_head_rcu(&mn->hlist, &mm->mmu_notifier.head);

> +	spin_unlock(&mmu_notifier_list_lock);
> +}
> +EXPORT_SYMBOL_GPL(mmu_notifier_register);
> +
> +void mmu_notifier_unregister(struct mmu_notifier *mn, struct mm_struct *mm)
> +{
> +	spin_lock(&mmu_notifier_list_lock);
> +	hlist_del(&mn->hlist);

hlist_del_rcu?  Ditto on the lock.

> +	spin_unlock(&mmu_notifier_list_lock);
> +}
> +EXPORT_SYMBOL_GPL(mmu_notifier_unregister);
> +
> +HLIST_HEAD(mmu_rmap_notifier_list);

static DEFINE_SPINLOCK(mmu_rmap_notifier_list_lock);

> +
> +void mmu_rmap_notifier_register(struct mmu_rmap_notifier *mrn)
> +{
> +	spin_lock(&mmu_notifier_list_lock);
> +	hlist_add_head_rcu(&mrn->hlist, &mmu_rmap_notifier_list);
> +	spin_unlock(&mmu_notifier_list_lock);

	spin_lock(&mmu_rmap_notifier_list_lock);
	hlist_add_head_rcu(&mrn->hlist, &mmu_rmap_notifier_list);
	spin_unlock(&mmu_rmap_notifier_list_lock);

> +}
> +EXPORT_SYMBOL(mmu_rmap_notifier_register);
> +
> +void mmu_rmap_notifier_unregister(struct mmu_rmap_notifier *mrn)
> +{
> +	spin_lock(&mmu_notifier_list_lock);
> +	hlist_del_rcu(&mrn->hlist);
> +	spin_unlock(&mmu_notifier_list_lock);

	spin_lock(&mmu_rmap_notifier_list_lock);
	hlist_del_rcu(&mrn->hlist);
	spin_unlock(&mmu_rmap_notifier_list_lock);


> @@ -2043,6 +2044,7 @@ void exit_mmap(struct mm_struct *mm)
>  	vm_unacct_memory(nr_accounted);
>  	free_pgtables(&tlb, vma, FIRST_USER_ADDRESS, 0);
>  	tlb_finish_mmu(tlb, 0, end);
> +	mmu_notifier_release(mm);

Can we consider moving this notifier or introducing an additional notifier
in the release or a flag to this one indicating early/late.

The GRU that Jack is concerned with would benefit from the early in
that it could just invalidate the GRU context and immediately all GRU
TLB entries are invalid.  I believe Jack would like to also be able to
remove his entry from the mmu_notifier list in an effort to avoid the
page and range callouts.

XPMEM, would also benefit from a call early.  We could make all the
segments as being torn down and start the recalls.  We already have
this code in and working (have since it was first written 6 years ago).
In this case, all segments are torn down with a single message to each
of the importing partitions.  In contrast, the teardown code which would
happen now would be one set of messages for each vma.

Thanks,
Robin

--
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>

  reply	other threads:[~2008-01-25 18:39 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-25  5:56 [patch 0/4] [RFC] MMU Notifiers V1 Christoph Lameter
2008-01-25  5:56 ` Christoph Lameter
2008-01-25  5:56 ` [patch 1/4] mmu_notifier: Core code Christoph Lameter
2008-01-25  5:56   ` Christoph Lameter
2008-01-25 18:39   ` Robin Holt [this message]
2008-01-25 18:39     ` Robin Holt
2008-01-25 18:39     ` Robin Holt
2008-01-25 18:47     ` Christoph Lameter
2008-01-25 18:47       ` Christoph Lameter
2008-01-25 18:47       ` Christoph Lameter
2008-01-25 18:56       ` Robin Holt
2008-01-25 18:56         ` Robin Holt
2008-01-25 19:03         ` Christoph Lameter
2008-01-25 19:03           ` Christoph Lameter
2008-01-25 19:03           ` Christoph Lameter
2008-01-25 19:35           ` Robin Holt
2008-01-25 19:35             ` Robin Holt
2008-01-25 19:35             ` Robin Holt
2008-01-25 20:10             ` Christoph Lameter
2008-01-25 20:10               ` Christoph Lameter
2008-01-25 20:10               ` Christoph Lameter
2008-01-26 11:56               ` Robin Holt
2008-01-26 11:56                 ` Robin Holt
2008-01-26 11:56                 ` Robin Holt
2008-01-28 18:51                 ` Christoph Lameter
2008-01-28 18:51                   ` Christoph Lameter
2008-01-25 21:18             ` Christoph Lameter
2008-01-25 21:18               ` Christoph Lameter
2008-01-25 21:18               ` Christoph Lameter
2008-01-26 12:01               ` Robin Holt
2008-01-26 12:01                 ` Robin Holt
2008-01-26 12:01                 ` Robin Holt
2008-01-28 18:44                 ` Christoph Lameter
2008-01-28 18:44                   ` Christoph Lameter
2008-01-28 18:44                   ` Christoph Lameter
2008-01-25  5:56 ` [patch 2/4] mmu_notifier: Callbacks to invalidate address ranges Christoph Lameter
2008-01-25  5:56   ` Christoph Lameter
2008-01-25  5:56 ` [patch 3/4] mmu_notifier: invalidate_page callbacks for subsystems with rmap Christoph Lameter
2008-01-25  5:56   ` Christoph Lameter
2008-01-25  5:56 ` [patch 4/4] MMU notifier: invalidate_page callbacks using Linux rmaps Christoph Lameter
2008-01-25  5:56   ` Christoph Lameter
2008-01-25 11:42 ` [patch 0/4] [RFC] MMU Notifiers V1 Andrea Arcangeli
2008-01-25 11:42   ` Andrea Arcangeli
2008-01-25 12:43   ` Robin Holt
2008-01-25 12:43     ` Robin Holt
2008-01-25 12:43     ` Robin Holt
2008-01-25 18:31   ` Christoph Lameter
2008-01-25 18:31     ` Christoph Lameter
2008-01-25 18:31     ` Christoph Lameter
2008-01-25 21:18   ` Benjamin Herrenschmidt
2008-01-25 21:18     ` Benjamin Herrenschmidt
2008-01-25 21:18     ` Benjamin Herrenschmidt
2008-01-25 21:25     ` Christoph Lameter
2008-01-25 21:25       ` Christoph Lameter
2008-01-25 21:25       ` Christoph Lameter
2008-01-28 16:10   ` Izik Eidus
2008-01-28 16:10     ` Izik Eidus
2008-01-28 16:10     ` Izik Eidus
2008-01-28 17:25     ` Andrea Arcangeli
2008-01-28 17:25       ` Andrea Arcangeli
2008-01-28 19:04       ` Christoph Lameter
2008-01-28 19:04         ` Christoph Lameter
2008-01-28 19:40         ` Andrea Arcangeli
2008-01-28 19:40           ` Andrea Arcangeli
2008-01-28 19:40           ` Andrea Arcangeli
2008-01-28 20:16           ` Christoph Lameter
2008-01-28 20:16             ` Christoph Lameter
2008-01-28 20:16             ` Christoph Lameter
  -- strict thread matches above, loose matches on Subject: below --
2008-02-01  5:04 [patch 0/4] [RFC] EMMU Notifiers V5 Christoph Lameter
2008-02-01  5:04 ` [patch 1/4] mmu_notifier: Core code Christoph Lameter
2008-02-01  5:04   ` Christoph Lameter
2008-02-01 10:55   ` Robin Holt
2008-02-01 10:55     ` Robin Holt
2008-02-01 10:55     ` Robin Holt
2008-02-01 11:04     ` Robin Holt
2008-02-01 11:04       ` Robin Holt
2008-02-01 19:14     ` Christoph Lameter
2008-02-01 19:14       ` Christoph Lameter
2008-02-01 19:14       ` Christoph Lameter

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=20080125183934.GO26420@sgi.com \
    --to=holt@sgi.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=andrea@qumranet.com \
    --cc=avi@qumranet.com \
    --cc=benh@kernel.crashing.org \
    --cc=clameter@sgi.com \
    --cc=daniel.blueman@quadrics.com \
    --cc=hugh@veritas.com \
    --cc=izike@qumranet.com \
    --cc=kvm-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=npiggin@suse.de \
    --cc=steiner@sgi.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.