aboutsummaryrefslogtreecommitdiff
path: root/scripts
AgeCommit message (Collapse)AuthorFilesLines
2020-10-12asm-generic/atomic: Add try_cmpxchg() fallbacksPeter Zijlstra2-13/+79
Only x86 provides try_cmpxchg() outside of the atomic_t interfaces, provide generic fallbacks to create this interface from the widely available cmpxchg() function. Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Masami Hiramatsu <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Acked-by: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/159870621515.1229682.15506193091065001742.stgit@devnote2
2020-10-12scripts/dtc: Update to upstream version v1.6.0-31-gcbca977ea121Rob Herring11-42/+58
This adds the following commits from upstream: cbca977ea121 checks: Allow PCI bridge child nodes without an address 73e0f143b73d libfdt: fdt_strerror(): Fix comparison warning 6c2be7d85315 libfdt: fdt_get_string(): Fix sequential write comparison warnings 82525f41d59e libfdt: libfdt_wip: Fix comparison warning fb1f65f15832 libfdt: fdt_create_with_flags(): Fix comparison warning f28aa271000b libfdt: fdt_move(): Fix comparison warnings 3d7c6f44195a libfdt: fdt_add_string_(): Fix comparison warning 10f682788c30 libfdt: fdt_node_offset_by_phandle(): Fix comparison warning 07158f4cf2a2 libfdt: overlay: Fix comparison warning ce9e1f25a7de libfdt: fdt_resize(): Fix comparison warning faa76fc10bc5 libfdt: fdt_splice_(): Fix comparison warning 54dca0985316 libfdt: fdt_get_string(): Fix comparison warnings f8e11e61624e libfdt: fdt_grab_space_(): Fix comparison warning 0c43d4d7bf5a libfdt: fdt_mem_rsv(): Fix comparison warnings 442ea3dd1579 libfdt: fdt_offset_ptr(): Fix comparison warnings ca19c3db2bf6 Makefile: Specify cflags for libyaml 7bb86f1c0956 libfdt: fix fdt_check_node_offset_ w/ VALID_INPUT 3d522abc7571 dtc: Include stdlib.h in util.h 808cdaaf524f dtc: Avoid UB when shifting 3e3138b4a956 libfdt: fix fdt_check_full buffer overrun Signed-off-by: Rob Herring <[email protected]>
2020-10-12Merge branch 'printk-rework' into for-linusPetr Mladek2-37/+117
2020-10-12scripts: coccicheck: Change default condition for parallelismSumera Priyadarsini1-1/+1
Currently, Coccinelle uses at most one thread per core by default in machines with more than 2 hyperthreads. However, for systems with only 4 hyperthreads, this does not improve performance. Modify coccicheck to use all available threads in machines with upto 4 hyperthreads. Signed-off-by: Sumera Priyadarsini <[email protected]> Signed-off-by: Julia Lawall <[email protected]>
2020-10-12scripts: coccicheck: Add quotes to improve portabilitySumera Priyadarsini1-1/+1
While fetching the number of threads per core with lscpu, the [:digit:] set is used for translation of digits from 0-9. However, using [:digit:] instead of "[:digit:]" does not seem to work uniformly for some shell types and configurations (such as zsh). Therefore, modify coccicheck to use double quotes around the [:digit:] set for uniformity and better portability. Signed-off-by: Sumera Priyadarsini <[email protected]> Signed-off-by: Julia Lawall <[email protected]>
2020-10-12scripts: remove namespace.plJacob Keller1-473/+0
namespace.pl is intended to help locate symbols which are defined but are not used externally. The goal is to avoid bloat of the namespace in the resulting kernel image. The script relies on object data, and only finds unused symbols for the configuration used to generate that object data. This results in a lot of false positive warnings such as symbols only used by a single architecture, or symbols which are used externally only under certain configurations. Running namespace.pl using allyesconfig, allmodconfig, and x86_64_defconfig yields the following results: * allmodconfig * 11122 unique symbol names with no external reference * 1194 symbols listed as multiply defined * 214 symbols it can't resolve * allyesconfig * 10997 unique symbol names with no external reference * 1194 symbols listed as multiply defined * 214 symbols it can't resolve * x86_64_defconfig * 5757 unique symbol names with no external reference * 528 symbols listed as multiply defined * 154 symbols it can't resolve The script also has no way to easily limit the scope of the checks to a given subset of the kernel, such as only checking for symbols defined within a module or subsystem. Discussion on public mailing lists seems to indicate that many view the tool output as suspect or not very useful (see discussions at [1] and [2] for further context). As described by Masahiro Yamada at [2], namespace.pl provides 3 types of checks: listing multiply defined symbols, resolving external symbols, and warnings about symbols with no reference. The first category of issues is easily caught by the linker as any set of multiply defined symbols should fail to link. The second category of issues is also caught by linking, as undefined symbols would cause issues. Even with modules, these types of issues where a module relies on an external symbol are caught by modpost. The remaining category of issues reported is the list of symbols with no external reference, and is the primary motivation of this script. However, it ought to be clear from the above examples that the output is difficult to sort through. Even allyesconfig has ~10000 entries. The current submit-checklist indicates that patches ought to go through namespacecheck and fix any new issues arising. But that itself presents problems. As described at [1], many cases of reports are due to configuration where a function is used externally by some configuration settings. Prominent maintainers appear to dislike changes modify code such that symbols become static based on CONFIG_* flags ([3], and [4]) One possible solution is to adjust the advice and indicate that we only care about the output of namespacecheck on allyesconfig or allmodconfig builds... However, given the discussion at [2], I suspect that few people are actively using this tool. It doesn't have a maintainer in the MAINTAINERS flie, and it produces so many warnings for unused symbols that it is difficult to use effectively. Thus, I propose we simply remove it. [1] https://lore.kernel.org/netdev/20200708164812.384ae8ea@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com/ [2] https://lore.kernel.org/lkml/[email protected]/ [3] https://lore.kernel.org/netdev/[email protected]/ [4] https://lore.kernel.org/netdev/[email protected]/ Signed-off-by: Jacob Keller <[email protected]> Acked-by: Randy Dunlap <[email protected]> Acked-by: Jakub Kicinski <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2020-10-10coccinelle: api: kfree_sensitive: print memset positionDenis Efremov1-4/+6
Print memset() call position in addition to the kfree() position to ease issues identification. Signed-off-by: Denis Efremov <[email protected]> Signed-off-by: Julia Lawall <[email protected]>
2020-10-10builddeb: Add support for all required debian/rules targetsGuillem Jover1-2/+6
These have been required by the Debian policy for a while, even though the tooling can detect and workaround their omission, but are a hard requirement when using rootless builds. [masahiro: The following Debian policy is particularly important for rootless builds: "Both binary-* targets should depend on the build target, or on the appropriate build-arch or build-indep target, so that the package is built if it has not been already." ] Signed-off-by: Guillem Jover <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2020-10-09builddeb: Enable rootless buildsGuillem Jover2-2/+8
This makes it possible to build the Debian packages without requiring (pseudo-)root privileges, when the build drivers support this mode of operation. See-Also: /usr/share/doc/dpkg/rootless-builds.txt.gz Signed-off-by: Guillem Jover <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2020-10-09builddeb: Pass -n to gzip for reproducible packagesGuillem Jover1-1/+1
We should not be encoding the timestamp, otherwise we end up generating unreproducible files that cascade into unreproducible packages. Signed-off-by: Guillem Jover <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2020-10-09kbuild: split the build log of kallsymsMasahiro Yamada1-10/+10
Currently, the build log shows KSYM + object name. Precisely speaking, kallsyms generates a .S file and then the compiler compiles it into a .o file. Split the build log into two. [Before] GEN modules.builtin LD .tmp_vmlinux.kallsyms1 KSYM .tmp_vmlinux.kallsyms1.o LD .tmp_vmlinux.kallsyms2 KSYM .tmp_vmlinux.kallsyms2.o LD vmlinux [After] GEN modules.builtin LD .tmp_vmlinux.kallsyms1 KSYMS .tmp_vmlinux.kallsyms1.S AS .tmp_vmlinux.kallsyms1.o LD .tmp_vmlinux.kallsyms2 KSYMS .tmp_vmlinux.kallsyms2.S AS .tmp_vmlinux.kallsyms2.o LD vmlinux Signed-off-by: Masahiro Yamada <[email protected]>
2020-10-09Merge branch 'kcsan' of ↵Ingo Molnar2-7/+16
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu into locking/core Pull KCSAN updates for v5.10 from Paul E. McKenney: - Improve kernel messages. - Be more permissive with bitops races under KCSAN_ASSUME_PLAIN_WRITES_ATOMIC=y. - Optimize debugfs stat counters. - Introduce the instrument_*read_write() annotations, to provide a finer description of certain ops - using KCSAN's compound instrumentation. Use them for atomic RNW and bitops, where appropriate. Doing this might find new races. (Depends on the compiler having tsan-compound-read-before-write=1 support.) - Support atomic built-ins, which will help certain architectures, such as s390. - Misc enhancements and smaller fixes. Signed-off-by: Ingo Molnar <[email protected]>
2020-10-09Merge branch 'locking/urgent' into locking/core, to pick up fixesIngo Molnar10-44/+68
Signed-off-by: Ingo Molnar <[email protected]>
2020-10-07locking/atomics: Check atomic-arch-fallback.h tooPaul Bolle1-0/+1
The sha1sum of include/linux/atomic-arch-fallback.h isn't checked by check-atomics.sh. It's not clear why it's skipped so let's check it too. Signed-off-by: Paul Bolle <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Mark Rutland <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-10-06Merge branch 'dt/linus' into dt/nextRob Herring1-1/+1
2020-10-05Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netDavid S. Miller3-3/+17
Rejecting non-native endian BTF overlapped with the addition of support for it. The rest were more simple overlapping changes, except the renesas ravb binding update, which had to follow a file move as well as a YAML conversion. Signed-off-by: David S. Miller <[email protected]>
2020-10-03coccinelle: misc: add flexible_array.cocci scriptDenis Efremov1-0/+88
One-element and zero-length arrays are deprecated [1]. Kernel code should always use "flexible array members" instead, except for existing uapi definitions. The script warns about one-element and zero-length arrays in structs. [1] commit 68e4cd17e218 ("docs: deprecated.rst: Add zero-length and one-element arrays") Cc: Kees Cook <[email protected]> Cc: Gustavo A. R. Silva <[email protected]> Signed-off-by: Denis Efremov <[email protected]> Signed-off-by: Julia Lawall <[email protected]>
2020-10-03scripts/spelling.txt: fix malformed entryEric Biggers1-1/+1
One of the entries has three fields "mistake||correction||correction" rather than the expected two fields "mistake||correction". Fix it. Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-10-02scripts/spdxcheck.py: handle license identifiers in XML commentsLukas Bulwahn1-0/+3
Commit cc9539e7884c ("media: docs: use the new SPDX header for GFDL-1.1 on *.svg files") adds SPDX-License-Identifiers enclosed in XML comments, i.e., <!-- ... -->, for svg files. Unfortunately, ./scripts/spdxcheck.py does not handle SPDX-License-Identifiers in XML comments, so it simply fails on checking these files with 'Invalid License ID: --'. Strip the XML comment ending simply by copying how it was done for comments in C. With that, ./scripts/spdxcheck.py handles the svg files properly. Signed-off-by: Lukas Bulwahn <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-10-01coccinelle: api: add kvmalloc scriptDenis Efremov1-0/+256
Suggest kvmalloc, kvfree instead of opencoded patterns. Signed-off-by: Denis Efremov <[email protected]> Signed-off-by: Julia Lawall <[email protected]>
2020-09-29Merge tag 'devicetree-fixes-for-5.9-3' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux Pull devicetree fixes from Rob Herring: - Fix handling of HOST_EXTRACFLAGS for dtc - Several warning fixes for DT bindings * tag 'devicetree-fixes-for-5.9-3' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: scripts/dtc: only append to HOST_EXTRACFLAGS instead of overwriting dt-bindings: Fix 'reg' size issues in zynqmp examples ARM: dts: bcm2835: Change firmware compatible from simple-bus to simple-mfd dt-bindings: leds: cznic,turris-omnia-leds: fix error in binding dt-bindings: crypto: sa2ul: fix a DT binding check warning
2020-09-29scripts/dtc: only append to HOST_EXTRACFLAGS instead of overwritingUwe Kleine-König1-1/+1
When building with $ HOST_EXTRACFLAGS=-g make the expectation is that host tools are built with debug informations. This however doesn't happen if the Makefile assigns a new value to the HOST_EXTRACFLAGS instead of appending to it. So use += instead of := for the first assignment. Fixes: e3fd9b5384f3 ("scripts/dtc: consolidate include path options in Makefile") Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Rob Herring <[email protected]>
2020-09-28bpf: Add bpf_snprintf_btf helperAlan Maguire1-0/+2
A helper is added to support tracing kernel type information in BPF using the BPF Type Format (BTF). Its signature is long bpf_snprintf_btf(char *str, u32 str_size, struct btf_ptr *ptr, u32 btf_ptr_size, u64 flags); struct btf_ptr * specifies - a pointer to the data to be traced - the BTF id of the type of data pointed to - a flags field is provided for future use; these flags are not to be confused with the BTF_F_* flags below that control how the btf_ptr is displayed; the flags member of the struct btf_ptr may be used to disambiguate types in kernel versus module BTF, etc; the main distinction is the flags relate to the type and information needed in identifying it; not how it is displayed. For example a BPF program with a struct sk_buff *skb could do the following: static struct btf_ptr b = { }; b.ptr = skb; b.type_id = __builtin_btf_type_id(struct sk_buff, 1); bpf_snprintf_btf(str, sizeof(str), &b, sizeof(b), 0, 0); Default output looks like this: (struct sk_buff){ .transport_header = (__u16)65535, .mac_header = (__u16)65535, .end = (sk_buff_data_t)192, .head = (unsigned char *)0x000000007524fd8b, .data = (unsigned char *)0x000000007524fd8b, .truesize = (unsigned int)768, .users = (refcount_t){ .refs = (atomic_t){ .counter = (int)1, }, }, } Flags modifying display are as follows: - BTF_F_COMPACT: no formatting around type information - BTF_F_NONAME: no struct/union member names/types - BTF_F_PTR_RAW: show raw (unobfuscated) pointer values; equivalent to %px. - BTF_F_ZERO: show zero-valued struct/union members; they are not displayed by default Signed-off-by: Alan Maguire <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2020-09-27scripts: coccicheck: Change default value for parallelismSumera Priyadarsini1-0/+5
By default, coccicheck utilizes all available threads to implement parallelisation. However, when all available threads are used, a decrease in performance is noted. The elapsed time is minimum when at most one thread per core is used. For example, on benchmarking the semantic patch kfree.cocci for usb/serial using hyperfine, the outputs obtained for J=5 and J=2 are 1.32 and 1.90 times faster than those for J=10 and J=9 respectively for two separate runs. For the larger drivers/staging directory, minimium elapsed time is obtained for J=3 which is 1.86 times faster than that for J=12. The optimal J value does not exceed 6 in any of the test runs. The benchmarks are run on a machine with 6 cores, with 2 threads per core, i.e, 12 hyperthreads in all. To improve performance, modify coccicheck to use at most only one thread per core by default. Signed-off-by: Sumera Priyadarsini <[email protected]> Signed-off-by: Julia Lawall <[email protected]>
2020-09-25scripts/setlocalversion: make git describe output more reliableRasmus Villemoes1-5/+16
When building for an embedded target using Yocto, we're sometimes observing that the version string that gets built into vmlinux (and thus what uname -a reports) differs from the path under /lib/modules/ where modules get installed in the rootfs, but only in the length of the -gabc123def suffix. Hence modprobe always fails. The problem is that Yocto has the concept of "sstate" (shared state), which allows different developers/buildbots/etc. to share build artifacts, based on a hash of all the metadata that went into building that artifact - and that metadata includes all dependencies (e.g. the compiler used etc.). That normally works quite well; usually a clean build (without using any sstate cache) done by one developer ends up being binary identical to a build done on another host. However, one thing that can cause two developers to end up with different builds [and thus make one's vmlinux package incompatible with the other's kernel-dev package], which is not captured by the metadata hashing, is this `git describe`: The output of that can be affected by (1) git version: before 2.11 git defaulted to a minimum of 7, since 2.11 (git.git commit e6c587) the default is dynamic based on the number of objects in the repo (2) hence even if both run the same git version, the output can differ based on how many remotes are being tracked (or just lots of local development branches or plain old garbage) (3) and of course somebody could have a core.abbrev config setting in ~/.gitconfig So in order to avoid `uname -a` output relying on such random details of the build environment which are rather hard to ensure are consistent between developers and buildbots, make sure the abbreviated sha1 always consists of exactly 12 hex characters. That is consistent with the current rule for -stable patches, and is almost always enough to identify the head commit unambigously - in the few cases where it does not, the v5.4.3-00021- prefix would certainly nail it down. Signed-off-by: Rasmus Villemoes <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2020-09-25scripts/kallsyms: skip ppc compiler stub *.long_branch.* / *.plt_branch.*Masahiro Yamada1-1/+15
PowerPC allmodconfig often fails to build as follows: LD .tmp_vmlinux.kallsyms1 KSYM .tmp_vmlinux.kallsyms1.o LD .tmp_vmlinux.kallsyms2 KSYM .tmp_vmlinux.kallsyms2.o LD .tmp_vmlinux.kallsyms3 KSYM .tmp_vmlinux.kallsyms3.o LD vmlinux SORTTAB vmlinux SYSMAP System.map Inconsistent kallsyms data Try make KALLSYMS_EXTRA_PASS=1 as a workaround make[2]: *** [../Makefile:1162: vmlinux] Error 1 Setting KALLSYMS_EXTRA_PASS=1 does not help. This is caused by the compiler inserting stubs such as *.long_branch.* and *.plt_branch.* $ powerpc-linux-nm -n .tmp_vmlinux.kallsyms2 [ snip ] c00000000210c010 t 00000075.plt_branch.da9:19 c00000000210c020 t 00000075.plt_branch.1677:5 c00000000210c030 t 00000075.long_branch.memmove c00000000210c034 t 00000075.plt_branch.9e0:5 c00000000210c044 t 00000075.plt_branch.free_initrd_mem ... Actually, the problem mentioned in scripts/link-vmlinux.sh comments; "In theory it's possible this results in even more stubs, but unlikely" is happening here, and ends up with another kallsyms step required. scripts/kallsyms.c already ignores various compiler stubs. Let's do similar to make kallsysms for PowerPC always succeed in 2 steps. Reported-by: Guenter Roeck <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> Tested-by: Guenter Roeck <[email protected]>
2020-09-25kconfig: qconf: create QApplication after option checksMasahiro Yamada1-1/+2
'scripts/kconfig/qconf -h' just calls usage() and exits, with QApplication unused. There is no need to construct QApplication so early. Do it after the parse stage. Signed-off-by: Masahiro Yamada <[email protected]> Tested-by: Randy Dunlap <[email protected]>
2020-09-25kconfig: qconf: remove Y, M, N columnsMasahiro Yamada2-61/+4
There are so many ways to toggle bool / tristate options. I do not know how useful these columns are. Signed-off-by: Masahiro Yamada <[email protected]>
2020-09-25kconfig: qconf: remove ConfigView classMasahiro Yamada2-47/+17
Now that ConfigView only contains ConfigList, we can remove ConfigView and just use ConfigList. Signed-off-by: Masahiro Yamada <[email protected]>
2020-09-25kconfig: qconf: move setShowName/Range() to ConfigList from ConfigViewMasahiro Yamada2-33/+32
ConfigView::setShowName/Range() only get access to the 'list' member. Move them to the more relevant ConfigList class. Signed-off-by: Masahiro Yamada <[email protected]>
2020-09-25kconfig: qconf: remove ConfigLineEdit classMasahiro Yamada2-57/+0
Now that "int", "hex", "string" menus are edited in-place, this class is no longer needed. Signed-off-by: Masahiro Yamada <[email protected]>
2020-09-25kconfig: qconf: allow to edit "int", "hex", "string" menus in-placeMasahiro Yamada2-17/+91
Previously, when you double-clicked the "int", "hex", or "string" menus, a line-edit gadget showed up to allow you to input the value, which looked clumsy. Also, it was buggy; the editor opened even if the config option was not editable. For example, just try to double-click CC_VERSION_TEXT, which has no prompt. This commit sub-classes QStyleItemDelegate to allow users to edit "int", "hex", "string" menus in-place. Just double-click (or press the F2 key) in the data column. Then, an editor widget is placed on top of the item view. The two methods are overridden: createEditor - process only when the data column is being accessed and the menu is visible. Otherwise, return nullptr to disallow editing. setModelData - take the new data from the editor, and set it to the addressed symbol. If it was successful, update all the list windows. Otherwise, (the reason for the failure is possibly the input data was out of range), set the old value back to the editor. Signed-off-by: Masahiro Yamada <[email protected]>
2020-09-25kconfig: qconf: show data column all the timeMasahiro Yamada2-32/+2
The next commit will allow users to edit "int", "hex", "string" menus in-place from the data column. The data column should be always displayed. Signed-off-by: Masahiro Yamada <[email protected]>
2020-09-25kconfig: qconf: move ConfigView::updateList(All) to ConfigList classMasahiro Yamada2-42/+39
ConfigView::updateList() iterates over all views, and then calls updateList() against for its ConfigList instance. This means there is no point to implement it in the ConfigView class. Move and rename as follows: ConfigView::updateList() -> ConfigList::updateListForAll() ConfigView::updateListAll() -> ConfigList::updateListAllForAll() I used QList to contain all ConfigList instances. Signed-off-by: Masahiro Yamada <[email protected]>
2020-09-25kconfig: qconf: remove unused ConfigItem::okRename()Masahiro Yamada2-9/+0
Commit 76538660fb08 ("Port xconfig to Qt5 - Remove custom ListView classes.") removed the original implementation, where ConfigItem::okRename() overrode Q3ListViewItem::okRename(). Commit 59e564408f88 ("Port xconfig to Qt5 - Put back some of the old implementation.") restored the empty stub, but it seems useless. Signed-off-by: Masahiro Yamada <[email protected]>
2020-09-25kconfig: qconf: update the intro message to match to the current codeMasahiro Yamada1-4/+4
I do not think "Although there is no cross reference yet ..." is valid any longer. The cross reference is supported via hyperlinks enabled by the "show Debug Info" option. Update the message. Signed-off-by: Masahiro Yamada <[email protected]> Tested-by: Randy Dunlap <[email protected]>
2020-09-25kconfig: qconf: reformat the intro messageMasahiro Yamada1-11/+18
The introduction message displayed by 'Help -> Introduction' does not look nice due to excessive new lines. Reformat the message. Signed-off-by: Masahiro Yamada <[email protected]> Tested-by: Randy Dunlap <[email protected]>
2020-09-25kbuild: move CFLAGS_{KASAN,UBSAN,KCSAN} exports to relevant MakefilesMasahiro Yamada3-1/+6
Move CFLAGS_KASAN*, CFLAGS_UBSAN, CFLAGS_KCSAN to Makefile.kasan, Makefile.ubsan, Makefile.kcsan, respectively. This commit also avoids the same -fsanitize=* flags being added to CFLAGS_UBSAN multiple times. Prior to this commit, the ubsan flags were appended by the '+=' operator, without any initialization. Some build targets such as 'make bindeb-pkg' recurses to the top Makefile, and ended up with adding the same flags to CFLAGS_UBSAN twice. Clear CFLAGS_UBSAN with ':=' to make it a simply expanded variable. This is better than a recursively expanded variable, which evaluates $(call cc-option, ...) multiple times before Kbuild starts descending to subdirectories. Signed-off-by: Masahiro Yamada <[email protected]> Acked-by: Marco Elver <[email protected]>
2020-09-25kbuild: remove redundant CONFIG_KASAN check from scripts/Makefile.kasanMasahiro Yamada1-2/+0
Since commit e0fe0bbe57b8 ("kbuild: include scripts/Makefile.* only when relevant CONFIG is enabled"), this file is included only when CONFIG_KASAN=y. This ifdef is redundant. Signed-off-by: Masahiro Yamada <[email protected]> Acked-by: Marco Elver <[email protected]>
2020-09-25kbuild: preprocess module linker scriptMasahiro Yamada5-4/+10
There was a request to preprocess the module linker script like we do for the vmlinux one. (https://lkml.org/lkml/2020/8/21/512) The difference between vmlinux.lds and module.lds is that the latter is needed for external module builds, thus must be cleaned up by 'make mrproper' instead of 'make clean'. Also, it must be created by 'make modules_prepare'. You cannot put it in arch/$(SRCARCH)/kernel/, which is cleaned up by 'make clean'. I moved arch/$(SRCARCH)/kernel/module.lds to arch/$(SRCARCH)/include/asm/module.lds.h, which is included from scripts/module.lds.S. scripts/module.lds is fine because 'make clean' keeps all the build artifacts under scripts/. You can add arch-specific sections in <asm/module.lds.h>. Signed-off-by: Masahiro Yamada <[email protected]> Tested-by: Jessica Yu <[email protected]> Acked-by: Will Deacon <[email protected]> Acked-by: Geert Uytterhoeven <[email protected]> Acked-by: Palmer Dabbelt <[email protected]> Reviewed-by: Kees Cook <[email protected]> Acked-by: Jessica Yu <[email protected]>
2020-09-23Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextDavid S. Miller1-3/+3
Alexei Starovoitov says: ==================== pull-request: bpf-next 2020-09-23 The following pull-request contains BPF updates for your *net-next* tree. We've added 95 non-merge commits during the last 22 day(s) which contain a total of 124 files changed, 4211 insertions(+), 2040 deletions(-). The main changes are: 1) Full multi function support in libbpf, from Andrii. 2) Refactoring of function argument checks, from Lorenz. 3) Make bpf_tail_call compatible with functions (subprograms), from Maciej. 4) Program metadata support, from YiFei. 5) bpf iterator optimizations, from Yonghong. ==================== Signed-off-by: David S. Miller <[email protected]>
2020-09-23bpf: Check CONFIG_BPF option for resolve_btfidsJiri Olsa1-3/+3
Currently all the resolve_btfids 'users' are under CONFIG_BPF code, so if we have CONFIG_BPF disabled, resolve_btfids will fail, because there's no data to resolve. Disabling resolve_btfids if there's CONFIG_BPF disabled, so we won't fail such builds. Suggested-by: Andrii Nakryiko <[email protected]> Signed-off-by: Jiri Olsa <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Acked-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2020-09-22Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netDavid S. Miller5-39/+47
Two minor conflicts: 1) net/ipv4/route.c, adding a new local variable while moving another local variable and removing it's initial assignment. 2) drivers/net/dsa/microchip/ksz9477.c, overlapping changes. One pretty prints the port mode differently, whilst another changes the driver to try and obtain the port mode from the port node rather than the switch node. Signed-off-by: David S. Miller <[email protected]>
2020-09-22printk: move dictionary keys to dev_printk_infoJohn Ogness1-5/+11
Dictionaries are only used for SUBSYSTEM and DEVICE properties. The current implementation stores the property names each time they are used. This requires more space than otherwise necessary. Also, because the dictionary entries are currently considered optional, it cannot be relied upon that they are always available, even if the writer wanted to store them. These issues will increase should new dictionary properties be introduced. Rather than storing the subsystem and device properties in the dict ring, introduce a struct dev_printk_info with separate fields to store only the property values. Embed this struct within the struct printk_info to provide guaranteed availability. Signed-off-by: John Ogness <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Signed-off-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-09-21coccinelle: misc: add excluded_middle.cocci scriptDenis Efremov1-0/+39
Check for !A || A && B condition. It's equivalent to !A || B. Signed-off-by: Denis Efremov <[email protected]> Signed-off-by: Julia Lawall <[email protected]>
2020-09-20kconfig: qconf: revive help message in the info viewMasahiro Yamada1-3/+8
Since commit 68fd110b3e7e ("kconfig: qconf: remove redundant help in the info view"), the help message is no longer displayed. I intended to drop duplicated "Symbol:", "Type:", but precious info about help and reverse dependencies was lost too. Revive it now. "defined at" is contained in menu_get_ext_help(), so I made sure to not display it twice. Fixes: 68fd110b3e7e ("kconfig: qconf: remove redundant help in the info view") Reported-by: Maxim Levitsky <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2020-09-20kconfig: qconf: fix incomplete type 'struct gstr' warningMasahiro Yamada2-31/+30
"make HOSTCXX=clang++ xconfig" reports the following: HOSTCXX scripts/kconfig/qconf.o In file included from scripts/kconfig/qconf.cc:23: In file included from scripts/kconfig/lkc.h:15: scripts/kconfig/lkc_proto.h:26:13: warning: 'get_relations_str' has C-linkage specified, but returns incomplete type 'struct gstr' which could be incompatible with C [-Wreturn-type-c-linkage] struct gstr get_relations_str(struct symbol **sym_arr, struct list_head *head); ^ Currently, get_relations_str() is declared before the struct gstr definition. Move all declarations of menu.c functions below. BTW, some are declared in lkc.h and some in lkc_proto.h, but the difference is unclear. I guess some refactoring is needed. Signed-off-by: Masahiro Yamada <[email protected]> Acked-by: Boris Kolpackov <[email protected]>
2020-09-19kconfig: qconf: use delete[] instead of delete to free array (again)Masahiro Yamada1-1/+1
Commit c9b09a9249e6 ("kconfig: qconf: use delete[] instead of delete to free array") fixed two lines, but there is one more. (cppcheck does not report it for some reason...) This was detected by Clang. "make HOSTCXX=clang++ xconfig" reports the following: scripts/kconfig/qconf.cc:1279:2: warning: 'delete' applied to a pointer that was allocated with 'new[]'; did you mean 'delete[]'? [-Wmismatched-new-delete] delete data; ^ [] scripts/kconfig/qconf.cc:1239:15: note: allocated with 'new[]' here char *data = new char[count + 1]; ^ Fixes: c4f7398bee9c ("kconfig: qconf: make debug links work again") Fixes: c9b09a9249e6 ("kconfig: qconf: use delete[] instead of delete to free array") Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]>
2020-09-16kernel-doc: add support for ____cacheline_aligned attributeJonathan Cameron1-1/+2
Subroutine dump_struct uses type attributes to check if the struct syntax is valid. Then, it removes all attributes before using it for output. `____cacheline_aligned` is an attribute that is not included in both steps. Add it, since it is used by kernel structs. Based on previous patch to add ____cacheline_aligned_in_smp. Motivated by patches to reorder this attribute to before the variable name. Whilst we could do that in all cases, that would be a massive change and it is more common in the kernel to place this particular attribute after the variable name. A quick grep suggests approximately 400 instances of which 341 have this attribute just before a semicolon and hence after the variable name. Signed-off-by: Jonathan Cameron <[email protected]> Cc: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Corbet <[email protected]>
2020-09-15printk: ringbuffer: add finalization/extension supportJohn Ogness1-1/+2
Add support for extending the newest data block. For this, introduce a new finalization state (desc_finalized) denoting a committed descriptor that cannot be extended. Until a record is finalized, a writer can reopen that record to append new data. Reopening a record means transitioning from the desc_committed state back to the desc_reserved state. A writer can explicitly finalize a record if there is no intention of extending it. Also, records are automatically finalized when a new record is reserved. This relieves writers of needing to explicitly finalize while also making such records available to readers sooner. (Readers can only traverse finalized records.) Four new memory barrier pairs are introduced. Two of them are insignificant additions (data_realloc:A/desc_read:D and data_realloc:A/data_push_tail:B) because they are alternate path memory barriers that exactly match the purpose, pairing, and context of the two existing memory barrier pairs they provide an alternate path for. The other two new memory barrier pairs are significant additions: desc_reopen_last:A / _prb_commit:B - When reopening a descriptor, ensure the state transitions back to desc_reserved before fully trusting the descriptor data. _prb_commit:B / desc_reserve:D - When committing a descriptor, ensure the state transitions to desc_committed before checking the head ID to see if the descriptor needs to be finalized. Signed-off-by: John Ogness <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Signed-off-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/[email protected]