From: Ulf Magnusson <ulfalizer@gmail.com>
To: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Kees Cook <keescook@chromium.org>,
Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Nicolas Pitre <nicolas.pitre@linaro.org>,
"Luis R . Rodriguez" <mcgrof@suse.com>,
Randy Dunlap <rdunlap@infradead.org>,
Sam Ravnborg <sam@ravnborg.org>,
Michal Marek <michal.lkml@markovi.net>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
Pavel Machek <pavel@ucw.cz>,
linux-s390 <linux-s390@vger.kernel.org>,
Jiri Kosina <jkosina@suse.cz>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 4/7] kconfig: support new special property shell=
Date: Sat, 10 Feb 2018 10:21:24 +0100 [thread overview]
Message-ID: <20180210092124.im7x2qs5xbkyebr7@huvuddator> (raw)
In-Reply-To: <20180210085519.737ckf4bcl57h4g2@huvuddator>
On Sat, Feb 10, 2018 at 09:55:19AM +0100, Ulf Magnusson wrote:
> On Sat, Feb 10, 2018 at 09:05:56AM +0100, Ulf Magnusson wrote:
> > On Sat, Feb 10, 2018 at 08:49:24AM +0100, Ulf Magnusson wrote:
> > > On Sat, Feb 10, 2018 at 04:12:13PM +0900, Masahiro Yamada wrote:
> > > > 2018-02-10 14:48 GMT+09:00 Ulf Magnusson <ulfalizer@gmail.com>:
> > > > > On Fri, Feb 09, 2018 at 12:46:54PM -0800, Kees Cook wrote:
> > > > >> On Fri, Feb 9, 2018 at 4:46 AM, Ulf Magnusson <ulfalizer@gmail.com> wrote:
> > > > >> > One thing that makes Kconfig confusing (though it works well enough in
> > > > >> > practice) is that .config files both record user selections (the saved
> > > > >> > configuration) and serve as a configuration output format for make.
> > > > >> >
> > > > >> > It becomes easier to think about .config files once you realize that
> > > > >> > assignments to promptless symbols never have an effect on Kconfig
> > > > >> > itself: They're just configuration output, intermixed with the saved
> > > > >> > user selections.
> > > > >> >
> > > > >> > Assume 'option env' symbols got written out for example:
> > > > >> >
> > > > >> > - For a non-user-assignable symbol, the entry in the .config
> > > > >> > file is just configuration output and ignored by Kconfig,
> > > > >> > which will fetch the value from the environment instead.
> > > > >> >
> > > > >> > - For an assignable 'option env' symbol, the entry in the
> > > > >> > .config file is a saved user selection (as well as
> > > > >> > configuration output), and will be respected by Kconfig.
> > > > >>
> > > > >> In the stack-protector case, this becomes quite important, since the
> > > > >> goal is to record the user's selection regardless of compiler
> > > > >> capability. For example, if someone selects _REGULAR, it shouldn't
> > > > >> "upgrade" to _STRONG. (Similarly for _NONE.) Having _AUTO provides a
> > > > >> way to pick "best possible for this compiler", though. If a user had
> > > > >> previously selected _STRONG but they're doing builds with an older
> > > > >> compiler (or a misconfigured newer compiler) without support, the goal
> > > > >> is to _fail_ to build, not silently select _REGULAR.
> > > > >>
> > > > >> So, in this case, what's gained is the logic for _AUTO, and the logic
> > > > >> to not show, say, _STRONG when it's not available in the compiler. But
> > > > >> we must still fail to build if _STRONG was in the .config. It can't
> > > > >> silently rewrite it to _REGULAR because the compiler support for
> > > > >> _STRONG regressed.
> > > > >>
> > > > >> -Kees
> > > > >>
> > > > >> --
> > > > >> Kees Cook
> > > > >> Pixel Security
> > > > >
> > > > > Provided that would be the desired behavior:
> > > > >
> > > > > What about changing the meaning of the choice symbols from e.g. "select
> > > > > -fstack-protector-strong" to "want -fstack-protector-strong"? Then the
> > > > > user preference would always be remembered, regardless of what's
> > > > > available.
> > > > >
> > > > > Here's a proof-of-concept. I realized that the fancy new 'imply' keyword
> > > > > fits pretty well here, since it works like a dependency-respecting
> > > > > select.
> > > > >
> > > > > config CC_HAS_STACKPROTECTOR_STRONG
> > > > > bool
> > > > > option shell="$CC -Werror -fstack-protector-strong -c -x c /dev/null"
> > > > >
> > > > > config CC_HAS_STACKPROTECTOR
> > > > > bool
> > > > > option shell="$CC -Werror -fstack-protector -c -x c /dev/null"
> > > > >
> > > > >
> > > > > choice
> > > > > prompt "Stack Protector buffer overflow detection"
> > > > > default WANT_CC_STACKPROTECTOR_STRONG
> > > > >
> > > > > config WANT_CC_STACKPROTECTOR_STRONG
> > > > > bool "Strong"
> > > > > imply CC_STACKPROTECTOR_STRONG
> > > > >
> > > > > config WANT_CC_STACKPROTECTOR_REGULAR
> > > > > bool "Regular"
> > > > > imply CC_STACKPROTECTOR_REGULAR
> > > > >
> > > > > config WANT_CC_STACKPROTECTOR_NONE
> > > > > bool "None"
> > > > > imply CC_STACKPROTECTOR_NONE
> > > > >
> > > > > endchoice
> > > > >
> > > > >
> > > > > config CC_STACKPROTECTOR_STRONG
> > > > > bool
> > > > > depends on CC_HAS_STACKPROTECTOR_STRONG
> > > >
> > > >
> > > > Do you mean
> > > >
> > > > config CC_STACKPROTECTOR_STRONG
> > > > bool
> > > > depends on CC_HAS_STACKPROTECTOR_STRONG && \
> > > > WANT_CC_STACKPROTECTOR_STRONG
> > > >
> > > > or, maybe
> > > >
> > > >
> > > > config CC_STACKPROTECTOR_STRONG
> > > > bool
> > > > depends on CC_HAS_STACKPROTECTOR_STRONG
> > > > default WANT_CC_STACKPROTECTOR_STRONG
> > > >
> > > > ?
> > >
> > > With the 'imply', it should work with just the 'depends on'. I had your
> > > last version earlier though, and it works too.
> > >
> > > 'imply' kinda makes sense, as in "turn on the strong stack protector if
> > > its dependencies are satisfied".
> > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > config CC_STACKPROTECTOR_REGULAR
> > > > > bool
> > > > > depends on CC_HAS_STACKPROTECTOR_REGULAR
> > > > >
> > > > > config CC_STACKPROTECTOR_NONE
> > > > > bool
> > > > >
> > > > > This version has the drawback of always showing all the options, even if
> > > > > some they wouldn't be available. Kconfig comments could be added to warn
> > > > > if an option isn't available at least:
> > > > >
> > > > > comment "Warning: Your compiler does not support -fstack-protector-strong"
> > > > > depends on !CC_HAS_STACKPROTECTOR_STRONG
> > > > >
> > > > > config WANT_CC_STACKPROTECTOR_STRONG
> > > > > ...
> > > > >
> > > > >
> > > > > comment "Warning: Your compiler does not support -fstack-protector"
> > > > > depends on !CC_HAS_STACKPROTECTOR_REGULAR
> > > > >
> > > > > config WANT_CC_STACKPROTECTOR_REGULAR
> > > > > ...
> > > > >
> > > > > This final comment might be nice to have too:
> > > > >
> > > > > comment "Warning: Selected stack protector not available"
> > > > > depends on !(CC_STACKPROTECTOR_STRONG ||
> > > > > CC_STACKPROTECTOR_REGULAR ||
> > > > > CC_STACKPROTECTOR_NONE)
> > > > >
> > > > > Should probably introduce a clear warning that tells the user what they
> > > > > need to change in Kconfig if they build with a broken selection too.
> > > > >
> > > > >
> > > > > CC_STACKPROTECTOR_AUTO could be added to the choice in a slightly kludgy
> > > > > way too. Maybe there's something neater.
> > > > >
> > > > > config CC_STACKPROTECTOR_AUTO
> > > > > bool "Automatic"
> > > > > imply CC_STACKPROTECTOR_STRONG
> > > > > imply CC_STACKPROTECTOR_REGULAR if !CC_HAS_STACKPROTECTOR_STRONG
> > > > > imply CC_STACKPROTECTOR_NONE if !CC_HAS_STACKPROTECTOR_STRONG && \
> > > > > !CC_HAS_STACKPROTECTOR_REGULAR
> > > > >
> > > > >
> > > > > Another drawback of this approach is that it breaks existing .config
> > > > > files (the CC_STACKPROTECTOR_* settings are ignored, since they just
> > > > > look like "configuration output" to Kconfig now). If that'd be a
> > > > > problem, the old names could be used instead of
> > > > > WANT_CC_STACKPROTECTOR_STRONG, etc., and new names introduced instead,
> > > > > though it'd look a bit cryptic.
> > > > >
> > > > > Ideas?
> > > > >
> > > >
> > > >
> > > >
> > > > FWIW, the following is what I was playing with.
> > > > (The idea for emitting warnings is Ulf's idea)
> > > >
> > > >
> > > > ------------------>8-------------------
> > > > config CC
> > > > string
> > > > option env="CC"
> > > >
> > > > config CC_HAS_STACKPROTECTOR
> > > > bool
> > > > option shell="$CC -Werror -fstack-protector -c -x c /dev/null"
> > > >
> > > > config CC_HAS_STACKPROTECTOR_STRONG
> > > > bool
> > > > option shell="$CC -Werror -fstack-protector-strong -c -x c /dev/null"
> > > >
> > > > config CC_HAS_STACKPROTECTOR_NONE
> > > > bool
> > > > option shell="$CC -Werror -fno-stack-protector -c -x c /dev/null"
> > > >
> > > > config CC_STACKPROTECTOR
> > > > bool
> > > >
> > > > choice
> > > > prompt "Stack Protector buffer overflow detection"
> > > >
> > > > config CC_STACKPROTECTOR_AUTO
> > > > bool "Auto"
> > > > select CC_STACKPROTECTOR if (CC_HAS_STACKPROTECTOR || \
> > > > CC_HAS_STACKPROTECTOR_STRONG)
> > >
> > > With this approach, I guess you would still need to handle the
> > > CC_STACKPROTECTOR_AUTO logic outside of Kconfig, since e.g.
> > > CC_STACKPROTECTOR_STRONG won't get enabled automatically if supported.
> > >
> > > The idea above was to make it "internal" to the Kconfig files (though it
> > > still gets written out), with the
> > > CC_STACKPROTECTOR_{REGULAR,STRONG,NONE} variables automatically getting
> > > set as appropriate.
> >
> > That was a confusing way of putting it -- sorry about that.
> >
> > What I meant was that it would just be a user selection, with all the
> > logic of selecting one of CC_STACKPROTECTOR_{REGULAR,STRONG,NONE} being
> > handled internally in the Kconfig files, even in the
> > CC_STACKPROTECTOR_AUTO case.
> >
> > Nothing outside of Kconfig would need to check CC_STACKPROTECTOR_AUTO
> > then.
> >
> > >
> > > The build could then the detect if none of
> > > CC_STACKPROTECTOR_{REGULAR,STRONG,NONE} are set and do what's
> > > appropriate (error out in some semi-helpful way or whatever... not
> > > deeply familiar with kernel policy here :).
> > >
> > > >
> > > > config CC_STACKPROTECTOR_REGULAR
> > > > bool "Regular"
> > > > select CC_STACKPROTECTOR
> > > >
> > > > config CC_STACKPROTECTOR_STRONG
> > > > bool "Strong"
> > > > select CC_STACKPROTECTOR
> > > >
> > > > config CC_STACKPROTECTOR_NONE
> > > > bool "None"
> > > >
> > > > endchoice
> > > >
> > > >
> > > > comment "(WARNING) stackprotecter was chosen, but your compile does
> > > > not support it. Build will fail"
> > > > depends on CC_STACKPROTECTOR_REGULAR && \
> > > > !CC_HAS_STACKPROTECTOR
> > > >
> > > > comment "(WARNING) stackprotecter-strong was chosen, but your compile
> > > > does not support it. Build will fail"
> > > > depends on CC_STACKPROTECTOR_STRONG && \
> > > > !CC_HAS_STACKPROTECTOR_STRONG
> > > > ------------------------->8---------------------------------
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > BTW, setting option flags in Makefile is dirty, like follows:
> > > >
> > > >
> > > > ccflags-$(CONFIG_CC_STACKPROTECTOR_STRONG) += -fstack-protector-strong
> > > > ccflags-$(CONFIG_CC_STACKPROTECTOR_REGULAR) += -fstack-protector
> > > >
> > > > if ($(CONFIG_CC_STACKPROTECTOR_AUTO),y)
> > > > ccflags-$(CONFIG_CC_HAS_STACKPROTECTOR) += -fstack-protector
> > > > ccflags-$(CONFIG_CC_HAS_STACKPROTECTOR_STRONG) += -fstack-protector-strong
> > > > ccflags-$(CONFIG_CC_HAS_STACKPROTECTOR_NONE) += -fno-stack-protector
> > > > endif
> > > >
> > > > if ($(CONFIG_CC_STACKPROTECTOR_NONE),y)
> > > > ccflags-$(CONFIG_CC_HAS_STACKPROTECTOR_NONE) += -fno-stack-protector
> > > > endif
> > > >
> > > >
> > > >
> > > >
> > > > One idea could be to calculate the compiler option in Kconfig.
> > > >
> > > > config CC_OPT_STACKPROTECTOR
> > > > string
> > > > default "-fstack-protector-strong" if CC_STACKPROTECTOR_STRONG || \
> > > > (CC_STACKPROTECTOR_AUTO && \
> > > > CC_HAS_STACKPROTECTOR_STRONG)
> > > > default "-fstack-protector" if CC_STACKPROTECTOR_REGULAR || \
> > > > (CC_STACKPROTECTOR_AUTO && \
> > > > CC_HAS_STACKPROTECTOR)
> > > > default "-fno-stack-protector" if CC_HAS_STACKPROTECTOR_NONE
> > >
> > > If CC_STACKPROTECTOR_AUTO is made "internal", this could be simplified
> > > to something like
> > >
> > > config CC_OPT_STACKPROTECTOR
> > > string
> > > default "-fstack-protector-strong" if CC_STACKPROTECTOR_STRONG
> > > default "-fstack-protector" if CC_STACKPROTECTOR_REGULAR
> > > default "-fno-stack-protector" if CC_HAS_STACKPROTECTOR_NONE
> > > # If the compiler doesn't even support
> > > # -fno-stack-protector
> > > default ""
> > >
> > > (Last default is just to make the empty string explicit. That's the
> > > value it would get anyway.)
> > >
> > > >
> > > >
> > > >
> > > > Makefile will become clean.
> > > > Of course, this is at the cost of ugliness in Kconfig.
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards
> > > > Masahiro Yamada
> > >
> > > Please tell me if I've misunderstood some aspect of the old behavior.
> > >
> > > Cheers,
> > > Ulf
> >
> > Cheers,
> > Ulf
>
> Here's a complete updated example, with some stuff from Masahiro added.
>
> Turns out warnings inside choices get cut off easily in menuconfig, so I
> went with just a single warning instead (which should be enough anyway).
>
> With this version, the only "outputs" that the Makefiles needs to look
> at are CC_STACKPROTECTOR_{STRONG,REGULAR,NONE} (and
> CC_OPT_STACKPROTECTOR). WANT_CC_OPT_STACKPROTECTOR_AUTO is handled
> automatically.
>
> The caveat related to old .config files mentioned above still applies.
>
> How many compilers don't support -fno-stack-protector by the way?
>
> config CC_HAS_STACKPROTECTOR_STRONG
> bool
> option shell="$CC -Werror -fstack-protector-strong -c -x c /dev/null"
>
> config CC_HAS_STACKPROTECTOR_REGULAR
> bool
> option shell="$CC -Werror -fstack-protector -c -x c /dev/null"
>
> config CC_HAS_STACKPROTECTOR_NONE
> bool
> default y
This default is left-over testing stuff. Sorry about that.
> option shell="$CC -Werror -fno-stack-protector -c -x c /dev/null"
>
>
> choice
> prompt "Stack Protector buffer overflow detection"
> default WANT_CC_STACKPROTECTOR_AUTO
>
> config WANT_CC_STACKPROTECTOR_AUTO
> bool "Automatic"
> imply CC_STACKPROTECTOR_STRONG
> imply CC_STACKPROTECTOR_REGULAR if !CC_HAS_STACKPROTECTOR_STRONG
> imply CC_STACKPROTECTOR_NONE if !CC_HAS_STACKPROTECTOR_STRONG && \
> !CC_HAS_STACKPROTECTOR_REGULAR
>
> config WANT_CC_STACKPROTECTOR_STRONG
> bool "Strong"
> imply CC_STACKPROTECTOR_STRONG
>
> config WANT_CC_STACKPROTECTOR_REGULAR
> bool "Regular"
> imply CC_STACKPROTECTOR_REGULAR
>
> config WANT_CC_STACKPROTECTOR_NONE
> bool "None"
> imply CC_STACKPROTECTOR_NONE
>
> endchoice
>
> comment "Warning: Selected stack protector not available"
> depends on !(CC_STACKPROTECTOR_STRONG || \
> CC_STACKPROTECTOR_REGULAR || \
> CC_STACKPROTECTOR_NONE)
>
>
> config CC_STACKPROTECTOR_STRONG
> bool
> depends on CC_HAS_STACKPROTECTOR_STRONG
>
> config CC_STACKPROTECTOR_REGULAR
> bool
> depends on CC_HAS_STACKPROTECTOR_REGULAR
>
> config CC_STACKPROTECTOR_NONE
> bool
>
>
> config CC_OPT_STACKPROTECTOR
> string
> default "-fstack-protector-strong" if CC_STACKPROTECTOR_STRONG
> default "-fstack-protector" if CC_STACKPROTECTOR_REGULAR
> default "-fno-stack-protector" if CC_HAS_STACKPROTECTOR_NONE
> # If the compiler doesn't even support
> # -fno-stack-protector
> default ""
>
> Of course, at some point you're just moving complexity from one place to
> another. Maybe this all-Kconfig approach isn't worth it if people find
> it harder to understand. I don't know how bad the Makefiles are here at
> the moment.
>
> Cheers,
> Ulf
Cheers,
Ulf
next prev parent reply other threads:[~2018-02-10 9:21 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-08 16:19 [RFC PATCH 0/7] Kconfig: add new special property shell= to test compiler options in Kconfig Masahiro Yamada
2018-02-08 16:19 ` [RFC PATCH 1/7] kbuild: remove kbuild cache Masahiro Yamada
2018-02-08 16:19 ` [RFC PATCH 2/7] kconfig: add xrealloc() helper Masahiro Yamada
2018-02-08 16:19 ` [RFC PATCH 3/7] kconfig: remove const qualifier from sym_expand_string_value() Masahiro Yamada
2018-02-08 16:19 ` [RFC PATCH 4/7] kconfig: support new special property shell= Masahiro Yamada
2018-02-09 5:30 ` Ulf Magnusson
2018-02-09 9:19 ` Masahiro Yamada
2018-02-09 12:46 ` Ulf Magnusson
2018-02-09 20:46 ` Kees Cook
2018-02-10 5:48 ` Ulf Magnusson
2018-02-10 7:12 ` Masahiro Yamada
2018-02-10 7:49 ` Ulf Magnusson
2018-02-10 8:05 ` Ulf Magnusson
2018-02-10 8:55 ` Ulf Magnusson
2018-02-10 9:21 ` Ulf Magnusson [this message]
2018-02-10 18:05 ` Randy Dunlap
2018-02-11 2:00 ` Kevin Easton
2018-02-10 19:23 ` Kees Cook
2018-02-10 20:08 ` Linus Torvalds
2018-02-11 4:13 ` Kees Cook
2018-02-11 4:46 ` Linus Torvalds
2018-02-11 7:28 ` Linus Torvalds
2018-02-11 10:34 ` Ulf Magnusson
2018-02-11 17:56 ` Kees Cook
2018-02-11 18:13 ` Linus Torvalds
2018-02-11 19:39 ` Kees Cook
2018-02-11 19:53 ` Linus Torvalds
2018-02-11 20:06 ` Linus Torvalds
2018-02-11 21:10 ` Arnd Bergmann
2018-02-11 21:19 ` Kees Cook
2018-02-11 21:50 ` Linus Torvalds
2018-02-12 10:44 ` Arnd Bergmann
2018-02-12 10:44 ` Arnd Bergmann
2018-02-11 22:29 ` Geert Uytterhoeven
2018-02-15 23:38 ` [RFC PATCH 4/7] kconfig: support new special property shell Palmer Dabbelt
2018-02-11 21:11 ` [RFC PATCH 4/7] kconfig: support new special property shell= Kees Cook
2018-02-11 19:42 ` Linus Torvalds
2018-02-12 8:26 ` Peter Zijlstra
2018-02-12 10:27 ` Thomas Gleixner
2018-02-12 11:52 ` Peter Zijlstra
2018-02-12 16:19 ` David Woodhouse
2018-02-12 16:19 ` David Woodhouse
2018-02-12 16:56 ` Kees Cook
2018-02-12 17:05 ` Peter Zijlstra
2018-02-12 17:33 ` Kees Cook
2018-02-12 17:36 ` David Woodhouse
2018-02-12 17:36 ` David Woodhouse
2018-02-12 17:37 ` Kees Cook
2018-02-12 17:00 ` Peter Zijlstra
2018-02-11 18:34 ` Ulf Magnusson
2018-02-11 21:05 ` Kees Cook
2018-02-11 21:35 ` Ulf Magnusson
2018-02-11 20:29 ` Ulf Magnusson
2018-02-11 20:42 ` Ulf Magnusson
2018-02-12 12:54 ` Ulf Magnusson
2018-02-12 14:21 ` Masahiro Yamada
2018-02-12 14:23 ` Masahiro Yamada
2018-02-12 14:32 ` Ulf Magnusson
2018-02-12 14:29 ` Ulf Magnusson
2018-02-12 14:53 ` Ulf Magnusson
2018-02-12 15:22 ` Masahiro Yamada
2018-02-12 15:35 ` Ulf Magnusson
2018-02-11 21:22 ` Ulf Magnusson
2018-02-12 14:39 ` Masahiro Yamada
2018-02-12 15:24 ` Kees Cook
2018-02-12 23:48 ` Randy Dunlap
2018-02-13 1:41 ` Masahiro Yamada
2018-02-13 1:53 ` Randy Dunlap
2018-02-13 8:35 ` Arnd Bergmann
2018-02-13 8:59 ` Masahiro Yamada
2018-02-12 10:44 ` Masahiro Yamada
2018-02-12 11:44 ` Ulf Magnusson
2018-02-12 11:49 ` Ulf Magnusson
2018-02-12 13:53 ` Masahiro Yamada
2018-02-12 14:13 ` Ulf Magnusson
2018-02-12 15:46 ` Kees Cook
2018-02-12 16:10 ` Masahiro Yamada
2018-02-13 8:55 ` Ulf Magnusson
2018-02-11 16:54 ` Kees Cook
2018-02-08 16:19 ` [RFC PATCH 5/7] kconfig: invoke silentoldconfig when compiler is updated Masahiro Yamada
2018-02-08 17:19 ` Masahiro Yamada
2018-02-08 17:45 ` Linus Torvalds
2018-02-08 16:19 ` [RFC PATCH 6/7] kconfig: add basic environments to evaluate C flags in Kconfig Masahiro Yamada
2018-02-08 16:19 ` [RFC PATCH 7/7] Test stackprotector options in Kconfig to kill CC_STACKPROTECTOR_AUTO Masahiro Yamada
2018-02-08 18:30 ` Kees Cook
2018-02-09 4:13 ` Masahiro Yamada
2018-02-08 16:43 ` [RFC PATCH 0/7] Kconfig: add new special property shell= to test compiler options in Kconfig Greg Kroah-Hartman
2018-02-08 17:19 ` Linus Torvalds
2018-02-08 17:39 ` Masahiro Yamada
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=20180210092124.im7x2qs5xbkyebr7@huvuddator \
--to=ulfalizer@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=jkosina@suse.cz \
--cc=keescook@chromium.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mcgrof@suse.com \
--cc=michal.lkml@markovi.net \
--cc=nicolas.pitre@linaro.org \
--cc=pavel@ucw.cz \
--cc=rdunlap@infradead.org \
--cc=sam@ravnborg.org \
--cc=schwidefsky@de.ibm.com \
--cc=torvalds@linux-foundation.org \
--cc=yamada.masahiro@socionext.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.