summaryrefslogtreecommitdiff
path: root/scripts
AgeCommit message (Collapse)Author
2020-10-12asm-generic/atomic: Add try_cmpxchg() fallbacksPeter Zijlstra
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) <peterz@infradead.org> Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Acked-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/159870621515.1229682.15506193091065001742.stgit@devnote2
2020-10-12scripts/dtc: Update to upstream version v1.6.0-31-gcbca977ea121Rob Herring
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 <robh@kernel.org>
2020-10-12Merge branch 'printk-rework' into for-linusPetr Mladek
2020-10-12scripts: coccicheck: Change default condition for parallelismSumera Priyadarsini
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 <sylphrenadin@gmail.com> Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
2020-10-12scripts: coccicheck: Add quotes to improve portabilitySumera Priyadarsini
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 <sylphrenadin@gmail.com> Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
2020-10-12scripts: remove namespace.plJacob Keller
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/20190129204319.15238-1-jacob.e.keller@intel.com/ [3] https://lore.kernel.org/netdev/20190828.154744.2058157956381129672.davem@davemloft.net/ [4] https://lore.kernel.org/netdev/20190827210928.576c5fef@cakuba.netronome.com/ Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-10-10coccinelle: api: kfree_sensitive: print memset positionDenis Efremov
Print memset() call position in addition to the kfree() position to ease issues identification. Signed-off-by: Denis Efremov <efremov@linux.com> Signed-off-by: Julia Lawall <julia.lawall@inria.fr>
2020-10-10builddeb: Add support for all required debian/rules targetsGuillem Jover
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 <guillem@hadrons.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-10-09builddeb: Enable rootless buildsGuillem Jover
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 <guillem@hadrons.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-10-09builddeb: Pass -n to gzip for reproducible packagesGuillem Jover
We should not be encoding the timestamp, otherwise we end up generating unreproducible files that cascade into unreproducible packages. Signed-off-by: Guillem Jover <guillem@hadrons.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-10-09kbuild: split the build log of kallsymsMasahiro Yamada
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 <masahiroy@kernel.org>
2020-10-09Merge branch 'kcsan' of ↵Ingo Molnar
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 <mingo@kernel.org>
2020-10-09Merge branch 'locking/urgent' into locking/core, to pick up fixesIngo Molnar
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2020-10-07locking/atomics: Check atomic-arch-fallback.h tooPaul Bolle
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 <pebolle@tiscali.nl> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Link: https://lkml.kernel.org/r/20201001202028.1048418-1-pebolle@tiscali.nl
2020-10-06Merge branch 'dt/linus' into dt/nextRob Herring
2020-10-05Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netDavid S. Miller
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 <davem@davemloft.net>
2020-10-03coccinelle: misc: add flexible_array.cocci scriptDenis Efremov
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 <keescook@chromium.org> Cc: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Denis Efremov <efremov@linux.com> Signed-off-by: Julia Lawall <julia.lawall@inria.fr>
2020-10-03scripts/spelling.txt: fix malformed entryEric Biggers
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 <ebiggers@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Link: https://lkml.kernel.org/r/20200930234359.255295-1-ebiggers@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-10-02scripts/spdxcheck.py: handle license identifiers in XML commentsLukas Bulwahn
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 <lukas.bulwahn@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-01coccinelle: api: add kvmalloc scriptDenis Efremov
Suggest kvmalloc, kvfree instead of opencoded patterns. Signed-off-by: Denis Efremov <efremov@linux.com> Signed-off-by: Julia Lawall <julia.lawall@inria.fr>
2020-09-29Merge tag 'devicetree-fixes-for-5.9-3' of ↵Linus Torvalds
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önig
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 <u.kleine-koenig@pengutronix.de> Signed-off-by: Rob Herring <robh@kernel.org>
2020-09-28bpf: Add bpf_snprintf_btf helperAlan Maguire
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 <alan.maguire@oracle.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/1601292670-1616-4-git-send-email-alan.maguire@oracle.com
2020-09-27scripts: coccicheck: Change default value for parallelismSumera Priyadarsini
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 <sylphrenadin@gmail.com> Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
2020-09-25scripts/setlocalversion: make git describe output more reliableRasmus Villemoes
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 <linux@rasmusvillemoes.dk> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-09-25scripts/kallsyms: skip ppc compiler stub *.long_branch.* / *.plt_branch.*Masahiro Yamada
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 <linux@roeck-us.net> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Tested-by: Guenter Roeck <linux@roeck-us.net>
2020-09-25kconfig: qconf: create QApplication after option checksMasahiro Yamada
'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 <masahiroy@kernel.org> Tested-by: Randy Dunlap <rdunlap@infradead.org>
2020-09-25kconfig: qconf: remove Y, M, N columnsMasahiro Yamada
There are so many ways to toggle bool / tristate options. I do not know how useful these columns are. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-09-25kconfig: qconf: remove ConfigView classMasahiro Yamada
Now that ConfigView only contains ConfigList, we can remove ConfigView and just use ConfigList. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-09-25kconfig: qconf: move setShowName/Range() to ConfigList from ConfigViewMasahiro Yamada
ConfigView::setShowName/Range() only get access to the 'list' member. Move them to the more relevant ConfigList class. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-09-25kconfig: qconf: remove ConfigLineEdit classMasahiro Yamada
Now that "int", "hex", "string" menus are edited in-place, this class is no longer needed. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-09-25kconfig: qconf: allow to edit "int", "hex", "string" menus in-placeMasahiro Yamada
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 <masahiroy@kernel.org>
2020-09-25kconfig: qconf: show data column all the timeMasahiro Yamada
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 <masahiroy@kernel.org>
2020-09-25kconfig: qconf: move ConfigView::updateList(All) to ConfigList classMasahiro Yamada
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 <masahiroy@kernel.org>
2020-09-25kconfig: qconf: remove unused ConfigItem::okRename()Masahiro Yamada
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 <masahiroy@kernel.org>
2020-09-25kconfig: qconf: update the intro message to match to the current codeMasahiro Yamada
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 <masahiroy@kernel.org> Tested-by: Randy Dunlap <rdunlap@infradead.org>
2020-09-25kconfig: qconf: reformat the intro messageMasahiro Yamada
The introduction message displayed by 'Help -> Introduction' does not look nice due to excessive new lines. Reformat the message. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Tested-by: Randy Dunlap <rdunlap@infradead.org>
2020-09-25kbuild: move CFLAGS_{KASAN,UBSAN,KCSAN} exports to relevant MakefilesMasahiro Yamada
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 <masahiroy@kernel.org> Acked-by: Marco Elver <elver@google.com>
2020-09-25kbuild: remove redundant CONFIG_KASAN check from scripts/Makefile.kasanMasahiro Yamada
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 <masahiroy@kernel.org> Acked-by: Marco Elver <elver@google.com>
2020-09-25kbuild: preprocess module linker scriptMasahiro Yamada
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 <masahiroy@kernel.org> Tested-by: Jessica Yu <jeyu@kernel.org> Acked-by: Will Deacon <will@kernel.org> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Palmer Dabbelt <palmerdabbelt@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Acked-by: Jessica Yu <jeyu@kernel.org>
2020-09-23Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextDavid S. Miller
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 <davem@davemloft.net>
2020-09-23bpf: Check CONFIG_BPF option for resolve_btfidsJiri Olsa
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 <andriin@fb.com> Signed-off-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Andrii Nakryiko <andriin@fb.com> Link: https://lore.kernel.org/bpf/20200923185735.3048198-1-jolsa@kernel.org
2020-09-22Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netDavid S. Miller
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 <davem@davemloft.net>
2020-09-22printk: move dictionary keys to dev_printk_infoJohn Ogness
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 <john.ogness@linutronix.de> Reviewed-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Petr Mladek <pmladek@suse.com> Link: https://lore.kernel.org/r/87mu1jl6ne.fsf@jogness.linutronix.de
2020-09-21coccinelle: misc: add excluded_middle.cocci scriptDenis Efremov
Check for !A || A && B condition. It's equivalent to !A || B. Signed-off-by: Denis Efremov <efremov@linux.com> Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
2020-09-20kconfig: qconf: revive help message in the info viewMasahiro Yamada
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 <mlevitsk@redhat.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-09-20kconfig: qconf: fix incomplete type 'struct gstr' warningMasahiro Yamada
"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 <masahiroy@kernel.org> Acked-by: Boris Kolpackov <boris@codesynthesis.com>
2020-09-19kconfig: qconf: use delete[] instead of delete to free array (again)Masahiro Yamada
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 <masahiroy@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2020-09-16kernel-doc: add support for ____cacheline_aligned attributeJonathan Cameron
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 <Jonathan.Cameron@huawei.com> Cc: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20200910185415.653139-1-jic23@kernel.org Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2020-09-15printk: ringbuffer: add finalization/extension supportJohn Ogness
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 <john.ogness@linutronix.de> Reviewed-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Petr Mladek <pmladek@suse.com> Link: https://lore.kernel.org/r/20200914123354.832-6-john.ogness@linutronix.de
generated by cgit (git 2.34.1) at 2025-07-18 15:16:16 +0000