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: 86+ 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-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: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: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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).