All of lore.kernel.org
 help / color / mirror / Atom feed
From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Vivek Goyal <vgoyal@redhat.com>,
	Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Cc: linux-mips@linux-mips.org, Baoquan He <bhe@redhat.com>,
	linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-metag@vger.kernel.org,
	HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Daniel Walker <dwalker@fifo99.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linuxppc-dev@lists.ozlabs.org, Ingo Molnar <mingo@kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: Re: [PATCH 3/3] kexec: Change the timing of callbacks related to "crash_kexec_post_notifiers" boot option
Date: Wed, 15 Jul 2015 12:09:08 +0900	[thread overview]
Message-ID: <55A5CED4.7050400@hitachi.com> (raw)
In-Reply-To: <20150714144248.GC10792@redhat.com>

On 2015/07/14 23:42, Vivek Goyal wrote:
> On Fri, Jul 10, 2015 at 08:33:31PM +0900, Hidehiro Kawai wrote:
>> This patch fixes problems reported by Daniel Walker
>> (https://lkml.org/lkml/2015/6/24/44), and also replaces the bug fix
>> commits 5375b70 and f45d85f.
>>
>> If "crash_kexec_post_notifiers" boot option is specified,
>> other cpus are stopped by smp_send_stop() before entering
>> crash_kexec(), while usually machine_crash_shutdown() called by
>> crash_kexec() does that.  This behavior change leads two problems.
>>
>>  Problem 1:
>>  Some function in the crash_kexec() path depend on other cpus being
>>  still online.  If other cpus have been offlined already, they
>>  doesn't work properly.
>>
>>   Example:
>>    panic()
>>     crash_kexec()
>>      machine_crash_shutdown()
>>       octeon_generic_shutdown() // shutdown watchdog for ONLINE cpus
>>      machine_kexec()
>>
>>  Problem 2:
>>  Most of architectures stop other cpus in the machine_crash_shutdown()
>>  path and save register information at the same time.  However, if
>>  smp_send_stop() is called before that, we can't save the register
>>  information.
>>
>> To solve these problems, this patch changes the timing of calling
>> the callbacks instead of changing the timing of crash_kexec() if
>> crash_kexec_post_notifiers boot option is specified.
>>
>>  Before:
>>   if (!crash_kexec_post_notifiers)
>>       crash_kexec()
>>
>>   smp_send_stop()
>>   atomic_notifier_call_chain()
>>   kmsg_dump()
>>
>>   if (crash_kexec_post_notifiers)
>>       crash_kexec()
>>
>>  After:
>>   crash_kexec()
>>       machine_crash_shutdown()
>>       if (crash_kexec_post_notifiers) {
>>           atomic_notifier_call_chain()
>>           kmsg_dump()
>>       }
>>       machine_kexec()
>>
>>   smp_send_stop()
>>   if (!crash_kexec_post_notifiers) {
>>       atomic_notifier_call_chain()
>>       kmsg_dump()
>>   }
>>
> 
> I think this new code flow looks bad. Now we are calling kmsg_dump()
> and atomic_notifier_call_chain() from inside the crash_kexec() as well
> as from inside panic(). This is bad.
> 
> So basic problem seems to be that cpus need to be stopped once (with
> or without panic notifiers. So why don't we look into desiginig a 
> function which stops cpus, saves register states first and then does
> rest of the processing.
> 
> Something like.
> 
> stop_cpus_save_register_state;
> 
> if (!crash_kexec_post_notifiers)
> 	crash_kexec()
> 
> atomic_notifier_call_chain()
> kmsg_dump()
> 
> Here crash_kexec() will have to be modified and it will assume that cpus
> have already been stopped and register states have already been saved.

Ah, nice! I like this idea :)

> 
> IOW, is there a reason that we can't get rid of smp_send_stop() and
> use the mechanism crash_kexec() is using to stop cpus after panic()?

I think there is no reason why we don't do so. smp_send_stop() just
stops other cpus, but crash's one does more (collect registers and
stop watchdogs if needed, etc.). why don't we just replace(improve) it?

Thank you!


-- 
Masami HIRAMATSU
Linux Technology Research Center, System Productivity Research Dept.
Center for Technology Innovation - Systems Engineering
Hitachi, Ltd., Research & Development Group
E-mail: masami.hiramatsu.pt@hitachi.com

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

WARNING: multiple messages have this Message-ID (diff)
From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Vivek Goyal <vgoyal@redhat.com>,
	Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	linux-mips@linux-mips.org, Baoquan He <bhe@redhat.com>,
	linux-sh@vger.kernel.org, linux-s390@vger.kernel.org,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	Ingo Molnar <mingo@kernel.org>,
	HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>,
	Daniel Walker <dwalker@fifo99.com>,
	linuxppc-dev@lists.ozlabs.org, linux-metag@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: Re: [PATCH 3/3] kexec: Change the timing of callbacks related to "crash_kexec_post_notifiers" boot option
Date: Wed, 15 Jul 2015 12:09:08 +0900	[thread overview]
Message-ID: <55A5CED4.7050400@hitachi.com> (raw)
In-Reply-To: <20150714144248.GC10792@redhat.com>

On 2015/07/14 23:42, Vivek Goyal wrote:
> On Fri, Jul 10, 2015 at 08:33:31PM +0900, Hidehiro Kawai wrote:
>> This patch fixes problems reported by Daniel Walker
>> (https://lkml.org/lkml/2015/6/24/44), and also replaces the bug fix
>> commits 5375b70 and f45d85f.
>>
>> If "crash_kexec_post_notifiers" boot option is specified,
>> other cpus are stopped by smp_send_stop() before entering
>> crash_kexec(), while usually machine_crash_shutdown() called by
>> crash_kexec() does that.  This behavior change leads two problems.
>>
>>  Problem 1:
>>  Some function in the crash_kexec() path depend on other cpus being
>>  still online.  If other cpus have been offlined already, they
>>  doesn't work properly.
>>
>>   Example:
>>    panic()
>>     crash_kexec()
>>      machine_crash_shutdown()
>>       octeon_generic_shutdown() // shutdown watchdog for ONLINE cpus
>>      machine_kexec()
>>
>>  Problem 2:
>>  Most of architectures stop other cpus in the machine_crash_shutdown()
>>  path and save register information at the same time.  However, if
>>  smp_send_stop() is called before that, we can't save the register
>>  information.
>>
>> To solve these problems, this patch changes the timing of calling
>> the callbacks instead of changing the timing of crash_kexec() if
>> crash_kexec_post_notifiers boot option is specified.
>>
>>  Before:
>>   if (!crash_kexec_post_notifiers)
>>       crash_kexec()
>>
>>   smp_send_stop()
>>   atomic_notifier_call_chain()
>>   kmsg_dump()
>>
>>   if (crash_kexec_post_notifiers)
>>       crash_kexec()
>>
>>  After:
>>   crash_kexec()
>>       machine_crash_shutdown()
>>       if (crash_kexec_post_notifiers) {
>>           atomic_notifier_call_chain()
>>           kmsg_dump()
>>       }
>>       machine_kexec()
>>
>>   smp_send_stop()
>>   if (!crash_kexec_post_notifiers) {
>>       atomic_notifier_call_chain()
>>       kmsg_dump()
>>   }
>>
> 
> I think this new code flow looks bad. Now we are calling kmsg_dump()
> and atomic_notifier_call_chain() from inside the crash_kexec() as well
> as from inside panic(). This is bad.
> 
> So basic problem seems to be that cpus need to be stopped once (with
> or without panic notifiers. So why don't we look into desiginig a 
> function which stops cpus, saves register states first and then does
> rest of the processing.
> 
> Something like.
> 
> stop_cpus_save_register_state;
> 
> if (!crash_kexec_post_notifiers)
> 	crash_kexec()
> 
> atomic_notifier_call_chain()
> kmsg_dump()
> 
> Here crash_kexec() will have to be modified and it will assume that cpus
> have already been stopped and register states have already been saved.

Ah, nice! I like this idea :)

> 
> IOW, is there a reason that we can't get rid of smp_send_stop() and
> use the mechanism crash_kexec() is using to stop cpus after panic()?

I think there is no reason why we don't do so. smp_send_stop() just
stops other cpus, but crash's one does more (collect registers and
stop watchdogs if needed, etc.). why don't we just replace(improve) it?

Thank you!


-- 
Masami HIRAMATSU
Linux Technology Research Center, System Productivity Research Dept.
Center for Technology Innovation - Systems Engineering
Hitachi, Ltd., Research & Development Group
E-mail: masami.hiramatsu.pt@hitachi.com

WARNING: multiple messages have this Message-ID (diff)
From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: Re: [PATCH 3/3] kexec: Change the timing of callbacks related to "crash_kexec_post_notifiers" bo
Date: Wed, 15 Jul 2015 03:09:08 +0000	[thread overview]
Message-ID: <55A5CED4.7050400@hitachi.com> (raw)
In-Reply-To: <20150714144248.GC10792@redhat.com>

On 2015/07/14 23:42, Vivek Goyal wrote:
> On Fri, Jul 10, 2015 at 08:33:31PM +0900, Hidehiro Kawai wrote:
>> This patch fixes problems reported by Daniel Walker
>> (https://lkml.org/lkml/2015/6/24/44), and also replaces the bug fix
>> commits 5375b70 and f45d85f.
>>
>> If "crash_kexec_post_notifiers" boot option is specified,
>> other cpus are stopped by smp_send_stop() before entering
>> crash_kexec(), while usually machine_crash_shutdown() called by
>> crash_kexec() does that.  This behavior change leads two problems.
>>
>>  Problem 1:
>>  Some function in the crash_kexec() path depend on other cpus being
>>  still online.  If other cpus have been offlined already, they
>>  doesn't work properly.
>>
>>   Example:
>>    panic()
>>     crash_kexec()
>>      machine_crash_shutdown()
>>       octeon_generic_shutdown() // shutdown watchdog for ONLINE cpus
>>      machine_kexec()
>>
>>  Problem 2:
>>  Most of architectures stop other cpus in the machine_crash_shutdown()
>>  path and save register information at the same time.  However, if
>>  smp_send_stop() is called before that, we can't save the register
>>  information.
>>
>> To solve these problems, this patch changes the timing of calling
>> the callbacks instead of changing the timing of crash_kexec() if
>> crash_kexec_post_notifiers boot option is specified.
>>
>>  Before:
>>   if (!crash_kexec_post_notifiers)
>>       crash_kexec()
>>
>>   smp_send_stop()
>>   atomic_notifier_call_chain()
>>   kmsg_dump()
>>
>>   if (crash_kexec_post_notifiers)
>>       crash_kexec()
>>
>>  After:
>>   crash_kexec()
>>       machine_crash_shutdown()
>>       if (crash_kexec_post_notifiers) {
>>           atomic_notifier_call_chain()
>>           kmsg_dump()
>>       }
>>       machine_kexec()
>>
>>   smp_send_stop()
>>   if (!crash_kexec_post_notifiers) {
>>       atomic_notifier_call_chain()
>>       kmsg_dump()
>>   }
>>
> 
> I think this new code flow looks bad. Now we are calling kmsg_dump()
> and atomic_notifier_call_chain() from inside the crash_kexec() as well
> as from inside panic(). This is bad.
> 
> So basic problem seems to be that cpus need to be stopped once (with
> or without panic notifiers. So why don't we look into desiginig a 
> function which stops cpus, saves register states first and then does
> rest of the processing.
> 
> Something like.
> 
> stop_cpus_save_register_state;
> 
> if (!crash_kexec_post_notifiers)
> 	crash_kexec()
> 
> atomic_notifier_call_chain()
> kmsg_dump()
> 
> Here crash_kexec() will have to be modified and it will assume that cpus
> have already been stopped and register states have already been saved.

Ah, nice! I like this idea :)

> 
> IOW, is there a reason that we can't get rid of smp_send_stop() and
> use the mechanism crash_kexec() is using to stop cpus after panic()?

I think there is no reason why we don't do so. smp_send_stop() just
stops other cpus, but crash's one does more (collect registers and
stop watchdogs if needed, etc.). why don't we just replace(improve) it?

Thank you!


-- 
Masami HIRAMATSU
Linux Technology Research Center, System Productivity Research Dept.
Center for Technology Innovation - Systems Engineering
Hitachi, Ltd., Research & Development Group
E-mail: masami.hiramatsu.pt@hitachi.com

WARNING: multiple messages have this Message-ID (diff)
From: masami.hiramatsu.pt@hitachi.com (Masami Hiramatsu)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/3] kexec: Change the timing of callbacks related to "crash_kexec_post_notifiers" boot option
Date: Wed, 15 Jul 2015 12:09:08 +0900	[thread overview]
Message-ID: <55A5CED4.7050400@hitachi.com> (raw)
In-Reply-To: <20150714144248.GC10792@redhat.com>

On 2015/07/14 23:42, Vivek Goyal wrote:
> On Fri, Jul 10, 2015 at 08:33:31PM +0900, Hidehiro Kawai wrote:
>> This patch fixes problems reported by Daniel Walker
>> (https://lkml.org/lkml/2015/6/24/44), and also replaces the bug fix
>> commits 5375b70 and f45d85f.
>>
>> If "crash_kexec_post_notifiers" boot option is specified,
>> other cpus are stopped by smp_send_stop() before entering
>> crash_kexec(), while usually machine_crash_shutdown() called by
>> crash_kexec() does that.  This behavior change leads two problems.
>>
>>  Problem 1:
>>  Some function in the crash_kexec() path depend on other cpus being
>>  still online.  If other cpus have been offlined already, they
>>  doesn't work properly.
>>
>>   Example:
>>    panic()
>>     crash_kexec()
>>      machine_crash_shutdown()
>>       octeon_generic_shutdown() // shutdown watchdog for ONLINE cpus
>>      machine_kexec()
>>
>>  Problem 2:
>>  Most of architectures stop other cpus in the machine_crash_shutdown()
>>  path and save register information at the same time.  However, if
>>  smp_send_stop() is called before that, we can't save the register
>>  information.
>>
>> To solve these problems, this patch changes the timing of calling
>> the callbacks instead of changing the timing of crash_kexec() if
>> crash_kexec_post_notifiers boot option is specified.
>>
>>  Before:
>>   if (!crash_kexec_post_notifiers)
>>       crash_kexec()
>>
>>   smp_send_stop()
>>   atomic_notifier_call_chain()
>>   kmsg_dump()
>>
>>   if (crash_kexec_post_notifiers)
>>       crash_kexec()
>>
>>  After:
>>   crash_kexec()
>>       machine_crash_shutdown()
>>       if (crash_kexec_post_notifiers) {
>>           atomic_notifier_call_chain()
>>           kmsg_dump()
>>       }
>>       machine_kexec()
>>
>>   smp_send_stop()
>>   if (!crash_kexec_post_notifiers) {
>>       atomic_notifier_call_chain()
>>       kmsg_dump()
>>   }
>>
> 
> I think this new code flow looks bad. Now we are calling kmsg_dump()
> and atomic_notifier_call_chain() from inside the crash_kexec() as well
> as from inside panic(). This is bad.
> 
> So basic problem seems to be that cpus need to be stopped once (with
> or without panic notifiers. So why don't we look into desiginig a 
> function which stops cpus, saves register states first and then does
> rest of the processing.
> 
> Something like.
> 
> stop_cpus_save_register_state;
> 
> if (!crash_kexec_post_notifiers)
> 	crash_kexec()
> 
> atomic_notifier_call_chain()
> kmsg_dump()
> 
> Here crash_kexec() will have to be modified and it will assume that cpus
> have already been stopped and register states have already been saved.

Ah, nice! I like this idea :)

> 
> IOW, is there a reason that we can't get rid of smp_send_stop() and
> use the mechanism crash_kexec() is using to stop cpus after panic()?

I think there is no reason why we don't do so. smp_send_stop() just
stops other cpus, but crash's one does more (collect registers and
stop watchdogs if needed, etc.). why don't we just replace(improve) it?

Thank you!


-- 
Masami HIRAMATSU
Linux Technology Research Center, System Productivity Research Dept.
Center for Technology Innovation - Systems Engineering
Hitachi, Ltd., Research & Development Group
E-mail: masami.hiramatsu.pt at hitachi.com

  reply	other threads:[~2015-07-15  3:09 UTC|newest]

Thread overview: 105+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-10 11:33 [PATCH 0/3] kexec: crash_kexec_post_notifiers boot option related fixes Hidehiro Kawai
2015-07-10 11:33 ` Hidehiro Kawai
2015-07-10 11:33 ` Hidehiro Kawai
2015-07-10 11:33 ` Hidehiro Kawai
2015-07-10 11:33 ` [PATCH 1/3] panic: Disable crash_kexec_post_notifiers if kdump is not available Hidehiro Kawai
2015-07-10 11:33   ` Hidehiro Kawai
2015-07-10 11:33   ` Hidehiro Kawai
2015-07-10 11:33   ` Hidehiro Kawai
2015-07-10 13:41   ` Eric W. Biederman
2015-07-10 13:41     ` Eric W. Biederman
2015-07-10 13:41     ` Eric W. Biederman
2015-07-10 13:41     ` Eric W. Biederman
2015-07-10 13:41     ` Eric W. Biederman
2015-07-13 20:26     ` dwalker
2015-07-13 20:26       ` dwalker at fifo99.com
2015-07-13 20:26       ` dwalker
2015-07-13 20:26       ` dwalker
2015-07-14  1:19       ` Eric W. Biederman
2015-07-14  1:19         ` Eric W. Biederman
2015-07-14  1:19         ` Eric W. Biederman
2015-07-14  1:19         ` Eric W. Biederman
2015-07-14 13:59         ` dwalker
2015-07-14 13:59           ` dwalker at fifo99.com
2015-07-14 13:59           ` dwalker
2015-07-14 13:59           ` dwalker
2015-07-14 13:59           ` dwalker-zu3NM2574RrQT0dZR+AlfA
2015-07-14 14:20           ` Vivek Goyal
2015-07-14 14:20             ` Vivek Goyal
2015-07-14 14:20             ` Vivek Goyal
2015-07-14 14:20             ` Vivek Goyal
2015-07-14 14:20             ` Vivek Goyal
2015-07-14 15:02           ` Vivek Goyal
2015-07-14 15:02             ` Vivek Goyal
2015-07-14 15:02             ` Vivek Goyal
2015-07-14 15:02             ` Vivek Goyal
2015-07-14 15:34             ` dwalker
2015-07-14 15:34               ` dwalker at fifo99.com
2015-07-14 15:34               ` dwalker
2015-07-14 15:34               ` dwalker
2015-07-14 15:40               ` Vivek Goyal
2015-07-14 15:40                 ` Vivek Goyal
2015-07-14 15:40                 ` Vivek Goyal
2015-07-14 15:40                 ` Vivek Goyal
2015-07-14 15:48                 ` dwalker
2015-07-14 15:48                   ` dwalker at fifo99.com
2015-07-14 15:48                   ` dwalker
2015-07-14 15:48                   ` dwalker
2015-07-14 16:16                   ` Vivek Goyal
2015-07-14 16:16                     ` Vivek Goyal
2015-07-14 16:16                     ` Vivek Goyal
2015-07-14 16:16                     ` Vivek Goyal
2015-07-14 16:16                     ` Vivek Goyal
2015-07-14 17:06                     ` Eric W. Biederman
2015-07-14 17:06                       ` Eric W. Biederman
2015-07-14 17:06                       ` Eric W. Biederman
2015-07-14 17:06                       ` Eric W. Biederman
2015-07-14 17:06                       ` Eric W. Biederman
2015-07-14 17:29                       ` dwalker
2015-07-14 17:29                         ` dwalker at fifo99.com
2015-07-14 17:29                         ` dwalker
2015-07-14 17:29                         ` dwalker
2015-07-14 17:55                         ` Vivek Goyal
2015-07-14 17:55                           ` Vivek Goyal
2015-07-14 17:55                           ` Vivek Goyal
2015-07-14 17:55                           ` Vivek Goyal
2015-07-14 17:55                           ` Vivek Goyal
2015-07-14 18:01                           ` Eric W. Biederman
2015-07-14 18:01                             ` Eric W. Biederman
2015-07-14 18:01                             ` Eric W. Biederman
2015-07-14 18:01                             ` Eric W. Biederman
2015-07-14 18:23                             ` Vivek Goyal
2015-07-14 18:23                               ` Vivek Goyal
2015-07-14 18:23                               ` Vivek Goyal
2015-07-14 18:23                               ` Vivek Goyal
2015-07-14 18:23                               ` Vivek Goyal
2015-07-15  5:16                               ` Masami Hiramatsu
2015-07-15  5:16                                 ` Masami Hiramatsu
2015-07-15  5:16                                 ` Masami Hiramatsu
2015-07-15  5:16                                 ` Masami Hiramatsu
2015-07-15 10:49                 ` Hidehiro Kawai
2015-07-15 10:49                   ` Hidehiro Kawai
2015-07-15 10:49                   ` Hidehiro Kawai
2015-07-15 10:49                   ` Hidehiro Kawai
2015-07-15 10:49                   ` Hidehiro Kawai
2015-07-14  1:56       ` Hidehiro Kawai
2015-07-14  1:56         ` Hidehiro Kawai
2015-07-14  1:56         ` Hidehiro Kawai
2015-07-14  1:56         ` Hidehiro Kawai
2015-07-14  1:56         ` Hidehiro Kawai
2015-07-10 11:33 ` [PATCH 3/3] kexec: Change the timing of callbacks related to "crash_kexec_post_notifiers" boot option Hidehiro Kawai
2015-07-10 11:33   ` Hidehiro Kawai
2015-07-10 11:33   ` [PATCH 3/3] kexec: Change the timing of callbacks related to "crash_kexec_post_notifiers" boot optio Hidehiro Kawai
2015-07-10 11:33   ` [PATCH 3/3] kexec: Change the timing of callbacks related to "crash_kexec_post_notifiers" boot option Hidehiro Kawai
2015-07-14 14:42   ` Vivek Goyal
2015-07-14 14:42     ` Vivek Goyal
2015-07-14 14:42     ` [PATCH 3/3] kexec: Change the timing of callbacks related to "crash_kexec_post_notifiers" boot o Vivek Goyal
2015-07-14 14:42     ` [PATCH 3/3] kexec: Change the timing of callbacks related to "crash_kexec_post_notifiers" boot option Vivek Goyal
2015-07-15  3:09     ` Masami Hiramatsu [this message]
2015-07-15  3:09       ` Masami Hiramatsu
2015-07-15  3:09       ` Re: [PATCH 3/3] kexec: Change the timing of callbacks related to "crash_kexec_post_notifiers" bo Masami Hiramatsu
2015-07-15  3:09       ` Re: [PATCH 3/3] kexec: Change the timing of callbacks related to "crash_kexec_post_notifiers" boot option Masami Hiramatsu
2015-07-10 11:33 ` [PATCH 2/3] kexec: Pass panic message to crash_kexec() Hidehiro Kawai
2015-07-10 11:33   ` Hidehiro Kawai
2015-07-10 11:33   ` Hidehiro Kawai
2015-07-10 11:33   ` Hidehiro Kawai

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=55A5CED4.7050400@hitachi.com \
    --to=masami.hiramatsu.pt@hitachi.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=d.hatayama@jp.fujitsu.com \
    --cc=dwalker@fifo99.com \
    --cc=ebiederm@xmission.com \
    --cc=hidehiro.kawai.ez@hitachi.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-metag@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mingo@kernel.org \
    --cc=vgoyal@redhat.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.