OSDN Git Service
Masahiro Yamada [Mon, 1 Jun 2020 05:57:19 +0000 (14:57 +0900)]
modpost: avoid false-positive file open error
One problem of grab_file() is that it cannot distinguish the following
two cases:
- It cannot read the file (the file does not exist, or read permission
is not set)
- It can read the file, but the file size is zero
This is because grab_file() calls mmap(), which requires the mapped
length is greater than 0. Hence, grab_file() fails for both cases.
If an empty header file were included for checksum calculation, the
following warning would be printed:
WARNING: modpost: could not open ...: Invalid argument
An empty file is a valid source file, so it should not fail.
Use read_text_file() instead. It can read a zero-length file.
Then, parse_file() will succeed with doing nothing.
Going forward, the first case (it cannot read the file) is a fatal
error. If the source file from which an object was compiled is missing,
something went wrong.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Mon, 1 Jun 2020 05:57:18 +0000 (14:57 +0900)]
modpost: fix potential mmap'ed file overrun in get_src_version()
I do not know how reliably this function works, but it looks dangerous
to me.
strchr(sources, '\n');
... continues searching until it finds '\n' or it reaches the '\0'
terminator. In other words, 'sources' should be a null-terminated
string.
However, grab_file() just mmaps a file, so 'sources' is not terminated
with null byte. If the file does not contain '\n' at all, strchr() will
go beyond the mmap'ed memory.
Use read_text_file(), which loads the file content into a malloc'ed
buffer, appending null byte.
Here we are interested only in the first line of *.mod files. Use
get_line() helper to get the first line.
This also makes missing *.mod file a fatal error.
Commit
4be40e22233c ("kbuild: do not emit src version warning for
non-modules") ignored missing *.mod files.
I do not fully understand what that commit addressed, but commit
91341d4b2c19 ("kbuild: introduce new option to enhance section mismatch
analysis") introduced partial section checks by using modpost. built-in.o
was parsed by modpost. Even modules had a problem because *.mod files
were created after the modpost check.
Commit
b7dca6dd1e59 ("kbuild: create *.mod with full directory path and
remove MODVERDIR") stopped doing that. Now that modpost is only invoked
after the directory descend, *.mod files should always exist at the
modpost stage.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Mon, 1 Jun 2020 05:57:17 +0000 (14:57 +0900)]
modpost: add read_text_file() and get_line() helpers
modpost uses grab_file() to open a file, but it is not suitable for
a text file because the mmap'ed file is not terminated by null byte.
Actually, I see some issues for the use of grab_file().
The new helper, read_text_file() loads the whole file content into a
malloc'ed buffer, and appends a null byte. Then, get_line() reads
each line.
To handle text files, I intend to replace as follows:
grab_file() -> read_text_file()
get_new_line() -> get_line()
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Mon, 1 Jun 2020 05:57:16 +0000 (14:57 +0900)]
modpost: do not call get_modinfo() for vmlinux(.o)
The three calls of get_modinfo() ("license", "import_ns", "version")
always return NULL for vmlinux(.o) because the built-in module info is
prefixed with __MODULE_INFO_PREFIX.
It is harmless to call get_modinfo(), but there is no point to search
for what apparently does not exist.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Mon, 1 Jun 2020 05:57:15 +0000 (14:57 +0900)]
modpost: drop RCS/CVS $Revision handling in MODULE_VERSION()
As far as I understood, this code gets rid of '$Revision$' or '$Revision:'
of CVS, RCS or whatever in MODULE_VERSION() tags.
Remove the primeval code.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Mon, 1 Jun 2020 05:57:14 +0000 (14:57 +0900)]
modpost: show warning if any of symbol dump files is missing
If modpost fails to load a symbol dump file, it cannot check unresolved
symbols, hence module dependency will not be added. Nor CRCs can be added.
Currently, external module builds check only $(objtree)/Module.symvers,
but it should check files specified by KBUILD_EXTRA_SYMBOLS as well.
Move the warning message from the top Makefile to scripts/Makefile.modpost
and print the warning if any dump file is missing.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Mon, 1 Jun 2020 05:57:13 +0000 (14:57 +0900)]
modpost: show warning if vmlinux is not found when processing modules
check_exports() does not print warnings about unresolved symbols if
vmlinux is missing because there would be too many.
This situation happens when you do 'make modules' from the clean
tree, or compile external modules against a kernel tree that has
not been completely built.
It is dangerous to not check unresolved symbols because you might be
building useless modules. At least it should be warned.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Mon, 1 Jun 2020 05:57:12 +0000 (14:57 +0900)]
modpost: invoke modpost only when input files are updated
Currently, the second pass of modpost is always invoked when you run
'make' or 'make modules' even if none of modules is changed.
Use if_changed to invoke it only when it is necessary.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Mon, 1 Jun 2020 05:57:11 +0000 (14:57 +0900)]
modpost: generate vmlinux.symvers and reuse it for the second modpost
The full build runs modpost twice, first for vmlinux.o and second for
modules.
The first pass dumps all the vmlinux symbols into Module.symvers, but
the second pass parses vmlinux again instead of reusing the dump file,
presumably because it needs to avoid accumulating stale symbols.
Loading symbol info from a dump file is faster than parsing an ELF object.
Besides, modpost deals with various issues to parse vmlinux in the second
pass.
A solution is to make the first pass dumps symbols into a separate file,
vmlinux.symvers. The second pass reads it, and parses module .o files.
The merged symbol information is dumped into Module.symvers in the same
way as before.
This makes further modpost cleanups possible.
Also, it fixes the problem of 'make vmlinux', which previously overwrote
Module.symvers, throwing away module symbols.
I slightly touched scripts/link-vmlinux.sh so that vmlinux is re-linked
when you cross this commit. Otherwise, vmlinux.symvers would not be
generated.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Mon, 1 Jun 2020 05:57:10 +0000 (14:57 +0900)]
modpost: refactor -i option calculation
Prepare to use -i for in-tree modpost as well.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Mon, 1 Jun 2020 05:57:09 +0000 (14:57 +0900)]
modpost: print symbol dump file as the build target in short log
The symbol dump *.symvers is the output of modpost. Print it in
the short log.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Mon, 1 Jun 2020 05:57:08 +0000 (14:57 +0900)]
modpost: re-add -e to set external_module flag
Previously, the -i option had two functions; load a symbol dump file,
and set the external_module flag.
I want to assign a dedicate option for each of them.
Going forward, the -i is used to load a symbol dump file, and the -e
to set the external_module flag.
With this, we will be able to use -i for loading in-kernel symbols.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Mon, 1 Jun 2020 05:57:07 +0000 (14:57 +0900)]
modpost: rename ext_sym_list to dump_list
The -i option is used to include Modules.symver as well as files from
$(KBUILD_EXTRA_SYMBOLS).
Make the struct and variable names more generic.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Mon, 1 Jun 2020 05:57:06 +0000 (14:57 +0900)]
modpost: allow to pass -i option multiple times to remove -e option
Now that there is no difference between -i and -e, they can be unified.
Make modpost accept the -i option multiple times, then remove -e.
I will reuse -e for a different purpose.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Mon, 1 Jun 2020 05:57:05 +0000 (14:57 +0900)]
modpost: track if the symbol origin is a dump file or ELF object
The meaning of sym->kernel is obscure; it is set for in-kernel symbols
loaded from Modules.symvers. This happens only when we are building
external modules, and it is used to determine whether to dump symbols
to $(KBUILD_EXTMOD)/Modules.symvers
It is clearer to remember whether the symbol or module came from a dump
file or ELF object.
This changes the KBUILD_EXTRA_SYMBOLS behavior. Previously, symbols
loaded from KBUILD_EXTRA_SYMBOLS are accumulated into the current
$(KBUILD_EXTMOD)/Modules.symvers
Going forward, they will be only used to check symbol references, but
not dumped into the current $(KBUILD_EXTMOD)/Modules.symvers. I believe
this makes more sense.
sym->vmlinux will have no user. Remove it too.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Mon, 1 Jun 2020 05:57:04 +0000 (14:57 +0900)]
modpost: load KBUILD_EXTRA_SYMBOLS files in order
Currently, modpost reads extra symbol dump files in the reverse order.
If '-e foo -e bar' is given, modpost reads bar, foo, in this order.
This is probably not a big deal, but there is no good reason to reverse
the order. Read files in the given order.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Mon, 1 Jun 2020 05:57:03 +0000 (14:57 +0900)]
modpost: pass -N option only for modules modpost
The built-in only code is not required to have MODULE_IMPORT_NS() to
use symbols. So, the namespace is not checked for vmlinux(.o).
Do not pass the meaningless -N option to the first pass of modpost.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Mon, 1 Jun 2020 05:57:02 +0000 (14:57 +0900)]
modpost: move -T option close to the modpost command
The '-T -' option reads the file list from stdin.
It is clearer to put it close to the piped command.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Mon, 1 Jun 2020 05:57:01 +0000 (14:57 +0900)]
modpost: fix -i (--ignore-errors) MAKEFLAGS detection
$(filter -i,$(MAKEFLAGS)) works only in limited use-cases.
The representation of $(MAKEFLAGS) depends on various factors:
- GNU Make version (version 3.8x or version 4.x)
- The presence of other flags like -j
In my experiments, $(MAKEFLAGS) is expanded as follows:
* GNU Make 3.8x:
* without -j option:
--no-print-directory -Rri
* with -j option:
--no-print-directory -Rr --jobserver-fds=3,4 -j -i
* GNU Make 4.x:
* without -j option:
irR --no-print-directory
* with -j option:
irR -j --jobserver-fds=3,4 --no-print-directory
For GNU Make 4.x, the flags are grouped as 'irR', which does not work.
For the single thread build with GNU Make 3.8x, the flags are grouped
as '-Rri', which does not work either.
To make it work for all cases, do likewise as commit
6f0fa58e4596
("kbuild: simplify silent build (-s) detection").
BTW, since commit
ff9b45c55b26 ("kbuild: modpost: read modules.order
instead of $(MODVERDIR)/*.mod"), you also need to pass -k option to
build final *.ko files. 'make -i -k' ignores compile errors in modules,
and build as many remaining *.ko as possible.
Please note this feature is kind of dangerous if other modules depend
on the broken module because the generated modules will lack the correct
module dependency or CRC. Honestly, I am not a big fan of it, but I am
keeping this feature.
Fixes:
eed380f3f593 ("modpost: Optionally ignore secondary errors seen if a single module build fails")
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Mon, 1 Jun 2020 05:57:00 +0000 (14:57 +0900)]
kbuild: update modules.order only when contained modules are updated
Make modules.order depend on $(obj-m), and use if_changed to build it.
This will avoid unneeded update of modules.order, which will be useful
to optimize the modpost stage.
Currently, the second pass of modpost is always invoked. By checking the
timestamp of modules.order, we can avoid the unneeded modpost.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Mon, 1 Jun 2020 05:56:59 +0000 (14:56 +0900)]
kbuild: refactor KBUILD_VMLINUX_{OBJS,LIBS} calculation
Do not overwrite core-y or drivers-y. Remove libs-y1 and libs-y2.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Mon, 1 Jun 2020 05:56:58 +0000 (14:56 +0900)]
kbuild: merge net-y and virt-y into drivers-y
This will slightly change the link order; drivers-y from arch Makefile
will be linked after virt/built-in.a, but I guess this is not a big
deal.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Mon, 1 Jun 2020 05:56:57 +0000 (14:56 +0900)]
kbuild: merge init-y into core-y
No arch Makefile specifies init-y.
Merge init-y into core-y. This does not change the link order.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Mon, 1 Jun 2020 05:56:56 +0000 (14:56 +0900)]
kbuild: refactor tagets caluculation for KBUILD_{BUILTIN,KBUILD_MODULES}
Remove lib-target, builtin-target, modorder-target, and modtargets.
Instead, add targets-for-builtin and targets-for-modules.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Mon, 1 Jun 2020 05:56:55 +0000 (14:56 +0900)]
kbuild: refactor subdir-ym calculation
Remove the unneeded variables, __subdir-y and __subdir-m.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Sun, 31 May 2020 10:11:39 +0000 (19:11 +0900)]
kbuild: merge two 'ifdef CONFIG_TRIM_UNUSED_KSYMS' blocks
This hunk has two 'ifdef CONFIG_TRIM_UNUSED_KSYMS ... endif' blocks
with no other code interleaved. Merge them.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Sun, 31 May 2020 08:47:06 +0000 (17:47 +0900)]
kbuild: force to build vmlinux if CONFIG_MODVERSION=y
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>
Nick Desaulniers [Tue, 26 May 2020 17:18:29 +0000 (10:18 -0700)]
Makefile: support compressed debug info
As debug information gets larger and larger, it helps significantly save
the size of vmlinux images to compress the information in the debug
information sections. Note: this debug info is typically split off from
the final compressed kernel image, which is why vmlinux is what's used
in conjunction with GDB. Minimizing the debug info size should have no
impact on boot times, or final compressed kernel image size.
All of the debug sections will have a `C` flag set.
$ readelf -S <object file>
$ bloaty vmlinux.gcc75.compressed.dwarf4 -- \
vmlinux.gcc75.uncompressed.dwarf4
FILE SIZE VM SIZE
-------------- --------------
+0.0% +18 [ = ] 0 [Unmapped]
-73.3% -114Ki [ = ] 0 .debug_aranges
-76.2% -2.01Mi [ = ] 0 .debug_frame
-73.6% -2.89Mi [ = ] 0 .debug_str
-80.7% -4.66Mi [ = ] 0 .debug_abbrev
-82.9% -4.88Mi [ = ] 0 .debug_ranges
-70.5% -9.04Mi [ = ] 0 .debug_line
-79.3% -10.9Mi [ = ] 0 .debug_loc
-39.5% -88.6Mi [ = ] 0 .debug_info
-18.2% -123Mi [ = ] 0 TOTAL
$ bloaty vmlinux.clang11.compressed.dwarf4 -- \
vmlinux.clang11.uncompressed.dwarf4
FILE SIZE VM SIZE
-------------- --------------
+0.0% +23 [ = ] 0 [Unmapped]
-65.6% -871 [ = ] 0 .debug_aranges
-77.4% -1.84Mi [ = ] 0 .debug_frame
-82.9% -2.33Mi [ = ] 0 .debug_abbrev
-73.1% -2.43Mi [ = ] 0 .debug_str
-84.8% -3.07Mi [ = ] 0 .debug_ranges
-65.9% -8.62Mi [ = ] 0 .debug_line
-86.2% -40.0Mi [ = ] 0 .debug_loc
-42.0% -64.1Mi [ = ] 0 .debug_info
-22.1% -122Mi [ = ] 0 TOTAL
For x86_64 defconfig + LLVM=1 (before):
Elapsed (wall clock) time (h:mm:ss or m:ss): 3:22.03
Maximum resident set size (kbytes): 43856
For x86_64 defconfig + LLVM=1 (after):
Elapsed (wall clock) time (h:mm:ss or m:ss): 3:32.52
Maximum resident set size (kbytes):
1566776
Thanks to:
Nick Clifton helped us to provide the minimal binutils version.
Sedat Dilek found an increase in size of debug .deb package.
Cc: Nick Clifton <nickc@redhat.com>
Suggested-by: David Blaikie <blaikie@google.com>
Reviewed-by: Fangrui Song <maskray@google.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Mon, 25 May 2020 05:47:05 +0000 (14:47 +0900)]
modpost: refactor sech_name()
Use sym_get_data_by_offset() helper to get access to the .shstrtab
section data. No functional change is intended because
elf->sechdrs[elf->secindex_strings].sh_addr is 0 for both ET_REL
and ET_EXEC object types.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Mon, 25 May 2020 05:47:04 +0000 (14:47 +0900)]
modpost: fix potential segmentation fault for addend_i386_rel()
This may not be a practical problem, but the second pass of ARCH=i386
modpost causes segmentation fault if the -s option is not passed.
MODPOST 12 modules
Segmentation fault (core dumped)
make[2]: *** [scripts/Makefile.modpost:94: __modpost] Error 139
make[1]: *** [Makefile:1339: modules] Error 2
make[1]: *** Waiting for unfinished jobs....
The segmentation fault occurs when section_rel() is called for vmlinux,
which is untested in regular builds. The cause of the problem is
reloc_location() returning a wrong pointer for ET_EXEC object type.
In this case, you need to subtract sechdr->sh_addr, otherwise it would
get access beyond the mmap'ed memory.
Add sym_get_data_by_offset() helper to avoid code duplication.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Sun, 24 May 2020 15:42:15 +0000 (00:42 +0900)]
kbuild: disallow multi-word in M= or KBUILD_EXTMOD
$(firstword ...) in scripts/Makefile.modpost was added by commit
3f3fd3c05585 ("[PATCH] kbuild: allow multi-word $M in Makefile.modpost")
to build multiple external module directories.
It was a solution to resolve symbol dependencies when an external
module depends on another external module.
Commit
0d96fb20b7ed ("kbuild: Add new Kbuild variable
KBUILD_EXTRA_SYMBOLS") introduced another solution by passing symbol
info via KBUILD_EXTRA_SYMBOLS, then broke the multi-word M= support.
include $(if $(wildcard $(KBUILD_EXTMOD)/Kbuild), \
$(KBUILD_EXTMOD)/Kbuild, $(KBUILD_EXTMOD)/Makefile)
... does not work if KBUILD_EXTMOD contains multiple words.
This feature has been broken for more than a decade. Remove the
bitrotten code, and stop parsing if M or KBUILD_EXTMOD contains
multiple words.
As Documentation/kbuild/modules.rst explains, if your module depends
on another one, there are two solutions:
- add a common top-level Kbuild file
- use KBUILD_EXTRA_SYMBOLS
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Fri, 22 May 2020 02:00:02 +0000 (11:00 +0900)]
kbuild: make modules.order rule consistent with built-in.a
built-in.a contains the built-in object paths from the current and sub
directories.
module.order collects the module paths from the current and sub
directories.
Make their build rules look more symmetrical.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Fri, 22 May 2020 02:00:01 +0000 (11:00 +0900)]
kbuild: rename subdir-obj-y to subdir-builtin
I think subdir-builtin is clearer.
While I was here, I made its build rule explicit.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Fri, 22 May 2020 02:00:00 +0000 (11:00 +0900)]
kbuild: move subdir-obj-y to scripts/Makefile.build
Save $(addprefix ...) for subdir-obj-y.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Fri, 22 May 2020 01:59:59 +0000 (10:59 +0900)]
kbuild: clear KBUILD_MODULES in top Makefile if CONFIG_MODULES=n
Do not try to build any module-related artifacts when CONFIG_MODULES
is disabled.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Fri, 22 May 2020 01:59:58 +0000 (10:59 +0900)]
kbuild: remove ifdef builtin-target / lib-target
I do not see a good reason to add ifdef here.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Thu, 21 May 2020 04:31:17 +0000 (13:31 +0900)]
kbuild: doc: remove documentation about copying Module.symvers around
This is a left-over of commit
39808e451fdf ("kbuild: do not read
$(KBUILD_EXTMOD)/Module.symvers").
Kbuild no longer supports this way.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Mon, 11 May 2020 04:21:49 +0000 (13:21 +0900)]
kbuild: make module name conflict fatal error
I think all the warnings have been fixed by now. Make it a fatal error.
Check it before modpost because we need to stop building *.ko files.
Also, pass modules.order via a script parameter.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Mon, 11 May 2020 03:50:13 +0000 (12:50 +0900)]
kbuild: error out if targets prefixed with '__' are directly run
Some targets are internal-use only.
It is tedious to care about "what if __build_one_by_one is contained
in $(MAKECMDGOALS)?" etc.
Prefix internal targets with double underscores. Stop parsing Makefile
if they are directly run.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Mon, 11 May 2020 03:50:12 +0000 (12:50 +0900)]
kbuild: add this-makefile as a shorthand for $(lastword $(MAKEFILE_LIST))
Make it clearer, and self-documenting.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Sun, 10 May 2020 02:00:44 +0000 (11:00 +0900)]
gcc-plugins: remove always-false $(if ...) in Makefile
This is the remnant of commit
c17d6179ad5a ("gcc-plugins: remove unused
GCC_PLUGIN_SUBDIR").
The conditional $(if $(findstring /,$(p)),...) is always false because
none of plugins contains '/' in the file name.
Clean up the code.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Valdis Kl ē tnieks [Sat, 9 May 2020 04:47:19 +0000 (00:47 -0400)]
bpfilter: document build requirements for bpfilter_umh
It's not intuitively obvious that bpfilter_umh is a statically linked binary.
Mention the toolchain requirement in the Kconfig help, so people
have an easier time figuring out what's needed.
Signed-off-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Maninder Singh [Fri, 8 May 2020 11:03:17 +0000 (16:33 +0530)]
scripts/checkstack.pl: fix arm sp regex
if objdump has below entries;
c01ed608 <X>:
c01ed614:
e24ddff7 sub sp, sp, #120 ; 0x78
c01f0d50 <Y>:
c01f0d50:
e24dd094 sub sp, sp, #140 ; 0x8c
scripts fails to read stack usage.
so making regex $re for ARM similar to aarch64
Co-developed-by: Vaneet Narang <v.narang@samsung.com>
Signed-off-by: Vaneet Narang <v.narang@samsung.com>
Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Maninder Singh [Fri, 8 May 2020 11:03:16 +0000 (16:33 +0530)]
scripts/checkstack.pl: add arm push handling for stack usage
To count stack usage of push {*, fp, ip, lr, pc} instruction in ARM,
if FRAME POINTER is enabled.
e.g.
c01f0d48:
e92ddff0 push {r4, r5, r6, r7, r8, r9, sl, fp, ip, lr, pc}
c01f0d50 <Y>:
c01f0d44:
e1a0c00d mov ip, sp
c01f0d48:
e92ddff0 push {r4, r5, r6, r7, r8, r9, sl, fp, ip, lr, pc}
c01f0d4c:
e24cb004 sub fp, ip, #4
c01f0d50:
e24dd094 sub sp, sp, #448 ; 0x1C0
$ cat dump | scripts/checkstack.pl arm
0xc01f0d50 Y []: 448
added subroutine frame work for this.
After change:
0xc01f0d500 Y []: 492
Co-developed-by: Vaneet Narang <v.narang@samsung.com>
Signed-off-by: Vaneet Narang <v.narang@samsung.com>
Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Maninder Singh [Fri, 8 May 2020 11:03:15 +0000 (16:33 +0530)]
scripts/checkstack.pl: Add argument to print stacks greather than value.
Add arguments support to print stacks which are greater than
argument value only.
Co-developed-by: Vaneet Narang <v.narang@samsung.com>
Signed-off-by: Vaneet Narang <v.narang@samsung.com>
Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Maninder Singh [Fri, 8 May 2020 11:03:14 +0000 (16:33 +0530)]
scripts/checkstack.pl: don't display $dre as different entity
currently script prints stack usage for functions
in two ways:($re and $dre)
dre breaks sorting mechanism.
0xffffa00011f26f88 sunxi_mux_clk_setup.isra.0 [vmlinux]:Dynamic (0x140)
..
0xffffa00011f27210 sunxi_divs_clk_setup [vmlinux]: Dynamic (0x1d0)
so we can print it in decimal only.
Also address before function name is changed to function
start address rather than stack consumption address.
Because in next patch, arm has two ways to use stack
which can be clubbed and printed in one function only.
All symbols whose stack by adding(re and dre) is greater than
100, will be printed.
0xffffa00011f2720c0 sunxi_divs_clk_setup [vmlinux]: 464
...
0xffffa00011f26f840 sunxi_mux_clk_setup.isra.0 [vmlinux]:320
Co-developed-by: Vaneet Narang <v.narang@samsung.com>
Signed-off-by: Vaneet Narang <v.narang@samsung.com>
Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Gustavo A. R. Silva [Thu, 7 May 2020 18:56:01 +0000 (13:56 -0500)]
modpost,fixdep: Replace zero-length array with flexible-array
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in
which the sizeof operator is being incorrectly/erroneously applied to
zero-length arrays and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also
help to get completely rid of those sorts of issues.
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Siddharth Gupta [Wed, 6 May 2020 01:52:37 +0000 (18:52 -0700)]
scripts: headers_install: Exit with error on config leak
Misuse of CONFIG_* in UAPI headers should result in an error. These config
options can be set in userspace by the user application which includes
these headers to control the APIs and structures being used in a kernel
which supports multiple targets.
Signed-off-by: Siddharth Gupta <sidgup@codeaurora.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Mon, 4 May 2020 08:08:07 +0000 (17:08 +0900)]
kbuild: remove {CLEAN,MRPROPER,DISTCLEAN}_DIRS
Merge {CLEAN,MRPROPER,DISTCLEAN}_DIRS into {CLEAN,MRPROPER,DISTCLEAN}_FILES
because the difference is just the -r option passed to the 'rm' command.
Do likewise as commit
1634f2bfdb84 ("kbuild: remove clean-dirs syntax").
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Mon, 4 May 2020 08:08:06 +0000 (17:08 +0900)]
kbuild: remove misleading stale FIXME comment
This comment was added by commit ("kbuild: Restore build nr, improve
vmlinux link") [1].
It was talking about if_changed_rule at that time. Now, it is unclear
what to fix.
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=
ea52ca1b3e3882b499cc6c043f384958b88b62ff
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Fri, 1 May 2020 06:01:41 +0000 (15:01 +0900)]
kbuild: invoke syncconfig if autoconf.h is missing
If include/generated/autoconf.h is accidentally lost somehow,
there is no clear way to fix it. Make it self-healing.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Wed, 29 Apr 2020 03:45:27 +0000 (12:45 +0900)]
samples: watchdog: use 'userprogs' syntax
Kbuild now supports the 'userprogs' syntax to compile userspace
programs for the same architecture as the kernel.
Add the entry to samples/Makefile to put this into the build bot
coverage.
I also added the CONFIG option guarded by 'depends on CC_CAN_LINK'
because $(CC) may not provide libc.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Masahiro Yamada [Wed, 29 Apr 2020 03:45:26 +0000 (12:45 +0900)]
samples: timers: use 'userprogs' syntax
Kbuild now supports the 'userprogs' syntax to compile userspace
programs for the same architecture as the kernel.
Add the entry to samples/Makefile to put this into the build bot
coverage.
I also added the CONFIG option guarded by 'depends on CC_CAN_LINK'
because $(CC) may not provide libc.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Masahiro Yamada [Wed, 29 Apr 2020 03:45:25 +0000 (12:45 +0900)]
samples: auxdisplay: use 'userprogs' syntax
Kbuild now supports the 'userprogs' syntax to compile userspace
programs for the same architecture as the kernel.
Add the entry to samples/Makefile to put this into the build bot
coverage.
I also added the CONFIG option guarded by 'depends on CC_CAN_LINK'
because $(CC) may not provide libc.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Masahiro Yamada [Wed, 29 Apr 2020 03:45:24 +0000 (12:45 +0900)]
samples: mei: build sample program for target architecture
This userspace program includes UAPI headers exported to usr/include/.
'make headers' always works for the target architecture (i.e. the same
architecture as the kernel), so the sample program should be built for
the target as well. Kbuild now supports 'userprogs' for that.
I also guarded the CONFIG option by 'depends on CC_CAN_LINK' because
$(CC) may not provide libc.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Masahiro Yamada [Wed, 29 Apr 2020 03:45:23 +0000 (12:45 +0900)]
samples: pidfd: build sample program for target architecture
This userspace program includes UAPI headers exported to usr/include/.
'make headers' always works for the target architecture (i.e. the same
architecture as the kernel), so the sample program should be built for
the target as well. Kbuild now supports 'userprogs' for that.
I also guarded the CONFIG option by 'depends on CC_CAN_LINK' because
$(CC) may not provide libc.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Masahiro Yamada [Wed, 29 Apr 2020 03:45:22 +0000 (12:45 +0900)]
samples: vfs: build sample programs for target architecture
These userspace programs include UAPI headers exported to usr/include/.
'make headers' always works for the target architecture (i.e. the same
architecture as the kernel), so the sample programs should be built for
the target as well. Kbuild now supports 'userprogs' for that.
I also guarded the CONFIG option by 'depends on CC_CAN_LINK' because
$(CC) may not provide libc.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Masahiro Yamada [Wed, 29 Apr 2020 03:45:21 +0000 (12:45 +0900)]
samples: connector: build sample program for target architecture
This userspace program includes UAPI headers exported to usr/include/.
'make headers' always works for the target architecture (i.e. the same
architecture as the kernel), so the sample program should be built for
the target as well. Kbuild now supports 'userprogs' for that.
$(CC) can always compile cn_text.o since it is the kenrel-space code,
but building ucon requires libc.
I guarded it by:
always-$(CONFIG_CC_CAN_LINK) := $(userprogs)
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Masahiro Yamada [Wed, 29 Apr 2020 03:45:20 +0000 (12:45 +0900)]
samples: hidraw: build sample program for target architecture
This userspace program includes UAPI headers exported to usr/include/.
'make headers' always works for the target architecture (i.e. the same
architecture as the kernel), so the sample program should be built for
the target as well. Kbuild now supports 'userprogs' for that.
I also guarded the CONFIG option by 'depends on CC_CAN_LINK' because
$(CC) may not provide libc.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Masahiro Yamada [Wed, 29 Apr 2020 03:45:19 +0000 (12:45 +0900)]
samples: uhid: build sample program for target architecture
This userspace program includes UAPI headers exported to usr/include/.
'make headers' always works for the target architecture (i.e. the same
architecture as the kernel), so the sample program should be built for
the target as well. Kbuild now supports 'userprogs' for that.
Add the entry to samples/Makefile to put this into the build bot
coverage.
I also added the CONFIG option guarded by 'depends on CC_CAN_LINK'
because $(CC) may not provide libc.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Sam Ravnborg [Wed, 29 Apr 2020 03:45:18 +0000 (12:45 +0900)]
samples: uhid: fix warnings in uhid-example
Fix warnings seen when building for 32-bit architecture.
Use "%xd" for arguments of type size_t to fix the warnings.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Wed, 29 Apr 2020 03:45:17 +0000 (12:45 +0900)]
kbuild: doc: document the new syntax 'userprogs'
Kbuild now supports the syntax 'userprogs' to compile userspace
programs for the same architecture as the kernel.
Insert the section '5 Userspace Program support' to explain it.
I copy-pasted '4 Host Program support' and fixed it up.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Masahiro Yamada [Wed, 29 Apr 2020 03:45:16 +0000 (12:45 +0900)]
samples: seccomp: build sample programs for target architecture
These userspace programs include UAPI headers exported to usr/include/.
'make headers' always works for the target architecture (i.e. the same
architecture as the kernel), so the sample programs should be built for
the target as well. Kbuild now supports 'userprogs' for that.
I also guarded the CONFIG option by 'depends on CC_CAN_LINK' because
$(CC) may not provide libc.
The 'ifndef CROSS_COMPILE' is no longer needed.
BTW, the -m31 for s390 is left-over code. Commit
5a79859ae0f3 ("s390:
remove 31 bit support") killed it.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Masahiro Yamada [Wed, 29 Apr 2020 03:45:15 +0000 (12:45 +0900)]
bpfilter: use 'userprogs' syntax to build bpfilter_umh
The user mode helper should be compiled for the same architecture as
the kernel.
This Makefile reused the 'hostprogs' syntax by overriding HOSTCC with CC.
Use the new syntax 'userprogs' to fix the Makefile mess.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Masahiro Yamada [Wed, 29 Apr 2020 03:45:14 +0000 (12:45 +0900)]
kbuild: add infrastructure to build userspace programs
Kbuild supports the infrastructure to build host programs, but there
was no support to build userspace programs for the target architecture
(i.e. the same architecture as the kernel).
Sam Ravnborg worked on this in 2014 (https://lkml.org/lkml/2014/7/13/154),
but it was not merged. One problem at that time was, there was no good way
to know whether $(CC) can link standalone programs. In fact, pre-built
kernel.org toolchains [1] are often used for building the kernel, but they
do not provide libc.
Now, we can handle this cleanly because the compiler capability is
evaluated at the Kconfig time. If $(CC) cannot link standalone programs,
the relevant options are hidden by 'depends on CC_CAN_LINK'.
The implementation just mimics scripts/Makefile.host
The userspace programs are compiled with the same flags as the host
programs. In addition, it uses -m32 or -m64 if it is found in
$(KBUILD_CFLAGS).
This new syntax has two usecases.
- Sample programs
Several userspace programs under samples/ include UAPI headers
installed in usr/include. Most of them were previously built for
the host architecture just to use the 'hostprogs' syntax.
However, 'make headers' always works for the target architecture.
This caused the arch mismatch in cross-compiling. To fix this
distortion, sample code should be built for the target architecture.
- Bpfilter
net/bpfilter/Makefile compiles bpfilter_umh as the user mode helper,
and embeds it into the kernel. Currently, it overrides HOSTCC with
CC to use the 'hostprogs' syntax. This hack should go away.
[1]: https://mirrors.edge.kernel.org/pub/tools/crosstool/
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Masahiro Yamada [Sat, 9 May 2020 07:39:15 +0000 (16:39 +0900)]
bpfilter: check if $(CC) can link static libc in Kconfig
On Fedora, linking static glibc requires the glibc-static RPM package,
which is not part of the glibc-devel package.
CONFIG_CC_CAN_LINK does not check the capability of static linking,
so you can enable CONFIG_BPFILTER_UMH, then fail to build:
HOSTLD net/bpfilter/bpfilter_umh
/usr/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
Add CONFIG_CC_CAN_LINK_STATIC, and make CONFIG_BPFILTER_UMH depend
on it.
Reported-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Masahiro Yamada [Wed, 29 Apr 2020 03:45:13 +0000 (12:45 +0900)]
bpfilter: match bit size of bpfilter_umh to that of the kernel
bpfilter_umh is built for the default machine bit of the compiler,
which may not match to the bit size of the kernel.
This happens in the scenario below:
You can use biarch GCC that defaults to 64-bit for building the 32-bit
kernel. In this case, Kbuild passes -m32 to teach the compiler to
produce 32-bit kernel space objects. However, it is missing when
building bpfilter_umh. It is built as a 64-bit ELF, and then embedded
into the 32-bit kernel.
The 32-bit kernel and 64-bit umh is a bad combination.
In theory, we can have 32-bit umh running on 64-bit kernel, but we do
not have a good reason to support such a usecase.
The best is to match the bit size between them.
Pass -m32 or -m64 to the umh build command if it is found in
$(KBUILD_CFLAGS). Evaluate CC_CAN_LINK against the kernel bit-size.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Mon, 27 Apr 2020 16:03:57 +0000 (01:03 +0900)]
kbuild: warn if always, hostprogs-y, or hostprogs-m is used
always, hostprogs-y, and hostprogs-m are deprecated.
There is no user in upstream code, but I will keep them for external
modules. I want to remove them entirely someday. Prompt downstream
users for the migration.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Mon, 27 Apr 2020 13:49:30 +0000 (22:49 +0900)]
kbuild: determine the output format of DTC by the target suffix
cmd_dtc takes the additional parameter $(2) to select the target
format, dtb or yaml. This makes things complicated when it is used
with cmd_and_fixdep and if_changed_rule. I actually stumbled on this.
See commit
3d4b2238684a ("kbuild: fix DT binding schema rule again to
avoid needless rebuilds").
Extract the suffix part of the target instead of passing the parameter.
Fortunately, this works for both $(obj)/%.dtb and $(obj)/%.dt.yaml .
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Mon, 27 Apr 2020 00:30:19 +0000 (09:30 +0900)]
kbuild: remove unused AS assignment
$(AS) is not used anywhere in the kernel build, hence commit
aa824e0c962b ("kbuild: remove AS variable") killed it.
Remove the left-over code in arch/{arm,arm64}/Makefile.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Acked-by: Will Deacon <will@kernel.org>
Masahiro Yamada [Sat, 25 Apr 2020 13:18:10 +0000 (22:18 +0900)]
kbuild: remove '/' target
This notice has been here for a while. Remove it entirely now.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Thu, 23 Apr 2020 07:39:15 +0000 (16:39 +0900)]
Revert "objtool: Skip samples subdirectory"
This reverts commit
8728497895794d1f207a836e02dae762ad175d56.
samples/ contains only sub-directories.
Because OBJECT_FILES_NON_STANDARD does not work recursively,
this line has no effect.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Masahiro Yamada [Thu, 23 Apr 2020 14:23:54 +0000 (23:23 +0900)]
kbuild: use CONFIG_CC_VERSION_TEXT to construct LINUX_COMPILER macro
scripts/mkcompile_h runs $(CC) just for getting the version string.
Reuse CONFIG_CC_VERSION_TEXT for optimization.
For GCC, this slightly changes the version string. I do not think it
is a big deal as we do not have the defined format for LINUX_COMPILER.
In fact, the recent commit
4dcc9a88448a ("kbuild: mkcompile_h:
Include $LD version in /proc/version") added the linker version.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Thu, 23 Apr 2020 14:23:53 +0000 (23:23 +0900)]
kbuild: use -MMD instead of -MD to exclude system headers from dependency
This omits system headers from the generated header dependency.
System headers are not updated unless you upgrade the compiler. Nor do
they contain CONFIG options, so fixdep does not need to parse them.
Having said that, the effect of this optimization will be quite small
because the kernel code generally does not include system headers
except <stdarg.h>. Host programs include a lot of system headers,
but there are not so many in the kernel tree.
At first, keeping system headers in .*.cmd files might be useful to
detect the compiler update, but there is no guarantee that <stdarg.h>
is included from every file. So, I implemented a more reliable way in
the previous commit.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Thu, 23 Apr 2020 14:23:52 +0000 (23:23 +0900)]
kbuild: ensure full rebuild when the compiler is updated
Commit
21c54b774744 ("kconfig: show compiler version text in the top
comment") added the environment variable, CC_VERSION_TEXT in the comment
of the top Kconfig file. It can detect the compiler update, and invoke
the syncconfig because all environment variables referenced in Kconfig
files are recorded in include/config/auto.conf.cmd
This commit makes it a CONFIG option in order to ensure the full rebuild
when the compiler is updated.
This works like follows:
include/config/kconfig.h contains "CONFIG_CC_VERSION_TEXT" in the comment
block.
The top Makefile specifies "-include $(srctree)/include/linux/kconfig.h"
to guarantee it is included from all kernel source files.
fixdep parses every source file and all headers included from it,
searching for words prefixed with "CONFIG_". Then, fixdep finds
CONFIG_CC_VERSION_TEXT in include/config/kconfig.h and adds
include/config/cc/version/text.h into every .*.cmd file.
When the compiler is updated, syncconfig is invoked because init/Kconfig
contains the reference to the environment variable CC_VERTION_TEXT.
CONFIG_CC_VERSION_TEXT is updated to the new version string, and
include/config/cc/version/text.h is touched.
In the next rebuild, Make will rebuild every files since the timestamp
of include/config/cc/version/text.h is newer than that of target.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Thu, 23 Apr 2020 14:23:51 +0000 (23:23 +0900)]
kbuild: use $(CC_VERSION_TEXT) to evaluate CC_IS_GCC and CC_IS_CLANG
The result of '$(CC) --version | head -n 1' has already been computed
by the top Makefile, and stored in the environment variable,
CC_VERSION_TEXT.
'echo' is cheaper than the two commands $(CC) and 'head' although this
optimization is not noticeable level.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Masahiro Yamada [Sat, 25 Apr 2020 06:06:40 +0000 (15:06 +0900)]
unicore32: do not evaluate compiler's library path when cleaning
Since commit
a83e4ca26af8 ("kbuild: remove cc-option switch from
-Wframe-larger-than="), 'make ARCH=unicore32 clean' emits error
messages as follows:
$ make ARCH=unicore32 clean
gcc: error: missing argument to '-Wframe-larger-than='
gcc: error: missing argument to '-Wframe-larger-than='
We do not care compiler flags when cleaning.
Use the '=' operator for lazy expansion because we do not use
GNU_LIBC_A or GNU_LIBGCC_A when cleaning.
Fixes:
a83e4ca26af8 ("kbuild: remove cc-option switch from -Wframe-larger-than=")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Masahiro Yamada [Sat, 25 Apr 2020 05:18:16 +0000 (14:18 +0900)]
h8300: suppress error messages for 'make clean'
'make ARCH=h8300 clean' emits error messages as follows:
$ make ARCH=h8300 clean
gcc: error: missing argument to '-Wframe-larger-than='
gcc: error: unrecognized command line option '-mint32'
You can suppress the second one by setting the correct CROSS_COMPILE=,
but we should not require any compiler for cleaning.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada [Fri, 24 Apr 2020 16:15:02 +0000 (01:15 +0900)]
hexagon: suppress error message for 'make clean'
'make ARCH=hexagon clean' emits an error message as follows:
$ make ARCH=hexagon clean
gcc: error: unrecognized command line option '-G0'
You can suppress it by setting the correct CROSS_COMPILE=,
but we should not require any compiler for cleaning.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Brian Cain <bcain@codeaurora.org>
Masahiro Yamada [Fri, 17 Apr 2020 18:04:55 +0000 (03:04 +0900)]
um: do not evaluate compiler's library path when cleaning
Since commit
a83e4ca26af8 ("kbuild: remove cc-option switch from
-Wframe-larger-than="), 'make ARCH=um clean' emits an error message
as follows:
$ make ARCH=um clean
gcc: error: missing argument to '-Wframe-larger-than='
We do not care compiler flags when cleaning.
Use the '=' operator for lazy expansion because we do not use
LDFLAGS_pcap.o or LDFLAGS_vde.o when cleaning.
While I was here, I removed the redundant -r option because it
already exists in the recipe.
Fixes:
a83e4ca26af8 ("kbuild: remove cc-option switch from -Wframe-larger-than=")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com> [build]
Linus Torvalds [Sun, 10 May 2020 22:16:58 +0000 (15:16 -0700)]
Linux 5.7-rc5
Linus Torvalds [Sun, 10 May 2020 18:59:53 +0000 (11:59 -0700)]
Merge tag 'x86-urgent-2020-05-10' of git://git./linux/kernel/git/tip/tip
Pull x86 fixes from Thomas Gleixner:
"A set of fixes for x86:
- Ensure that direct mapping alias is always flushed when changing
page attributes. The optimization for small ranges failed to do so
when the virtual address was in the vmalloc or module space.
- Unbreak the trace event registration for syscalls without arguments
caused by the refactoring of the SYSCALL_DEFINE0() macro.
- Move the printk in the TSC deadline timer code to a place where it
is guaranteed to only be called once during boot and cannot be
rearmed by clearing warn_once after boot. If it's invoked post boot
then lockdep rightfully complains about a potential deadlock as the
calling context is different.
- A series of fixes for objtool and the ORC unwinder addressing
variety of small issues:
- Stack offset tracking for indirect CFAs in objtool ignored
subsequent pushs and pops
- Repair the unwind hints in the register clearing entry ASM code
- Make the unwinding in the low level exit to usermode code stop
after switching to the trampoline stack. The unwind hint is no
longer valid and the ORC unwinder emits a warning as it can't
find the registers anymore.
- Fix unwind hints in switch_to_asm() and rewind_stack_do_exit()
which caused objtool to generate bogus ORC data.
- Prevent unwinder warnings when dumping the stack of a
non-current task as there is no way to be sure about the
validity because the dumped stack can be a moving target.
- Make the ORC unwinder behave the same way as the frame pointer
unwinder when dumping an inactive tasks stack and do not skip
the first frame.
- Prevent ORC unwinding before ORC data has been initialized
- Immediately terminate unwinding when a unknown ORC entry type
is found.
- Prevent premature stop of the unwinder caused by IRET frames.
- Fix another infinite loop in objtool caused by a negative
offset which was not catched.
- Address a few build warnings in the ORC unwinder and add
missing static/ro_after_init annotations"
* tag 'x86-urgent-2020-05-10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/unwind/orc: Move ORC sorting variables under !CONFIG_MODULES
x86/apic: Move TSC deadline timer debug printk
ftrace/x86: Fix trace event registration for syscalls without arguments
x86/mm/cpa: Flush direct map alias during cpa
objtool: Fix infinite loop in for_offset_range()
x86/unwind/orc: Fix premature unwind stoppage due to IRET frames
x86/unwind/orc: Fix error path for bad ORC entry type
x86/unwind/orc: Prevent unwinding before ORC initialization
x86/unwind/orc: Don't skip the first frame for inactive tasks
x86/unwind: Prevent false warnings for non-current tasks
x86/unwind/orc: Convert global variables to static
x86/entry/64: Fix unwind hints in rewind_stack_do_exit()
x86/entry/64: Fix unwind hints in __switch_to_asm()
x86/entry/64: Fix unwind hints in kernel exit path
x86/entry/64: Fix unwind hints in register clearing code
objtool: Fix stack offset tracking for indirect CFAs
Linus Torvalds [Sun, 10 May 2020 18:42:14 +0000 (11:42 -0700)]
Merge tag 'objtool-urgent-2020-05-10' of git://git./linux/kernel/git/tip/tip
Pull objtool fix from Thomas Gleixner:
"A single fix for objtool to prevent an infinite loop in the
jump table search which can be triggered when building the
kernel with '-ffunction-sections'"
* tag 'objtool-urgent-2020-05-10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
objtool: Fix infinite loop in find_jump_table()
Linus Torvalds [Sun, 10 May 2020 18:39:31 +0000 (11:39 -0700)]
Merge tag 'locking-urgent-2020-05-10' of git://git./linux/kernel/git/tip/tip
Pull locking fix from Thomas Gleixner:
"A single fix for the fallout of the recent futex uacess rework.
With those changes GCC9 fails to analyze arch_futex_atomic_op_inuser()
correctly and emits a 'maybe unitialized' warning. While we usually
ignore compiler stupidity the conditional store is pointless anyway
because the correct case has to store. For the fault case the extra
store does no harm"
* tag 'locking-urgent-2020-05-10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
ARM: futex: Address build warning
Linus Torvalds [Sun, 10 May 2020 18:26:23 +0000 (11:26 -0700)]
Merge tag 'iommu-fixes-v5.7-rc4' of git://git./linux/kernel/git/joro/iommu
Pull iommu fixes from Joerg Roedel:
- Race condition fixes for the AMD IOMMU driver.
These are five patches fixing two race conditions around
increase_address_space(). The first race condition was around the
non-atomic update of the domain page-table root pointer and the
variable containing the page-table depth (called mode). This is fixed
now be merging page-table root and mode into one 64-bit field which
is read/written atomically.
The second race condition was around updating the page-table root
pointer and making it public before the hardware caches were flushed.
This could cause addresses to be mapped and returned to drivers which
are not reachable by IOMMU hardware yet, causing IO page-faults. This
is fixed too by adding the necessary flushes before a new page-table
root is published.
Related to the race condition fixes these patches also add a missing
domain_flush_complete() barrier to update_domain() and a fix to bail
out of the loop which tries to increase the address space when the
call to increase_address_space() fails.
Qian was able to trigger the race conditions under high load and
memory pressure within a few days of testing. He confirmed that he
has seen no issues anymore with the fixes included here.
- Fix for a list-handling bug in the VirtIO IOMMU driver.
* tag 'iommu-fixes-v5.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
iommu/virtio: Reverse arguments to list_add
iommu/amd: Do not flush Device Table in iommu_map_page()
iommu/amd: Update Device Table in increase_address_space()
iommu/amd: Call domain_flush_complete() in update_domain()
iommu/amd: Do not loop forever when trying to increase address space
iommu/amd: Fix race in increase_address_space()/fetch_pte()
Linus Torvalds [Sun, 10 May 2020 18:16:07 +0000 (11:16 -0700)]
Merge tag 'block-5.7-2020-05-09' of git://git.kernel.dk/linux-block
Pull block fixes from Jens Axboe:
- a small series fixing a use-after-free of bdi name (Christoph,Yufen)
- NVMe fix for a regression with the smaller CQ update (Alexey)
- NVMe fix for a hang at namespace scanning error recovery (Sagi)
- fix race with blk-iocost iocg->abs_vdebt updates (Tejun)
* tag 'block-5.7-2020-05-09' of git://git.kernel.dk/linux-block:
nvme: fix possible hang when ns scanning fails during error recovery
nvme-pci: fix "slimmer CQ head update"
bdi: add a ->dev_name field to struct backing_dev_info
bdi: use bdi_dev_name() to get device name
bdi: move bdi_dev_name out of line
vboxsf: don't use the source name in the bdi name
iocost: protect iocg->abs_vdebt with iocg->waitq.lock
Linus Torvalds [Sun, 10 May 2020 00:50:03 +0000 (17:50 -0700)]
gcc-10: mark more functions __init to avoid section mismatch warnings
It seems that for whatever reason, gcc-10 ends up not inlining a couple
of functions that used to be inlined before. Even if they only have one
single callsite - it looks like gcc may have decided that the code was
unlikely, and not worth inlining.
The code generation difference is harmless, but caused a few new section
mismatch errors, since the (now no longer inlined) function wasn't in
the __init section, but called other init functions:
Section mismatch in reference from the function kexec_free_initrd() to the function .init.text:free_initrd_mem()
Section mismatch in reference from the function tpm2_calc_event_log_size() to the function .init.text:early_memremap()
Section mismatch in reference from the function tpm2_calc_event_log_size() to the function .init.text:early_memunmap()
So add the appropriate __init annotation to make modpost not complain.
In both cases there were trivially just a single callsite from another
__init function.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Sat, 9 May 2020 23:24:16 +0000 (16:24 -0700)]
Merge tag 'riscv-for-linus-5.7-rc5' of git://git./linux/kernel/git/riscv/linux
Pull RISC-V fixes from Palmer Dabbelt:
"A smattering of fixes and cleanups:
- Dead code removal.
- Exporting riscv_cpuid_to_hartid_mask for modules.
- Per-CPU tracking of ISA features.
- Setting max_pfn correctly when probing memory.
- Adding a note to the VDSO so glibc can check the kernel's version
without a uname().
- A fix to force the bootloader to initialize the boot spin tables,
which still get used as a fallback when SBI-0.1 is enabled"
* tag 'riscv-for-linus-5.7-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
RISC-V: Remove unused code from STRICT_KERNEL_RWX
riscv: force __cpu_up_ variables to put in data section
riscv: add Linux note to vdso
riscv: set max_pfn to the PFN of the last page
RISC-V: Remove N-extension related defines
RISC-V: Add bitmap reprensenting ISA features common across CPUs
RISC-V: Export riscv_cpuid_to_hartid_mask() API
Linus Torvalds [Sat, 9 May 2020 22:58:04 +0000 (15:58 -0700)]
gcc-10: avoid shadowing standard library 'free()' in crypto
gcc-10 has started warning about conflicting types for a few new
built-in functions, particularly 'free()'.
This results in warnings like:
crypto/xts.c:325:13: warning: conflicting types for built-in function ‘free’; expected ‘void(void *)’ [-Wbuiltin-declaration-mismatch]
because the crypto layer had its local freeing functions called
'free()'.
Gcc-10 is in the wrong here, since that function is marked 'static', and
thus there is no chance of confusion with any standard library function
namespace.
But the simplest thing to do is to just use a different name here, and
avoid this gcc mis-feature.
[ Side note: gcc knowing about 'free()' is in itself not the
mis-feature: the semantics of 'free()' are special enough that a
compiler can validly do special things when seeing it.
So the mis-feature here is that gcc thinks that 'free()' is some
restricted name, and you can't shadow it as a local static function.
Making the special 'free()' semantics be a function attribute rather
than tied to the name would be the much better model ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Sat, 9 May 2020 22:45:21 +0000 (15:45 -0700)]
gcc-10: disable 'restrict' warning for now
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>
Linus Torvalds [Sat, 9 May 2020 22:40:52 +0000 (15:40 -0700)]
gcc-10: disable 'stringop-overflow' warning for now
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>
Sagi Grimberg [Wed, 6 May 2020 22:44:02 +0000 (15:44 -0700)]
nvme: fix possible hang when ns scanning fails during error recovery
When the controller is reconnecting, the host fails I/O and admin
commands as the host cannot reach the controller. ns scanning may
revalidate namespaces during that period and it is wrong to remove
namespaces due to these failures as we may hang (see
205da2434301).
One command that may fail is nvme_identify_ns_descs. Since we return
success due to having ns identify descriptor list optional, we continue
to compare ns identifiers in nvme_revalidate_disk, obviously fail and
return -ENODEV to nvme_validate_ns, which will remove the namespace.
Exactly what we don't want to happen.
Fixes:
22802bf742c2 ("nvme: Namepace identification descriptor list is optional")
Tested-by: Anton Eidelman <anton@lightbitslabs.com>
Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
Reviewed-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Alexey Dobriyan [Thu, 7 May 2020 20:07:04 +0000 (23:07 +0300)]
nvme-pci: fix "slimmer CQ head update"
Pre-incrementing ->cq_head can't be done in memory because OOB value
can be observed by another context.
This devalues space savings compared to original code :-\
$ ./scripts/bloat-o-meter ../vmlinux-000 ../obj/vmlinux
add/remove: 0/0 grow/shrink: 0/4 up/down: 0/-32 (-32)
Function old new delta
nvme_poll_irqdisable 464 456 -8
nvme_poll 455 447 -8
nvme_irq 388 380 -8
nvme_dev_disable 955 947 -8
But the code is minimal now: one read for head, one read for q_depth,
one increment, one comparison, single instruction phase bit update and
one write for new head.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Reported-by: John Garry <john.garry@huawei.com>
Tested-by: John Garry <john.garry@huawei.com>
Fixes:
e2a366a4b0feaeb ("nvme-pci: slimmer CQ head update")
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Christoph Hellwig [Mon, 4 May 2020 12:47:56 +0000 (14:47 +0200)]
bdi: add a ->dev_name field to struct backing_dev_info
Cache a copy of the name for the life time of the backing_dev_info
structure so that we can reference it even after unregistering.
Fixes:
68f23b89067f ("memcg: fix a crash in wb_workfn when a device disappears")
Reported-by: Yufen Yu <yuyufen@huawei.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Yufen Yu [Mon, 4 May 2020 12:47:55 +0000 (14:47 +0200)]
bdi: use bdi_dev_name() to get device name
Use the common interface bdi_dev_name() to get device name.
Signed-off-by: Yufen Yu <yuyufen@huawei.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Add missing <linux/backing-dev.h> include BFQ
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Linus Torvalds [Sat, 9 May 2020 21:52:44 +0000 (14:52 -0700)]
gcc-10: disable 'array-bounds' warning for now
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>
Linus Torvalds [Sat, 9 May 2020 21:30:29 +0000 (14:30 -0700)]
gcc-10: disable 'zero-length-bounds' warning for now
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>
Linus Torvalds [Sat, 9 May 2020 20:57:10 +0000 (13:57 -0700)]
Stop the ad-hoc games with -Wno-maybe-initialized
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>
Linus Torvalds [Sat, 9 May 2020 19:02:09 +0000 (12:02 -0700)]
Merge tag 'io_uring-5.7-2020-05-08' of git://git.kernel.dk/linux-block
Pull io_uring fixes from Jens Axboe:
- Fix finish_wait() balancing in file cancelation (Xiaoguang)
- Ensure early cleanup of resources in ring map failure (Xiaoguang)
- Ensure IORING_OP_SLICE does the right file mode checks (Pavel)
- Remove file opening from openat/openat2/statx, it's not needed and
messes with O_PATH
* tag 'io_uring-5.7-2020-05-08' of git://git.kernel.dk/linux-block:
io_uring: don't use 'fd' for openat/openat2/statx
splice: move f_mode checks to do_{splice,tee}()
io_uring: handle -EFAULT properly in io_uring_setup()
io_uring: fix mismatched finish_wait() calls in io_uring_cancel_files()
Linus Torvalds [Fri, 8 May 2020 17:36:56 +0000 (10:36 -0700)]
Merge tag 'scsi-fixes' of git://git./linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"Four minor fixes, all in drivers (qla2xxx, ibmvfc, ibmvscsi)"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: ibmvscsi: Fix WARN_ON during event pool release
scsi: ibmvfc: Don't send implicit logouts prior to NPIV login
scsi: qla2xxx: Delete all sessions before unregister local nvme port
scsi: qla2xxx: Fix hang when issuing nvme disconnect-all in NPIV