Commit graph

1683 commits

Author SHA1 Message Date
Greg Kroah-Hartman
69b94dd6dc Linux 4.14.189 2020-07-22 09:22:29 +02:00
Greg Kroah-Hartman
56dfe6252c Linux 4.14.188 2020-07-09 09:36:33 +02:00
Sasha Levin
4139fb08c0 Linux 4.14.187
Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-30 16:24:19 -04:00
Greg Kroah-Hartman
f49027cf4f Linux 4.14.186 2020-06-25 15:42:02 +02:00
Greg Kroah-Hartman
c5c055bda3 Linux 4.14.185 2020-06-20 10:25:21 +02:00
Masahiro Yamada
8daebe30b6 kbuild: force to build vmlinux if CONFIG_MODVERSION=y
commit 4b50c8c4ea upstream.

This code does not work as stated in the comment.

$(CONFIG_MODVERSIONS) is always empty because it is expanded before
include/config/auto.conf is included. Hence, 'make modules' with
CONFIG_MODVERSION=y cannot record the version CRCs.

This has been broken since 2003, commit ("kbuild: Enable modules to be
build using the "make dir/" syntax"). [1]

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=15c6240cdc44bbeef3c4797ec860f9765ef4f1a7
Cc: linux-stable <stable@vger.kernel.org> # v2.5.71+
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-20 10:25:20 +02:00
Greg Kroah-Hartman
b850307b27 Linux 4.14.184 2020-06-11 09:23:02 +02:00
Greg Kroah-Hartman
c6db52a887 Linux 4.14.183 2020-06-03 08:18:13 +02:00
Greg Kroah-Hartman
4f68020fef Linux 4.14.182 2020-05-27 16:43:13 +02:00
Greg Kroah-Hartman
a41ba30d9d Linux 4.14.181 2020-05-20 08:17:19 +02:00
Sergei Trofimovich
b7d6e8c2f7 Makefile: disallow data races on gcc-10 as well
commit b1112139a1 upstream.

gcc-10 will rename --param=allow-store-data-races=0
to -fno-allow-store-data-races.

The flag change happened at https://gcc.gnu.org/PR92046.

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Acked-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Cc: Thomas Backlund <tmb@mageia.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-20 08:17:19 +02:00
Linus Torvalds
eaeb85d649 gcc-10: disable 'restrict' warning for now
commit adc7192096 upstream.

gcc-10 now warns about passing aliasing pointers to functions that take
restricted pointers.

That's actually a great warning, and if we ever start using 'restrict'
in the kernel, it might be quite useful.  But right now we don't, and it
turns out that the only thing this warns about is an idiom where we have
declared a few functions to be "printf-like" (which seems to make gcc
pick up the restricted pointer thing), and then we print to the same
buffer that we also use as an input.

And people do that as an odd concatenation pattern, with code like this:

    #define sysfs_show_gen_prop(buffer, fmt, ...) \
        snprintf(buffer, PAGE_SIZE, "%s"fmt, buffer, __VA_ARGS__)

where we have 'buffer' as both the destination of the final result, and
as the initial argument.

Yes, it's a bit questionable.  And outside of the kernel, people do have
standard declarations like

    int snprintf( char *restrict buffer, size_t bufsz,
                  const char *restrict format, ... );

where that output buffer is marked as a restrict pointer that cannot
alias with any other arguments.

But in the context of the kernel, that 'use snprintf() to concatenate to
the end result' does work, and the pattern shows up in multiple places.
And we have not marked our own version of snprintf() as taking restrict
pointers, so the warning is incorrect for now, and gcc picks it up on
its own.

If we do start using 'restrict' in the kernel (and it might be a good
idea if people find places where it matters), we'll need to figure out
how to avoid this issue for snprintf and friends.  But in the meantime,
this warning is not useful.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-20 08:17:11 +02:00
Linus Torvalds
d0e84b91f1 gcc-10: disable 'stringop-overflow' warning for now
commit 5a76021c2e upstream.

This is the final array bounds warning removal for gcc-10 for now.

Again, the warning is good, and we should re-enable all these warnings
when we have converted all the legacy array declaration cases to
flexible arrays. But in the meantime, it's just noise.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-20 08:17:11 +02:00
Linus Torvalds
7c29131adf gcc-10: disable 'array-bounds' warning for now
commit 44720996e2 upstream.

This is another fine warning, related to the 'zero-length-bounds' one,
but hitting the same historical code in the kernel.

Because C didn't historically support flexible array members, we have
code that instead uses a one-sized array, the same way we have cases of
zero-sized arrays.

The one-sized arrays come from either not wanting to use the gcc
zero-sized array extension, or from a slight convenience-feature, where
particularly for strings, the size of the structure now includes the
allocation for the final NUL character.

So with a "char name[1];" at the end of a structure, you can do things
like

       v = my_malloc(sizeof(struct vendor) + strlen(name));

and avoid the "+1" for the terminator.

Yes, the modern way to do that is with a flexible array, and using
'offsetof()' instead of 'sizeof()', and adding the "+1" by hand.  That
also technically gets the size "more correct" in that it avoids any
alignment (and thus padding) issues, but this is another long-term
cleanup thing that will not happen for 5.7.

So disable the warning for now, even though it's potentially quite
useful.  Having a slew of warnings that then hide more urgent new issues
is not an improvement.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-20 08:17:10 +02:00
Linus Torvalds
1a99bcaa09 gcc-10: disable 'zero-length-bounds' warning for now
commit 5c45de21a2 upstream.

This is a fine warning, but we still have a number of zero-length arrays
in the kernel that come from the traditional gcc extension.  Yes, they
are getting converted to flexible arrays, but in the meantime the gcc-10
warning about zero-length bounds is very verbose, and is hiding other
issues.

I missed one actual build failure because it was hidden among hundreds
of lines of warning.  Thankfully I caught it on the second go before
pushing things out, but it convinced me that I really need to disable
the new warnings for now.

We'll hopefully be all done with our conversion to flexible arrays in
the not too distant future, and we can then re-enable this warning.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-20 08:17:10 +02:00
Linus Torvalds
4cdd5c0c6b Stop the ad-hoc games with -Wno-maybe-initialized
commit 78a5255ffb upstream.

We have some rather random rules about when we accept the
"maybe-initialized" warnings, and when we don't.

For example, we consider it unreliable for gcc versions < 4.9, but also
if -O3 is enabled, or if optimizing for size.  And then various kernel
config options disabled it, because they know that they trigger that
warning by confusing gcc sufficiently (ie PROFILE_ALL_BRANCHES).

And now gcc-10 seems to be introducing a lot of those warnings too, so
it falls under the same heading as 4.9 did.

At the same time, we have a very straightforward way to _enable_ that
warning when wanted: use "W=2" to enable more warnings.

So stop playing these ad-hoc games, and just disable that warning by
default, with the known and straight-forward "if you want to work on the
extra compiler warnings, use W=123".

Would it be great to have code that is always so obvious that it never
confuses the compiler whether a variable is used initialized or not?
Yes, it would.  In a perfect world, the compilers would be smarter, and
our source code would be simpler.

That's currently not the world we live in, though.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-20 08:17:10 +02:00
Masahiro Yamada
859ea9726d kbuild: compute false-positive -Wmaybe-uninitialized cases in Kconfig
commit b303c6df80 upstream.

Since -Wmaybe-uninitialized was introduced by GCC 4.7, we have patched
various false positives:

 - commit e74fc973b6 ("Turn off -Wmaybe-uninitialized when building
   with -Os") turned off this option for -Os.

 - commit 815eb71e71 ("Kbuild: disable 'maybe-uninitialized' warning
   for CONFIG_PROFILE_ALL_BRANCHES") turned off this option for
   CONFIG_PROFILE_ALL_BRANCHES

 - commit a76bcf557e ("Kbuild: enable -Wmaybe-uninitialized warning
   for "make W=1"") turned off this option for GCC < 4.9
   Arnd provided more explanation in https://lkml.org/lkml/2017/3/14/903

I think this looks better by shifting the logic from Makefile to Kconfig.

Link: https://github.com/ClangBuiltLinux/linux/issues/350
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-20 08:17:10 +02:00
Greg Kroah-Hartman
ab9dfda232 Linux 4.14.180 2020-05-10 10:29:03 +02:00
Greg Kroah-Hartman
d71f695ce7 Linux 4.14.179 2020-05-05 19:15:53 +02:00
Greg Kroah-Hartman
773e2b1cd5 Linux 4.14.178 2020-05-02 17:24:47 +02:00
Greg Kroah-Hartman
050272a042 Linux 4.14.177 2020-04-24 08:01:25 +02:00
Greg Kroah-Hartman
c10b57a567 Linux 4.14.176 2020-04-13 10:34:39 +02:00
Greg Kroah-Hartman
4520f06b03 Linux 4.14.175 2020-04-02 16:34:38 +02:00
Greg Kroah-Hartman
01364dad1d Linux 4.14.174 2020-03-20 10:54:27 +01:00
Greg Kroah-Hartman
12cd844a39 Linux 4.14.173 2020-03-11 18:03:09 +01:00
Greg Kroah-Hartman
78d697fc93 Linux 4.14.172 2020-02-28 16:36:17 +01:00
Greg Kroah-Hartman
98db2bf27b Linux 4.14.171 2020-02-14 16:32:24 -05:00
Greg Kroah-Hartman
e0f8b8a65a Linux 4.14.170 2020-02-05 14:18:29 +00:00
Greg Kroah-Hartman
9fa690a2a0 Linux 4.14.169 2020-01-29 15:02:39 +01:00
Greg Kroah-Hartman
9a95f25269 Linux 4.14.168 2020-01-27 14:46:54 +01:00
Masahiro Yamada
f3691b5e7d kbuild: mark prepare0 as PHONY to fix external module build
[ Upstream commit e00d888048 ]

Commit c3ff2a5193 ("powerpc/32: add stack protector support")
caused kernel panic on PowerPC when an external module is used with
CONFIG_STACKPROTECTOR because the 'prepare' target was not executed
for the external module build.

Commit e07db28eea ("kbuild: fix single target build for external
module") turned it into a build error because the 'prepare' target is
now executed but the 'prepare0' target is missing for the external
module build.

External module on arm/arm64 with CONFIG_STACKPROTECTOR_PER_TASK is
also broken in the same way.

Move 'PHONY += prepare0' to the common place. GNU Make is fine with
missing rule for phony targets. I also removed the comment which is
wrong irrespective of this commit.

I minimize the change so it can be easily backported to 4.20.x

To fix v4.20, please backport e07db28eea ("kbuild: fix single target
build for external module"), and then this commit.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=201891
Fixes: e07db28eea ("kbuild: fix single target build for external module")
Fixes: c3ff2a5193 ("powerpc/32: add stack protector support")
Fixes: 189af46571 ("ARM: smp: add support for per-task stack canaries")
Fixes: 0a1213fa74 ("arm64: enable per-task stack canaries")
Cc: linux-stable <stable@vger.kernel.org> # v4.20
Reported-by: Samuel Holland <samuel@sholland.org>
Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-01-27 14:46:13 +01:00
Greg Kroah-Hartman
8bac50406c Linux 4.14.167 2020-01-23 08:20:37 +01:00
Greg Kroah-Hartman
c1141b3aab Linux 4.14.166 2020-01-17 19:45:55 +01:00
Greg Kroah-Hartman
c04fc6fa5c Linux 4.14.165 2020-01-14 20:05:49 +01:00
Greg Kroah-Hartman
6d0c334a40 Linux 4.14.164 2020-01-12 12:12:09 +01:00
Greg Kroah-Hartman
b0cdffaa54 Linux 4.14.163 2020-01-09 10:18:00 +01:00
Greg Kroah-Hartman
84f5ad4681 Linux 4.14.162 2020-01-04 14:00:23 +01:00
Greg Kroah-Hartman
4c5bf01e16 Linux 4.14.161 2019-12-31 12:38:09 +01:00
Greg Kroah-Hartman
e1f7d50ae3 Linux 4.14.160 2019-12-21 10:47:56 +01:00
Greg Kroah-Hartman
bfb9e5c030 Linux 4.14.159 2019-12-17 20:40:05 +01:00
Masahiro Yamada
a87bd630bc kbuild: fix single target build for external module
[ Upstream commit e07db28eea ]

Building a single target in an external module fails due to missing
.tmp_versions directory.

For example,

  $ make -C /lib/modules/$(uname -r)/build M=$PWD foo.o

will fail in the following way:

  CC [M]  /home/masahiro/foo/foo.o
/bin/sh: 1: cannot create /home/masahiro/foo/.tmp_versions/foo.mod: Directory nonexistent

This is because $(cmd_crmodverdir) is executed only before building
/, %/, %.ko single targets of external modules. Create .tmp_versions
in the 'prepare' target.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-17 20:38:31 +01:00
Greg Kroah-Hartman
a844dc4c54 Linux 4.14.158 2019-12-05 15:38:36 +01:00
Greg Kroah-Hartman
fbc5fe7a54 Linux 4.14.157 2019-12-01 09:14:37 +01:00
Greg Kroah-Hartman
43598c571e Linux 4.14.156 2019-11-24 08:23:35 +01:00
Greg Kroah-Hartman
f56f3d0e65 Linux 4.14.155 2019-11-20 18:00:54 +01:00
Greg Kroah-Hartman
775d01b65b Linux 4.14.154 2019-11-12 19:19:08 +01:00
Greg Kroah-Hartman
4762bcd451 Linux 4.14.153 2019-11-10 11:25:43 +01:00
Seth Forshee
2103cc67db kbuild: add -fcf-protection=none when using retpoline flags
[ Upstream commit 29be86d7f9 ]

The gcc -fcf-protection=branch option is not compatible with
-mindirect-branch=thunk-extern. The latter is used when
CONFIG_RETPOLINE is selected, and this will fail to build with
a gcc which has -fcf-protection=branch enabled by default. Adding
-fcf-protection=none when building with retpoline enabled
prevents such build failures.

Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-10 11:25:39 +01:00
Masahiro Yamada
b125188db9 kbuild: use -fmacro-prefix-map to make __FILE__ a relative path
[ Upstream commit a73619a845 ]

The __FILE__ macro is used everywhere in the kernel to locate the file
printing the log message, such as WARN_ON(), etc.  If the kernel is
built out of tree, this can be a long absolute path, like this:

  WARNING: CPU: 1 PID: 1 at /path/to/build/directory/arch/arm64/kernel/foo.c:...

This is because Kbuild runs in the objtree instead of the srctree,
then __FILE__ is expanded to a file path prefixed with $(srctree)/.

Commit 9da0763bdd ("kbuild: Use relative path when building in a
subdir of the source tree") improved this to some extent; $(srctree)
becomes ".." if the objtree is a child of the srctree.

For other cases of out-of-tree build, __FILE__ is still the absolute
path.  It also means the kernel image depends on where it was built.

A brand-new option from GCC, -fmacro-prefix-map, solves this problem.
If your compiler supports it, __FILE__ is the relative path from the
srctree regardless of O= option.  This provides more readable log and
more reproducible builds.

Please note __FILE__ is always an absolute path for external modules.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-10 11:25:38 +01:00
Greg Kroah-Hartman
c9fda4f224 Linux 4.14.152 2019-11-06 12:43:42 +01:00
Greg Kroah-Hartman
ddef1e8e3f Linux 4.14.151 2019-10-29 09:17:49 +01:00
Greg Kroah-Hartman
b98aebd298 Linux 4.14.150 2019-10-17 13:44:04 -07:00
Greg Kroah-Hartman
e132c8d7b5 Linux 4.14.149 2019-10-11 18:18:50 +02:00
Greg Kroah-Hartman
42327896f1 Linux 4.14.148 2019-10-07 18:55:23 +02:00
Greg Kroah-Hartman
db1892238c Linux 4.14.147 2019-10-05 12:48:14 +02:00
Rolf Eike Beer
21b50a160d objtool: Query pkg-config for libelf location
commit 056d28d135 upstream.

If it is not in the default location, compilation fails at several points.

Signed-off-by: Rolf Eike Beer <eb@emlix.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/91a25e992566a7968fedc89ec80e7f4c83ad0548.1553622500.git.jpoimboe@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-05 12:47:32 +02:00
Greg Kroah-Hartman
f6e27dbb1a Linux 4.14.146 2019-09-21 07:15:48 +02:00
Greg Kroah-Hartman
b10ab5e2c4 Linux 4.14.145 2019-09-19 09:08:09 +02:00
Greg Kroah-Hartman
968722f537 Linux 4.14.144 2019-09-16 08:20:46 +02:00
Greg Kroah-Hartman
e2cd24b629 Linux 4.14.143 2019-09-10 10:32:22 +01:00
Greg Kroah-Hartman
414510bc00 Linux 4.14.142 2019-09-06 10:21:01 +02:00
Greg Kroah-Hartman
01fd1694b9 Linux 4.14.141 2019-08-29 08:26:46 +02:00
Greg Kroah-Hartman
b526080152 Linux 4.14.140 2019-08-25 10:50:29 +02:00
Greg Kroah-Hartman
45f092f9e9 Linux 4.14.139 2019-08-16 10:13:59 +02:00
Greg Kroah-Hartman
3ffe1e79c1 Linux 4.14.138 2019-08-09 17:53:37 +02:00
Greg Kroah-Hartman
b19ffe6e72 Linux 4.14.137 2019-08-06 19:05:30 +02:00
Masahiro Yamada
3e1332cfb4 kbuild: initialize CLANG_FLAGS correctly in the top Makefile
commit 5241ab4cf4 upstream.

CLANG_FLAGS is initialized by the following line:

  CLANG_FLAGS     := --target=$(notdir $(CROSS_COMPILE:%-=%))

..., which is run only when CROSS_COMPILE is set.

Some build targets (bindeb-pkg etc.) recurse to the top Makefile.

When you build the kernel with Clang but without CROSS_COMPILE,
the same compiler flags such as -no-integrated-as are accumulated
into CLANG_FLAGS.

If you run 'make CC=clang' and then 'make CC=clang bindeb-pkg',
Kbuild will recompile everything needlessly due to the build command
change.

Fix this by correctly initializing CLANG_FLAGS.

Fixes: 238bcbc4e0 ("kbuild: consolidate Clang compiler flags")
Cc: <stable@vger.kernel.org> # v5.0+
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Acked-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-08-06 19:05:25 +02:00
Greg Kroah-Hartman
7d80e1218a Linux 4.14.136 2019-08-04 09:32:04 +02:00
Greg Kroah-Hartman
10d6aa565d Linux 4.14.135 2019-07-31 07:28:59 +02:00
Nathan Chancellor
89567efefe kbuild: Add -Werror=unknown-warning-option to CLANG_FLAGS
[ Upstream commit 589834b3a0 ]

In commit ebcc5928c5 ("arm64: Silence gcc warnings about arch ABI
drift"), the arm64 Makefile added -Wno-psabi to KBUILD_CFLAGS, which is
a GCC only option so clang rightfully complains:

warning: unknown warning option '-Wno-psabi' [-Wunknown-warning-option]

https://clang.llvm.org/docs/DiagnosticsReference.html#wunknown-warning-option

However, by default, this is merely a warning so the build happily goes
on with a slew of these warnings in the process.

Commit c3f0d0bc5b ("kbuild, LLVMLinux: Add -Werror to cc-option to
support clang") worked around this behavior in cc-option by adding
-Werror so that unknown flags cause an error. However, this all happens
silently and when an unknown flag is added to the build unconditionally
like -Wno-psabi, cc-option will always fail because there is always an
unknown flag in the list of flags. This manifested as link time failures
in the arm64 libstub because -fno-stack-protector didn't get added to
KBUILD_CFLAGS.

To avoid these weird cryptic failures in the future, make clang behave
like gcc and immediately error when it encounters an unknown flag by
adding -Werror=unknown-warning-option to CLANG_FLAGS. This can be added
unconditionally for clang because it is supported by at least 3.0.0,
according to godbolt [1] and 4.0.0, according to its documentation [2],
which is far earlier than we typically support.

[1]: https://godbolt.org/z/7F7rm3
[2]: https://releases.llvm.org/4.0.0/tools/clang/docs/DiagnosticsReference.html#wunknown-warning-option

Link: https://github.com/ClangBuiltLinux/linux/issues/511
Link: https://github.com/ClangBuiltLinux/linux/issues/517
Suggested-by: Peter Smith <peter.smith@linaro.org>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31 07:28:52 +02:00
Greg Kroah-Hartman
ff33472c28 Linux 4.14.134 2019-07-21 09:04:43 +02:00
Greg Kroah-Hartman
aea8526edf Linux 4.14.133 2019-07-10 09:54:43 +02:00
Greg Kroah-Hartman
e3c1b27308 Linux 4.14.132 2019-07-03 13:16:04 +02:00
Greg Kroah-Hartman
f4cc0ed9b2 Linux 4.14.131 2019-06-27 08:15:09 +08:00
Greg Kroah-Hartman
bc2bccef19 Linux 4.14.130 2019-06-25 11:36:55 +08:00
Linus Torvalds
8e69458509 gcc-9: silence 'address-of-packed-member' warning
commit 6f303d6053 upstream.

We already did this for clang, but now gcc has that warning too.  Yes,
yes, the address may be unaligned.  And that's kind of the point.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-25 11:36:50 +08:00
Greg Kroah-Hartman
a5758c5311 Linux 4.14.129 2019-06-22 08:16:19 +02:00
Greg Kroah-Hartman
bb263a2a2d Linux 4.14.128 2019-06-19 08:21:00 +02:00
Greg Kroah-Hartman
e861d0673e Linux 4.14.127 2019-06-17 19:52:45 +02:00
Greg Kroah-Hartman
a74d0e937a Linux 4.14.126 2019-06-15 11:55:00 +02:00
Greg Kroah-Hartman
2bf3258a12 Linux 4.14.125 2019-06-11 12:21:51 +02:00
Greg Kroah-Hartman
e6a95d8851 Linux 4.14.124 2019-06-09 09:18:21 +02:00
Greg Kroah-Hartman
8cb1239889 Linux 4.14.123 2019-05-31 06:47:36 -07:00
Greg Kroah-Hartman
44a05cd896 Linux 4.14.122 2019-05-25 18:25:38 +02:00
Greg Kroah-Hartman
bbcb3c09ea Linux 4.14.121 2019-05-21 18:50:21 +02:00
Greg Kroah-Hartman
e6fedb8802 Linux 4.14.120 2019-05-16 19:42:36 +02:00
Greg Kroah-Hartman
2af67d29b6 Linux 4.14.119 2019-05-14 19:18:47 +02:00
Greg Kroah-Hartman
d929572d7d Linux 4.14.118 2019-05-10 17:53:15 +02:00
Greg Kroah-Hartman
b4677bbb65 Linux 4.14.117 2019-05-08 07:20:54 +02:00
Greg Kroah-Hartman
6d1510d86e Linux 4.14.116 2019-05-04 09:15:23 +02:00
Greg Kroah-Hartman
1c046f3731 Linux 4.14.115 2019-05-02 09:40:34 +02:00
Greg Kroah-Hartman
fa5941f45d Linux 4.14.114 2019-04-27 09:35:42 +02:00
Matthias Kaehlcke
56714d4517 Revert "kbuild: use -Oz instead of -Os when using clang"
commit a75bb4eb9e upstream.

The clang option -Oz enables *aggressive* optimization for size,
which doesn't necessarily result in smaller images, but can have
negative impact on performance. Switch back to the less aggressive
-Os.

This reverts commit 6748cb3c29.

Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-04-27 09:35:40 +02:00
Greg Kroah-Hartman
68d7a45eec Linux 4.14.113 2019-04-20 09:15:10 +02:00
Greg Kroah-Hartman
58b454ebf8 Linux 4.14.112 2019-04-17 08:37:55 +02:00
Nick Desaulniers
1efb2caed0 kbuild: clang: choose GCC_TOOLCHAIN_DIR not on LD
commit ad15006cc7 upstream.

This causes an issue when trying to build with `make LD=ld.lld` if
ld.lld and the rest of your cross tools aren't in the same directory
(ex. /usr/local/bin) (as is the case for Android's build system), as the
GCC_TOOLCHAIN_DIR then gets set based on `which $(LD)` which will point
where LLVM tools are, not GCC/binutils tools are located.

Instead, select the GCC_TOOLCHAIN_DIR based on another tool provided by
binutils for which LLVM does not provide a substitute for, such as
elfedit.

Fixes: 785f11aa59 ("kbuild: Add better clang cross build support")
Link: https://github.com/ClangBuiltLinux/linux/issues/341
Suggested-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-04-17 08:37:43 +02:00
Greg Kroah-Hartman
1ec8f1f0bf Linux 4.14.111 2019-04-05 22:31:40 +02:00
Greg Kroah-Hartman
80bf6c64d5 Linux 4.14.110 2019-04-03 06:25:21 +02:00
Greg Kroah-Hartman
1848c32fad Linux 4.14.109 2019-03-27 14:13:56 +09:00
Greg Kroah-Hartman
dee55b062e Linux 4.14.108 2019-03-23 14:35:32 +01:00
Greg Kroah-Hartman
5726a8d0f1 Linux 4.14.107 2019-03-19 13:13:25 +01:00
Greg Kroah-Hartman
d989616452 Linux 4.14.106 2019-03-13 14:03:24 -07:00
Greg Kroah-Hartman
99403097be Linux 4.14.105 2019-03-05 17:58:03 +01:00
Greg Kroah-Hartman
30921fc1e5 Linux 4.14.104 2019-02-27 10:08:09 +01:00
Greg Kroah-Hartman
c793fa334c Linux 4.14.103 2019-02-23 09:06:44 +01:00
Greg Kroah-Hartman
5461ace2e2 Linux 4.14.102 2019-02-20 10:20:56 +01:00
Greg Kroah-Hartman
d6bf9dcebd Linux 4.14.101 2019-02-15 09:08:56 +01:00
Greg Kroah-Hartman
557ac4e207 Linux 4.14.100 2019-02-15 08:09:14 +01:00
Greg Kroah-Hartman
383e9b61f8 Linux 4.14.99 2019-02-12 19:46:14 +01:00
Greg Kroah-Hartman
0d7866d54a Linux 4.14.98 2019-02-06 17:31:37 +01:00
Greg Kroah-Hartman
e1e364bf09 Linux 4.14.97 2019-01-31 08:13:48 +01:00
Greg Kroah-Hartman
e6608e1f2f Linux 4.14.96 2019-01-26 09:37:07 +01:00
Greg Kroah-Hartman
3b68e5cf57 Linux 4.14.95 2019-01-23 08:09:52 +01:00
Greg Kroah-Hartman
8979da2558 Linux 4.14.94 2019-01-16 22:07:13 +01:00
Greg Kroah-Hartman
9c07fc2593 Linux 4.14.93 2019-01-13 10:01:07 +01:00
Joel Stanley
72d217d5df Makefile: Export clang toolchain variables
commit 3bd9805090 upstream.

The powerpc makefile will use these in it's boot wrapper.

Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-13 10:01:04 +01:00
Masahiro Yamada
ff858d8220 kbuild: consolidate Clang compiler flags
commit 238bcbc4e0 upstream.

Collect basic Clang options such as --target, --prefix, --gcc-toolchain,
-no-integrated-as into a single variable CLANG_FLAGS so that it can be
easily reused in other parts of Makefile.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Acked-by: Greg Hackmann <ghackmann@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-13 10:01:04 +01:00
Masahiro Yamada
23d9f5e4a3 kbuild: add -no-integrated-as Clang option unconditionally
commit dbe27a002e upstream.

We are still a way off the Clang's integrated assembler support for
the kernel. Hence, -no-integrated-as is mandatory to build the kernel
with Clang. If you had an ancient version of Clang that does not
recognize this option, you would not be able to compile the kernel
anyway.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-13 10:01:04 +01:00
Masahiro Yamada
b08f331e84 kbuild: fix false positive warning/error about missing libelf
[ Upstream commit ef7cfd00b2 ]

For the same reason as commit 25896d073d ("x86/build: Fix compiler
support check for CONFIG_RETPOLINE"), you cannot put this $(error ...)
into the parse stage of the top Makefile.

Perhaps I'd propose a more sophisticated solution later, but this is
the best I can do for now.

Link: https://lkml.org/lkml/2017/12/25/211
Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Reported-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reported-by: Qian Cai <cai@lca.pw>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Qian Cai <cai@lca.pw>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-01-13 10:01:01 +01:00
Greg Kroah-Hartman
24737fa6bc Linux 4.14.92 2019-01-09 17:14:53 +01:00
Greg Kroah-Hartman
d2dd9f1593 Linux 4.14.91 2018-12-29 13:39:11 +01:00
Greg Kroah-Hartman
592f5569e1 Linux 4.14.90 2018-12-21 14:13:19 +01:00
Greg Kroah-Hartman
3beeb26156 Linux 4.14.89 2018-12-17 09:28:56 +01:00
Greg Kroah-Hartman
1bb538a39c Linux 4.14.88 2018-12-13 09:18:54 +01:00
Greg Kroah-Hartman
ca48e5e30b Linux 4.14.87 2018-12-08 13:03:41 +01:00
Stephen Rothwell
9f8d10971a disable stringop truncation warnings for now
commit 217c3e0196 upstream.

They are too noisy

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-08 13:03:34 +01:00
Greg Kroah-Hartman
7152401aee Linux 4.14.86 2018-12-05 19:41:27 +01:00
Greg Kroah-Hartman
5ff1ad556a Linux 4.14.85 2018-12-01 09:43:00 +01:00
Stefan Agner
9d844b0e66 kbuild: allow to use GCC toolchain not in Clang search path
commit ef8c4ed9db upstream.

When using a GCC cross toolchain which is not in a compiled in
Clang search path, Clang reverts to the system assembler and
linker. This leads to assembler or linker errors, depending on
which tool is first used for a given architecture.

It seems that Clang is not searching $PATH for a matching
assembler or linker.

Make sure that Clang picks up the correct assembler or linker by
passing the cross compilers bin directory as search path.

This allows to use Clang provided by distributions with GCC
toolchains not in /usr/bin.

Link: https://github.com/ClangBuiltLinux/linux/issues/78
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-and-tested-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
[nc: Adjust context]
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-01 09:42:57 +01:00
Greg Kroah-Hartman
4201a586f1 Linux 4.14.84 2018-11-27 16:10:52 +01:00
Greg Kroah-Hartman
1d4bd2e4e1 Linux 4.14.83 2018-11-23 08:19:27 +01:00
Greg Kroah-Hartman
a21f3c11b4 Linux 4.14.82 2018-11-21 09:24:18 +01:00
Greg Kroah-Hartman
2e390c4878 Linux 4.14.81 2018-11-13 11:15:18 -08:00
Greg Kroah-Hartman
0b047cbc44 Linux 4.14.80 2018-11-10 07:48:36 -08:00
Greg Kroah-Hartman
50961e4888 Linux 4.14.79 2018-11-04 14:52:51 +01:00
Stefan Agner
6cfb67394a kbuild: set no-integrated-as before incl. arch Makefile
[ Upstream commit 0f0e8de334 ]

In order to make sure compiler flag detection for ARM works
correctly the no-integrated-as flags need to be set before
including the arch specific Makefile.

Fixes: cfe17c9bbe ("kbuild: move cc-option and cc-disable-warning after incl. arch Makefile")
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2018-11-04 14:52:43 +01:00
Greg Kroah-Hartman
e7405910ca Linux 4.14.78 2018-10-20 09:48:54 +02:00
Greg Kroah-Hartman
8263087bf6 Linux 4.14.77 2018-10-18 09:16:28 +02:00
Greg Kroah-Hartman
0b46ce3e34 Linux 4.14.76 2018-10-13 09:27:30 +02:00
Greg Kroah-Hartman
8e6a9240b1 Linux 4.14.75 2018-10-10 08:54:28 +02:00
Greg Kroah-Hartman
e6abbe80c8 Linux 4.14.74 2018-10-03 17:01:00 -07:00
Greg Kroah-Hartman
3b65f403d7 Linux 4.14.73 2018-09-29 03:06:07 -07:00
Greg Kroah-Hartman
2cc4d36536 Linux 4.14.72 2018-09-26 08:38:16 +02:00
Greg Kroah-Hartman
1244bbb3e9 Linux 4.14.71 2018-09-19 22:43:49 +02:00
Greg Kroah-Hartman
5dfe87ac34 Linux 4.14.70 2018-09-15 09:45:37 +02:00
Greg Kroah-Hartman
7fe7a0f4c5 Linux 4.14.69 2018-09-09 19:56:02 +02:00
Greg Kroah-Hartman
ee13f7edca Linux 4.14.68 2018-09-05 09:26:42 +02:00
Andy Lutomirski
4587db4c2a x86/vdso: Fix vDSO build if a retpoline is emitted
commit 2e549b2ee0 upstream.

Currently, if the vDSO ends up containing an indirect branch or
call, GCC will emit the "external thunk" style of retpoline, and it
will fail to link.

Fix it by building the vDSO with inline retpoline thunks.

I haven't seen any reports of this triggering on an unpatched
kernel.

Fixes: commit 76b043848f ("x86/retpoline: Add initial retpoline support")
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Matt Rickard <matt@softrans.com.au>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Jason Vas Dias <jason.vas.dias@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/c76538cd3afbe19c6246c2d1715bc6a60bd63985.1534448381.git.luto@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-05 09:26:37 +02:00
Greg Kroah-Hartman
f4c88459f7 Linux 4.14.67 2018-08-24 13:09:23 +02:00
Masahiro Yamada
edf81993dc kbuild: suppress warnings from 'getconf LFS_*'
[ Upstream commit 6d79a7b424 ]

Suppress warnings for systems that do not recognize LFS_*.

 getconf: no such configuration parameter `LFS_CFLAGS'
 getconf: no such configuration parameter `LFS_LDFLAGS'
 getconf: no such configuration parameter `LFS_LIBS'

Fixes: d7f14c66c2 ("kbuild: Enable Large File Support for hostprogs")
Reported-by: Chen Feng <puck.chen@hisilicon.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-24 13:09:17 +02:00
Greg Kroah-Hartman
c5f7d3c4da Linux 4.14.66 2018-08-22 07:46:11 +02:00
Greg Kroah-Hartman
4cea13b661 Linux 4.14.65 2018-08-18 10:48:00 +02:00
Greg Kroah-Hartman
7251bd56d9 Linux 4.14.64 2018-08-17 21:01:12 +02:00
Greg Kroah-Hartman
9d5cd9f2a4 Linux 4.14.63 2018-08-15 18:13:02 +02:00
Greg Kroah-Hartman
1aa1166efa Linux 4.14.62 2018-08-09 12:16:40 +02:00
Greg Kroah-Hartman
2ae6c0413b Linux 4.14.61 2018-08-06 16:20:52 +02:00
Greg Kroah-Hartman
deaacd62c2 Linux 4.14.60 2018-08-03 07:50:45 +02:00
Greg Kroah-Hartman
53208e12fa Linux 4.14.59 2018-07-28 07:55:45 +02:00
Arnd Bergmann
e94f784fdd turn off -Wattribute-alias
Starting with gcc-8.1, we get a warning about all system call definitions,
which use an alias between functions with incompatible prototypes, e.g.:

In file included from ../mm/process_vm_access.c:19:
../include/linux/syscalls.h:211:18: warning: 'sys_process_vm_readv' alias between functions of incompatible types 'long int(pid_t,  const struct iovec *, long unsigned int,  const struct iovec *, long unsigned int,  long unsigned int)' {aka 'long int(int,  const struct iovec *, long unsigned int,  const struct iovec *, long unsigned int,  long unsigned int)'} and 'long int(long int,  long int,  long int,  long int,  long int,  long int)' [-Wattribute-alias]
  asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
                  ^~~
../include/linux/syscalls.h:207:2: note: in expansion of macro '__SYSCALL_DEFINEx'
  __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
  ^~~~~~~~~~~~~~~~~
../include/linux/syscalls.h:201:36: note: in expansion of macro 'SYSCALL_DEFINEx'
 #define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
                                    ^~~~~~~~~~~~~~~
../mm/process_vm_access.c:300:1: note: in expansion of macro 'SYSCALL_DEFINE6'
 SYSCALL_DEFINE6(process_vm_readv, pid_t, pid, const struct iovec __user *, lvec,
 ^~~~~~~~~~~~~~~
../include/linux/syscalls.h:215:18: note: aliased declaration here
  asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
                  ^~~
../include/linux/syscalls.h:207:2: note: in expansion of macro '__SYSCALL_DEFINEx'
  __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
  ^~~~~~~~~~~~~~~~~
../include/linux/syscalls.h:201:36: note: in expansion of macro 'SYSCALL_DEFINEx'
 #define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
                                    ^~~~~~~~~~~~~~~
../mm/process_vm_access.c:300:1: note: in expansion of macro 'SYSCALL_DEFINE6'
 SYSCALL_DEFINE6(process_vm_readv, pid_t, pid, const struct iovec __user *, lvec,

This is really noisy and does not indicate a real problem. In the latest
mainline kernel, this was addressed by commit bee2003177 ("disable
-Wattribute-alias warning for SYSCALL_DEFINEx()"), which seems too invasive
to backport.

This takes a much simpler approach and just disables the warning across the
kernel.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-07-28 07:55:45 +02:00
Greg Kroah-Hartman
f952480a8f Linux 4.14.58 2018-07-25 11:25:11 +02:00
Greg Kroah-Hartman
ecc160ece6 Linux 4.14.57 2018-07-22 14:28:52 +02:00
Greg Kroah-Hartman
cff26c95b2 Linux 4.14.56 2018-07-17 11:39:34 +02:00
Greg Kroah-Hartman
1e92e81355 Linux 4.14.55 2018-07-11 16:29:25 +02:00
Greg Kroah-Hartman
5893f4c3fb Linux 4.14.54 2018-07-08 15:30:53 +02:00
Greg Kroah-Hartman
fa745a1bd9 Linux 4.14.53 2018-07-03 11:25:05 +02:00
Greg Kroah-Hartman
a26899e0ba Linux 4.14.52 2018-06-26 08:06:33 +08:00
Greg Kroah-Hartman
33445c07cd Linux 4.14.51 2018-06-21 04:03:02 +09:00
Greg Kroah-Hartman
cda6fd4d93 Linux 4.14.50 2018-06-16 09:45:18 +02:00
Greg Kroah-Hartman
70d7bbd9b5 Linux 4.14.49 2018-06-11 22:49:22 +02:00
Greg Kroah-Hartman
2c6025ebc7 Linux 4.14.48 2018-06-05 11:42:00 +02:00
Sodagudi Prasad
96b086a7bf kbuild: clang: disable unused variable warnings only when constant
commit 0a5f417674 upstream.

Currently, GCC disables -Wunused-const-variable, but not
-Wunused-variable, so warns unused variables if they are
non-constant.

While, Clang does not warn unused variables at all regardless of
the const qualifier because -Wno-unused-const-variable is implied
by the stronger option -Wno-unused-variable.

Disable -Wunused-const-variable instead of -Wunused-variable so that
GCC and Clang work in the same way.

Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-06-05 11:41:57 +02:00
Nick Desaulniers
151b144bc6 kbuild: clang: remove crufty HOSTCFLAGS
commit df16aaac26 upstream.

When compiling with `make CC=clang HOSTCC=clang`, I was seeing warnings
that clang did not recognize -fno-delete-null-pointer-checks for HOSTCC
targets.  These were added in commit 61163efae0 ("kbuild: LLVMLinux:
Add Kbuild support for building kernel with Clang").

Clang does not support -fno-delete-null-pointer-checks, so adding it to
HOSTCFLAGS if HOSTCC is clang does not make sense.

It's not clear why the other warnings were disabled, and just for
HOSTCFLAGS, but I can remove them, add -Werror to HOSTCFLAGS and compile
with clang just fine.

Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Nick Desaulniers <nick.desaulniers@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-06-05 11:41:57 +02:00
Greg Kroah-Hartman
57a3ca7835 Linux 4.14.47 2018-05-30 22:32:31 +02:00
Greg Kroah-Hartman
bf4367d790 Linux 4.14.46 2018-05-30 12:19:59 +02:00
Greg Kroah-Hartman
2c2b15bb0e Linux 4.14.45 2018-05-30 07:52:42 +02:00
Greg Kroah-Hartman
102b97d624 Linux 4.14.44 2018-05-25 16:18:02 +02:00
Greg Kroah-Hartman
1dff08485b Linux 4.14.43 2018-05-22 18:54:07 +02:00
Greg Kroah-Hartman
d88700f794 Linux 4.14.42 2018-05-19 10:20:27 +02:00
Greg Kroah-Hartman
3f07ecbec1 Linux 4.14.41 2018-05-16 10:10:32 +02:00
Greg Kroah-Hartman
fc72a41711 Linux 4.14.40 2018-05-09 09:51:56 +02:00
Greg Kroah-Hartman
7d6240f0fb Linux 4.14.39 2018-05-01 12:58:27 -07:00
Greg Kroah-Hartman
a87463f742 Linux 4.14.38 2018-04-29 11:33:18 +02:00
Greg Kroah-Hartman
753be7e83b Linux 4.14.37 2018-04-26 11:02:22 +02:00
Greg Kroah-Hartman
d6949f4809 Linux 4.14.36 2018-04-24 09:36:40 +02:00
Greg Kroah-Hartman
672f07d827 Linux 4.14.35 2018-04-19 08:56:21 +02:00
Greg Kroah-Hartman
ffebeb0d7c Linux 4.14.34 2018-04-12 12:32:27 +02:00
Greg Kroah-Hartman
b867b7a7e5 Linux 4.14.33 2018-04-08 14:26:34 +02:00
Greg Kroah-Hartman
9a2e216d9e Linux 4.14.32 2018-03-31 18:10:43 +02:00
Greg Kroah-Hartman
9861e6647c Linux 4.14.31 2018-03-28 18:24:51 +02:00
Daniel Borkmann
3e1130970e kbuild: disable clang's default use of -fmerge-all-constants
commit 87e0d4f0f3 upstream.

Prasad reported that he has seen crashes in BPF subsystem with netd
on Android with arm64 in the form of (note, the taint is unrelated):

  [ 4134.721483] Unable to handle kernel paging request at virtual address 800000001
  [ 4134.820925] Mem abort info:
  [ 4134.901283]   Exception class = DABT (current EL), IL = 32 bits
  [ 4135.016736]   SET = 0, FnV = 0
  [ 4135.119820]   EA = 0, S1PTW = 0
  [ 4135.201431] Data abort info:
  [ 4135.301388]   ISV = 0, ISS = 0x00000021
  [ 4135.359599]   CM = 0, WnR = 0
  [ 4135.470873] user pgtable: 4k pages, 39-bit VAs, pgd = ffffffe39b946000
  [ 4135.499757] [0000000800000001] *pgd=0000000000000000, *pud=0000000000000000
  [ 4135.660725] Internal error: Oops: 96000021 [#1] PREEMPT SMP
  [ 4135.674610] Modules linked in:
  [ 4135.682883] CPU: 5 PID: 1260 Comm: netd Tainted: G S      W       4.14.19+ #1
  [ 4135.716188] task: ffffffe39f4aa380 task.stack: ffffff801d4e0000
  [ 4135.731599] PC is at bpf_prog_add+0x20/0x68
  [ 4135.741746] LR is at bpf_prog_inc+0x20/0x2c
  [ 4135.751788] pc : [<ffffff94ab7ad584>] lr : [<ffffff94ab7ad638>] pstate: 60400145
  [ 4135.769062] sp : ffffff801d4e3ce0
  [...]
  [ 4136.258315] Process netd (pid: 1260, stack limit = 0xffffff801d4e0000)
  [ 4136.273746] Call trace:
  [...]
  [ 4136.442494] 3ca0: ffffff94ab7ad584 0000000060400145 ffffffe3a01bf8f8 0000000000000006
  [ 4136.460936] 3cc0: 0000008000000000 ffffff94ab844204 ffffff801d4e3cf0 ffffff94ab7ad584
  [ 4136.479241] [<ffffff94ab7ad584>] bpf_prog_add+0x20/0x68
  [ 4136.491767] [<ffffff94ab7ad638>] bpf_prog_inc+0x20/0x2c
  [ 4136.504536] [<ffffff94ab7b5d08>] bpf_obj_get_user+0x204/0x22c
  [ 4136.518746] [<ffffff94ab7ade68>] SyS_bpf+0x5a8/0x1a88

Android's netd was basically pinning the uid cookie BPF map in BPF
fs (/sys/fs/bpf/traffic_cookie_uid_map) and later on retrieving it
again resulting in above panic. Issue is that the map was wrongly
identified as a prog! Above kernel was compiled with clang 4.0,
and it turns out that clang decided to merge the bpf_prog_iops and
bpf_map_iops into a single memory location, such that the two i_ops
could then not be distinguished anymore.

Reason for this miscompilation is that clang has the more aggressive
-fmerge-all-constants enabled by default. In fact, clang source code
has a comment about it in lib/AST/ExprConstant.cpp on why it is okay
to do so:

  Pointers with different bases cannot represent the same object.
  (Note that clang defaults to -fmerge-all-constants, which can
  lead to inconsistent results for comparisons involving the address
  of a constant; this generally doesn't matter in practice.)

The issue never appeared with gcc however, since gcc does not enable
-fmerge-all-constants by default and even *explicitly* states in
it's option description that using this flag results in non-conforming
behavior, quote from man gcc:

  Languages like C or C++ require each variable, including multiple
  instances of the same variable in recursive calls, to have distinct
  locations, so using this option results in non-conforming behavior.

There are also various clang bug reports open on that matter [1],
where clang developers acknowledge the non-conforming behavior,
and refer to disabling it with -fno-merge-all-constants. But even
if this gets fixed in clang today, there are already users out there
that triggered this. Thus, fix this issue by explicitly adding
-fno-merge-all-constants to the kernel's Makefile to generically
disable this optimization, since potentially other places in the
kernel could subtly break as well.

Note, there is also a flag called -fmerge-constants (not supported
by clang), which is more conservative and only applies to strings
and it's enabled in gcc's -O/-O2/-O3/-Os optimization levels. In
gcc's code, the two flags -fmerge-{all-,}constants share the same
variable internally, so when disabling it via -fno-merge-all-constants,
then we really don't merge any const data (e.g. strings), and text
size increases with gcc (14,927,214 -> 14,942,646 for vmlinux.o).

  $ gcc -fverbose-asm -O2 foo.c -S -o foo.S
    -> foo.S lists -fmerge-constants under options enabled
  $ gcc -fverbose-asm -O2 -fno-merge-all-constants foo.c -S -o foo.S
    -> foo.S doesn't list -fmerge-constants under options enabled
  $ gcc -fverbose-asm -O2 -fno-merge-all-constants -fmerge-constants foo.c -S -o foo.S
    -> foo.S lists -fmerge-constants under options enabled

Thus, as a workaround we need to set both -fno-merge-all-constants
*and* -fmerge-constants in the Makefile in order for text size to
stay as is.

  [1] https://bugs.llvm.org/show_bug.cgi?id=18538

Reported-by: Prasad Sodagudi <psodagud@codeaurora.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Chenbo Feng <fengc@google.com>
Cc: Richard Smith <richard-llvm@metafoo.co.uk>
Cc: Chandler Carruth <chandlerc@gmail.com>
Cc: linux-kernel@vger.kernel.org
Tested-by: Prasad Sodagudi <psodagud@codeaurora.org>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-03-28 18:24:50 +02:00
Greg Kroah-Hartman
de8cdc5572 Linux 4.14.30 2018-03-24 11:01:30 +01:00
Greg Kroah-Hartman
8096079403 Linux 4.14.29 2018-03-21 12:06:45 +01:00
Greg Kroah-Hartman
42b96e19dd Linux 4.14.28 2018-03-19 08:42:57 +01:00
Greg Kroah-Hartman
9b1fb9cc92 Linux 4.14.27 2018-03-15 10:54:38 +01:00
Peter Zijlstra
c3b9f72606 objtool, retpolines: Integrate objtool with retpoline support more closely
commit d5028ba8ee upstream.

Disable retpoline validation in objtool if your compiler sucks, and otherwise
select the validation stuff for CONFIG_RETPOLINE=y (most builds would already
have it set due to ORC).

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-03-15 10:54:38 +01:00
Masahiro Yamada
3945bbe152 kbuild: move cc-option and cc-disable-warning after incl. arch Makefile
commit cfe17c9bbe upstream.

Geert reported commit ae6b289a37 ("kbuild: Set KBUILD_CFLAGS before
incl. arch Makefile") broke cross-compilation using a cross-compiler
that supports less compiler options than the host compiler.

For example,

  cc1: error: unrecognized command line option "-Wno-unused-but-set-variable"

This problem happens on architectures that setup CROSS_COMPILE in their
arch/*/Makefile.

Move the cc-option and cc-disable-warning back to the original position,
but keep the Clang target options untouched.

Fixes: ae6b289a37 ("kbuild: Set KBUILD_CFLAGS before incl. arch Makefile")
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-03-15 10:54:37 +01:00
Chris Fries
6288eb92ca kbuild: Set KBUILD_CFLAGS before incl. arch Makefile
commit ae6b289a37 upstream.

Set the clang KBUILD_CFLAGS up before including arch/ Makefiles,
so that ld-options (etc.) can work correctly.

This fixes errors with clang such as ld-options trying to CC
against your host architecture, but LD trying to link against
your target architecture.

Signed-off-by: Chris Fries <cfries@google.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-03-15 10:54:37 +01:00
Masahiro Yamada
cfe39acafb kbuild: re-order the code to not parse unnecessary variables
commit 2c1f4f1251 upstream.

The top Makefile is divided into some sections such as mixed targets,
config targets, build targets, etc.

When we build mixed targets, Kbuild just invokes submake to process
them one by one.  In this case, compiler-related variables like CC,
KBUILD_CFLAGS, etc. are unneeded.

Check what kind of targets we are building first, and parse variables
for building only when necessary.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-03-15 10:54:37 +01:00
Masahiro Yamada
31c4bc6e01 kbuild: move "_all" target out of $(KBUILD_SRC) conditional
commit ba634eceb5 upstream.

The first "_all" occurrence around line 120 is only visible when
KBUILD_SRC is unset.

If O=... is specified, the working directory is relocated, then the
only second occurrence around line 193 is visible, that is not set
to PHONY.

Move the first one to an always visible place.  This clarifies "_all"
is our default target and it is always set to PHONY.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-03-15 10:54:21 +01:00
Greg Kroah-Hartman
96427a5164 Linux 4.14.26 2018-03-11 16:23:23 +01:00