All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: Ignat Korchagin <ignat@cloudflare.com>
Cc: eric_devolder@yahoo.com, linux@armlinux.org.uk,
	catalin.marinas@arm.com, will@kernel.org, chenhuacai@kernel.org,
	geert@linux-m68k.org, tsbogend@alpha.franken.de,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	deller@gmx.de, ysato@users.sourceforge.jp, dalias@libc.org,
	glaubitz@physik.fu-berlin.de,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	dave.hansen@linux.intel.com, x86@kernel.org,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org,
	loongarch@lists.linux.dev, linux-m68k@lists.linux-m68k.org,
	linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
	linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
	kernel@xen0n.name, mpe@ellerman.id.au, npiggin@gmail.com,
	christophe.leroy@csgroup.eu, paul.walmsley@sifive.com,
	palmer@dabbelt.com, aou@eecs.berkeley.edu, hca@linux.ibm.com,
	gor@linux.ibm.com, agordeev@linux.ibm.com,
	borntraeger@linux.ibm.com, svens@linux.ibm.com, hpa@zytor.com,
	keescook@chromium.org, paulmck@kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	frederic@kernel.org, Andrew Morton <akpm@linux-foundation.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	samitolvanen@google.com, juerg.haefliger@canonical.com,
	arnd@arndb.de, rmk+kernel@armlinux.org.uk,
	linus.walleij@linaro.org, sebastian.reichel@collabora.com,
	rppt@kernel.org, kirill.shutemov@linux.intel.com,
	anshuman.khandual@arm.com, ziy@nvidia.com, masahiroy@kernel.org,
	ndesaulniers@google.com, mhiramat@kernel.org, ojeda@kernel.org,
	thunder.leizhen@huawei.com, xin3.li@intel.com, tj@kernel.org,
	Greg KH <gregkh@linuxfoundation.org>,
	tsi@tuyoix.net, hbathini@linux.ibm.com,
	sourabhjain@linux.ibm.com, boris.ostrovsky@oracle.com,
	konrad.wilk@oracle.com, kernel-team <kernel-team@cloudflare.com>
Subject: Re: Potential config regression after 89cde455 ("kexec: consolidate kexec and crash options into kernel/Kconfig.kexec")
Date: Tue, 21 Nov 2023 17:56:42 +0800	[thread overview]
Message-ID: <ZVx+2lfTckjv/kiq@MiWiFi-R3L-srv> (raw)
In-Reply-To: <CALrw=nG8xsYw7XKyL_VMHtKiaBcQCKvC8UVp-C9-BdeN4A1Daw@mail.gmail.com>

On 11/21/23 at 07:53am, Ignat Korchagin wrote:
> On Tue, Nov 21, 2023 at 1:50 AM Baoquan He <bhe@redhat.com> wrote:
> >
> > Eric DeVolder's Oracle mail address is not available anymore, add his
> > current mail address he told me.
> 
> Thank you!
> 
> > On 11/20/23 at 10:52pm, Ignat Korchagin wrote:
> > > Good day!
> > >
> > > We have recently started to evaluate Linux 6.6 and noticed that we
> > > cannot disable CONFIG_KEXEC anymore, but keep CONFIG_CRASH_DUMP
> > > enabled. It seems to be related to commit 89cde455 ("kexec:
> > > consolidate kexec and crash options into kernel/Kconfig.kexec"), where
> > > a CONFIG_KEXEC dependency was added to CONFIG_CRASH_DUMP.
> > >
> > > In our current kernel (Linux 6.1) we only enable CONFIG_KEXEC_FILE
> > > with enforced signature check to support the kernel crash dumping
> > > functionality and would like to keep CONFIG_KEXEC disabled for
> > > security reasons [1].
> > >
> > > I was reading the long commit message, but the reason for adding
> > > CONFIG_KEXEC as a dependency for CONFIG_CRASH_DUMP evaded me. And I
> > > believe from the implementation perspective CONFIG_KEXEC_FILE should
> > > suffice here (as we successfully used it for crashdumps on Linux 6.1).
> > >
> > > Is there a reason for adding this dependency or is it just an
> > > oversight? Would some solution of requiring either CONFIG_KEXEC or
> > > CONFIG_KEXEC_FILE work here?
> >
> > I searched the patch history, found Eric didn't add the dependency on
> > CONFIG_KEXEC at the beginning. Later a linux-next building failure with
> > randconfig was reported, in there CONFIG_CRASH_DUMP enabled, while
> > CONFIG_KEXEC is disabled. Finally Eric added the KEXEC dependency for
> > CRASH_DUMP. Please see below link for more details:
> >
> > https://lore.kernel.org/all/3e8eecd1-a277-2cfb-690e-5de2eb7b988e@oracle.com/T/#u
> 
> Thank you for digging this up. However I'm still confused, because
> this is exactly how we configure Linux 6.1 (although we do have
> CONFIG_KEXEC_FILE enabled) and we don't have any problems. I believe
> we did not investigate this issue properly.
> 
> > And besides, the newly added CONFIG_CRASH_HOTPLUG also needs
> > CONFIG_KEXEC if the elfcorehdr is allowed to be manipulated when
> > cpu/memory hotplug hapened.
> 
> This still feels like a regression to me: any crash dump support
> should be independent of KEXEC syscalls being present. While probably
> the common case (including us) that the crashing kernel and recovery
> kernel are the same, they don't have to be. We need kexec syscall in
> the crashing kernel, but crashdump support in the recovery kernel (but
> the recovery kernel not having the kexec syscalls should be totally
> fine). If we do require some code definitions from kexec - at most we
> should put them under CONFIG_KEXEC_CORE.

Hmm, I understand your concern. Will wait for Eric a while to see if he
has any explannation or plan, otherwise I will check this.


WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Ignat Korchagin <ignat@cloudflare.com>
Cc: eric_devolder@yahoo.com, linux@armlinux.org.uk,
	catalin.marinas@arm.com, will@kernel.org, chenhuacai@kernel.org,
	geert@linux-m68k.org, tsbogend@alpha.franken.de,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	deller@gmx.de, ysato@users.sourceforge.jp, dalias@libc.org,
	glaubitz@physik.fu-berlin.de,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	dave.hansen@linux.intel.com, x86@kernel.org,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org,
	loongarch@lists.linux.dev, linux-m68k@lists.linux-m68k.org,
	linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
	linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
	kernel@xen0n.name, mpe@ellerman.id.au, npiggin@gmail.com,
	christophe.leroy@csgroup.eu, paul.walmsley@sifive.com,
	palmer@dabbelt.com, aou@eecs.berkeley.edu, hca@linux.ibm.com,
	gor@linux.ibm.com, agordeev@linux.ibm.com,
	borntraeger@linux.ibm.com, svens@linux.ibm.com, hpa@zytor.com,
	keescook@chromium.org, paulmck@kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	frederic@kernel.org, Andrew Morton <akpm@linux-foundation.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	samitolvanen@google.com, juerg.haefliger@canonical.com,
	arnd@arndb.de, rmk+kernel@armlinux.org.uk,
	linus.walleij@linaro.org, sebastian.reichel@collabora.com,
	rppt@kernel.org, kirill.shutemov@linux.intel.com,
	anshuman.khandual@arm.com, ziy@nvidia.com, masahiroy@kernel.org,
	ndesaulniers@google.com, mhiramat@kernel.org, ojeda@kernel.org,
	thunder.leizhen@huawei.com, xin3.li@intel.com, tj@kernel.org,
	Greg KH <gregkh@linuxfoundation.org>,
	tsi@tuyoix.net, hbathini@linux.ibm.com,
	sourabhjain@linux.ibm.com, boris.ostrovsky@oracle.com,
	konrad.wilk@oracle.com, kernel-team <kernel-team@cloudflare.com>
Subject: Re: Potential config regression after 89cde455 ("kexec: consolidate kexec and crash options into kernel/Kconfig.kexec")
Date: Tue, 21 Nov 2023 17:56:42 +0800	[thread overview]
Message-ID: <ZVx+2lfTckjv/kiq@MiWiFi-R3L-srv> (raw)
In-Reply-To: <CALrw=nG8xsYw7XKyL_VMHtKiaBcQCKvC8UVp-C9-BdeN4A1Daw@mail.gmail.com>

On 11/21/23 at 07:53am, Ignat Korchagin wrote:
> On Tue, Nov 21, 2023 at 1:50 AM Baoquan He <bhe@redhat.com> wrote:
> >
> > Eric DeVolder's Oracle mail address is not available anymore, add his
> > current mail address he told me.
> 
> Thank you!
> 
> > On 11/20/23 at 10:52pm, Ignat Korchagin wrote:
> > > Good day!
> > >
> > > We have recently started to evaluate Linux 6.6 and noticed that we
> > > cannot disable CONFIG_KEXEC anymore, but keep CONFIG_CRASH_DUMP
> > > enabled. It seems to be related to commit 89cde455 ("kexec:
> > > consolidate kexec and crash options into kernel/Kconfig.kexec"), where
> > > a CONFIG_KEXEC dependency was added to CONFIG_CRASH_DUMP.
> > >
> > > In our current kernel (Linux 6.1) we only enable CONFIG_KEXEC_FILE
> > > with enforced signature check to support the kernel crash dumping
> > > functionality and would like to keep CONFIG_KEXEC disabled for
> > > security reasons [1].
> > >
> > > I was reading the long commit message, but the reason for adding
> > > CONFIG_KEXEC as a dependency for CONFIG_CRASH_DUMP evaded me. And I
> > > believe from the implementation perspective CONFIG_KEXEC_FILE should
> > > suffice here (as we successfully used it for crashdumps on Linux 6.1).
> > >
> > > Is there a reason for adding this dependency or is it just an
> > > oversight? Would some solution of requiring either CONFIG_KEXEC or
> > > CONFIG_KEXEC_FILE work here?
> >
> > I searched the patch history, found Eric didn't add the dependency on
> > CONFIG_KEXEC at the beginning. Later a linux-next building failure with
> > randconfig was reported, in there CONFIG_CRASH_DUMP enabled, while
> > CONFIG_KEXEC is disabled. Finally Eric added the KEXEC dependency for
> > CRASH_DUMP. Please see below link for more details:
> >
> > https://lore.kernel.org/all/3e8eecd1-a277-2cfb-690e-5de2eb7b988e@oracle.com/T/#u
> 
> Thank you for digging this up. However I'm still confused, because
> this is exactly how we configure Linux 6.1 (although we do have
> CONFIG_KEXEC_FILE enabled) and we don't have any problems. I believe
> we did not investigate this issue properly.
> 
> > And besides, the newly added CONFIG_CRASH_HOTPLUG also needs
> > CONFIG_KEXEC if the elfcorehdr is allowed to be manipulated when
> > cpu/memory hotplug hapened.
> 
> This still feels like a regression to me: any crash dump support
> should be independent of KEXEC syscalls being present. While probably
> the common case (including us) that the crashing kernel and recovery
> kernel are the same, they don't have to be. We need kexec syscall in
> the crashing kernel, but crashdump support in the recovery kernel (but
> the recovery kernel not having the kexec syscalls should be totally
> fine). If we do require some code definitions from kexec - at most we
> should put them under CONFIG_KEXEC_CORE.

Hmm, I understand your concern. Will wait for Eric a while to see if he
has any explannation or plan, otherwise I will check this.


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

WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Ignat Korchagin <ignat@cloudflare.com>
Cc: chenhuacai@kernel.org, linux-ia64@vger.kernel.org,
	linux-sh@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
	catalin.marinas@arm.com, linus.walleij@linaro.org,
	dave.hansen@linux.intel.com, linux-mips@vger.kernel.org,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	dalias@libc.org, eric_devolder@yahoo.com,
	linux-riscv@lists.infradead.org, will@kernel.org,
	kernel@xen0n.name, tsi@tuyoix.net, linux-s390@vger.kernel.org,
	agordeev@linux.ibm.com, rmk+kernel@armlinux.org.uk,
	hpa@zytor.com, paulmck@kernel.org, ysato@users.sourceforge.jp,
	kernel-team <kernel-team@cloudflare.com>,
	deller@gmx.de, x86@kernel.org, linux@armlinux.org.uk,
	paul.walmsley@sifive.com, Ingo Molnar <mingo@redhat.com>,
	geert@linux-m68k.org, hbathini@linux.ibm.com,
	samitolvanen@google.com, ojeda@kernel.org,
	juerg.haefliger@canonical.com, borntraeger@linux.ibm.com,
	frederic@kernel.org, arnd@arndb.de, mhiramat@kernel.org,
	Ard Biesheuvel <ardb@kernel.org>,
	thunder.leizhen@huawei.com, aou@eecs.berkeley.edu,
	 keescook@chromium.org, gor@linux.ibm.com,
	anshuman.khandual@arm.com, hca@linux.ibm.com, xin3.li@intel.com,
	npiggin@gmail.com, konrad.wilk@oracle.com,
	linux-m68k@lists.linux-m68k.org, Borislav Petkov <bp@alien8.de>,
	loongarch@lists.linux.dev, glaubitz@physik.fu-berlin.de,
	Thomas Gleixner <tglx@linutronix.de>,
	ziy@nvidia.com, linux-arm-kernel@lists.infradead.org,
	boris.ostrovsky@oracle.com, tsbogend@alpha.franken.de,
	sebastian.reichel@collabora.com, linux-parisc@vger.kernel.org,
	Greg KH <gregkh@linuxfoundation.org>,
	kirill.shutemov@linux.intel.com, ndesaulniers@google.com,
	linux-kernel <linux-kernel@vger.kernel.org>,
	sourabhjain@linux.ibm.com, palmer@dabbelt.com,
	svens@linux.ibm.com, tj@kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	linuxppc-dev@lists.ozlabs.org, masahiroy@kernel.org,
	rppt@kernel.org
Subject: Re: Potential config regression after 89cde455 ("kexec: consolidate kexec and crash options into kernel/Kconfig.kexec")
Date: Tue, 21 Nov 2023 17:56:42 +0800	[thread overview]
Message-ID: <ZVx+2lfTckjv/kiq@MiWiFi-R3L-srv> (raw)
In-Reply-To: <CALrw=nG8xsYw7XKyL_VMHtKiaBcQCKvC8UVp-C9-BdeN4A1Daw@mail.gmail.com>

On 11/21/23 at 07:53am, Ignat Korchagin wrote:
> On Tue, Nov 21, 2023 at 1:50 AM Baoquan He <bhe@redhat.com> wrote:
> >
> > Eric DeVolder's Oracle mail address is not available anymore, add his
> > current mail address he told me.
> 
> Thank you!
> 
> > On 11/20/23 at 10:52pm, Ignat Korchagin wrote:
> > > Good day!
> > >
> > > We have recently started to evaluate Linux 6.6 and noticed that we
> > > cannot disable CONFIG_KEXEC anymore, but keep CONFIG_CRASH_DUMP
> > > enabled. It seems to be related to commit 89cde455 ("kexec:
> > > consolidate kexec and crash options into kernel/Kconfig.kexec"), where
> > > a CONFIG_KEXEC dependency was added to CONFIG_CRASH_DUMP.
> > >
> > > In our current kernel (Linux 6.1) we only enable CONFIG_KEXEC_FILE
> > > with enforced signature check to support the kernel crash dumping
> > > functionality and would like to keep CONFIG_KEXEC disabled for
> > > security reasons [1].
> > >
> > > I was reading the long commit message, but the reason for adding
> > > CONFIG_KEXEC as a dependency for CONFIG_CRASH_DUMP evaded me. And I
> > > believe from the implementation perspective CONFIG_KEXEC_FILE should
> > > suffice here (as we successfully used it for crashdumps on Linux 6.1).
> > >
> > > Is there a reason for adding this dependency or is it just an
> > > oversight? Would some solution of requiring either CONFIG_KEXEC or
> > > CONFIG_KEXEC_FILE work here?
> >
> > I searched the patch history, found Eric didn't add the dependency on
> > CONFIG_KEXEC at the beginning. Later a linux-next building failure with
> > randconfig was reported, in there CONFIG_CRASH_DUMP enabled, while
> > CONFIG_KEXEC is disabled. Finally Eric added the KEXEC dependency for
> > CRASH_DUMP. Please see below link for more details:
> >
> > https://lore.kernel.org/all/3e8eecd1-a277-2cfb-690e-5de2eb7b988e@oracle.com/T/#u
> 
> Thank you for digging this up. However I'm still confused, because
> this is exactly how we configure Linux 6.1 (although we do have
> CONFIG_KEXEC_FILE enabled) and we don't have any problems. I believe
> we did not investigate this issue properly.
> 
> > And besides, the newly added CONFIG_CRASH_HOTPLUG also needs
> > CONFIG_KEXEC if the elfcorehdr is allowed to be manipulated when
> > cpu/memory hotplug hapened.
> 
> This still feels like a regression to me: any crash dump support
> should be independent of KEXEC syscalls being present. While probably
> the common case (including us) that the crashing kernel and recovery
> kernel are the same, they don't have to be. We need kexec syscall in
> the crashing kernel, but crashdump support in the recovery kernel (but
> the recovery kernel not having the kexec syscalls should be totally
> fine). If we do require some code definitions from kexec - at most we
> should put them under CONFIG_KEXEC_CORE.

Hmm, I understand your concern. Will wait for Eric a while to see if he
has any explannation or plan, otherwise I will check this.


  parent reply	other threads:[~2023-11-21  9:56 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-20 22:52 Potential config regression after 89cde455 ("kexec: consolidate kexec and crash options into kernel/Kconfig.kexec") Ignat Korchagin
2023-11-20 22:52 ` Ignat Korchagin
2023-11-20 22:52 ` Ignat Korchagin
2023-11-21  1:05 ` Michael Ellerman
2023-11-21  1:05   ` Michael Ellerman
2023-11-21  1:05   ` Michael Ellerman
2023-11-21  1:50 ` Baoquan He
2023-11-21  1:50   ` Baoquan He
2023-11-21  1:50   ` Baoquan He
2023-11-21  7:53   ` Ignat Korchagin
2023-11-21  7:53     ` Ignat Korchagin
2023-11-21  7:53     ` Ignat Korchagin
2023-11-21  9:43     ` Ignat Korchagin
2023-11-21  9:43       ` Ignat Korchagin
2023-11-21  9:43       ` Ignat Korchagin
2023-11-22  9:34       ` Baoquan He
2023-11-22  9:34         ` Baoquan He
2023-11-22  9:34         ` Baoquan He
2023-11-22  9:47         ` Ignat Korchagin
2023-11-22  9:47           ` Ignat Korchagin
2023-11-22  9:47           ` Ignat Korchagin
2023-11-23  8:27           ` Baoquan He
2023-11-23  8:27             ` Baoquan He
2023-11-23  8:27             ` Baoquan He
2023-11-21  9:56     ` Baoquan He [this message]
2023-11-21  9:56       ` Baoquan He
2023-11-21  9:56       ` Baoquan He

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=ZVx+2lfTckjv/kiq@MiWiFi-R3L-srv \
    --to=bhe@redhat.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=agordeev@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=boris.ostrovsky@oracle.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=chenhuacai@kernel.org \
    --cc=christophe.leroy@csgroup.eu \
    --cc=dalias@libc.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=deller@gmx.de \
    --cc=eric_devolder@yahoo.com \
    --cc=frederic@kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=gor@linux.ibm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hbathini@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=hpa@zytor.com \
    --cc=ignat@cloudflare.com \
    --cc=juerg.haefliger@canonical.com \
    --cc=keescook@chromium.org \
    --cc=kernel-team@cloudflare.com \
    --cc=kernel@xen0n.name \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=loongarch@lists.linux.dev \
    --cc=masahiroy@kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mingo@redhat.com \
    --cc=mpe@ellerman.id.au \
    --cc=ndesaulniers@google.com \
    --cc=npiggin@gmail.com \
    --cc=ojeda@kernel.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rmk+kernel@armlinux.org.uk \
    --cc=rppt@kernel.org \
    --cc=samitolvanen@google.com \
    --cc=sebastian.reichel@collabora.com \
    --cc=sourabhjain@linux.ibm.com \
    --cc=svens@linux.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=thunder.leizhen@huawei.com \
    --cc=tj@kernel.org \
    --cc=tsbogend@alpha.franken.de \
    --cc=tsi@tuyoix.net \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    --cc=xin3.li@intel.com \
    --cc=ysato@users.sourceforge.jp \
    --cc=ziy@nvidia.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.