Project 'drm/intel' was moved to 'drm/i915/kernel'. Please update any links and bookmarks that may still have the old path.
- Dec 24, 2021
-
-
Heiko Carstens authored
Commit 85bf17b2 ("recordmcount.pl: look for jgnop instruction as well as bcrl on s390") added a new alternative mnemonic for the existing brcl instruction. This is required for the combination old gcc version (pre 9.0) and binutils since version 2.37. However at the same time this commit introduced a typo, replacing brcl with bcrl. As a result no mcount locations are detected anymore with old gcc versions (pre 9.0) and binutils before version 2.37. Fix this by using the correct mnemonic again. Reported-by:
Miroslav Benes <mbenes@suse.cz> Cc: Jerome Marchand <jmarchan@redhat.com> Cc: <stable@vger.kernel.org> Fixes: 85bf17b2 ("recordmcount.pl: look for jgnop instruction as well as bcrl on s390") Link: https://lore.kernel.org/r/alpine.LSU.2.21.2112230949520.19849@pobox.suse.cz Signed-off-by:
Heiko Carstens <hca@linux.ibm.com>
-
- Dec 12, 2021
-
-
On s390, recordmcount.pl is looking for "bcrl 0,<xxx>" instructions in the objdump -d outpout. However since binutils 2.37, objdump -d display "jgnop <xxx>" for the same instruction. Update the mcount_regex so that it accepts both. Signed-off-by:
Jerome Marchand <jmarchan@redhat.com> Reviewed-by:
Miroslav Benes <mbenes@suse.cz> Acked-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20211210093827.1623286-1-jmarchan@redhat.com Signed-off-by:
Heiko Carstens <hca@linux.ibm.com>
-
- Nov 10, 2021
-
-
Masahiro Yamada authored
As commit 7ae4a78d ("ARM: 8969/1: decompressor: simplify libfdt builds") stated, copying source files during the build time may not end up with as clean code as expected. Do similar for mips to clean up the Makefile and .gitignore. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Tested-by:
Paul Cercueil <paul@crapouillou.net> Signed-off-by:
Thomas Bogendoerfer <tsbogend@alpha.franken.de>
-
- Nov 09, 2021
-
-
Douglas Anderson authored
This is related to two previous changes. Commit dfe4529e ("scripts/gdb: find vmlinux where it was before") and commit da036ae1 ("scripts/gdb: handle split debug"). Although Chrome OS has been using the debug suffix for modules for a while, it has just recently started using it for vmlinux as well. That means we've now got to improve the detection of "vmlinux" to also handle that it might end with ".debug". Link: https://lkml.kernel.org/r/20211028151120.v2.1.Ie6bd5a232f770acd8c9ffae487a02170bad3e963@changeid Signed-off-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Cc: Jan Kiszka <jan.kiszka@siemens.com> Cc: Kieran Bingham <kbingham@kernel.org> Cc: Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Peter Ujfalusi authored
The standard location of dictionary.txt is under codespell's package, on my machine atm (codespell 2.1, Artix Linux): /usr/lib/python3.9/site-packages/codespell_lib/data/dictionary.txt Since we enable the codespell by default for SOF I have constant: No codespell typos will be found - file '/usr/share/codespell/dictionary.txt': No such file or directory The patch proposes to try to fix up the path following the recommendation found here: https://github.com/codespell-project/codespell/issues/1540 Link: https://lkml.kernel.org/r/29e25d1364c8ad7f7657cc0660f60c568074d438.camel@perches.com Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Acked-by:
Joe Perches <joe@perches.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Joe Perches authored
The EXPORT_SYMBOL test expects a single argument but definitions of EXPORT_SYMBOL_NS have multiple arguments. Update the test to extract only the first argument from any EXPORT_SYMBOL related definition. Link: https://lkml.kernel.org/r/9e8f251b42e405f460f26a23ba9b33ef45a94adc.camel@perches.com Signed-off-by:
Joe Perches <joe@perches.com> Reported-by:
Ian Pilcher <arequipeno@gmail.com> Cc: Dwaipayan Ray <dwaipayanray1@gmail.com> Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Rikard Falkeborn authored
Add a couple of commonly used (>50 instances) sound ops structs that are typically const. Link: https://lkml.kernel.org/r/20210922211042.38017-1-rikard.falkeborn@gmail.com Signed-off-by:
Rikard Falkeborn <rikard.falkeborn@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Takashi Iwai <tiwai@suse.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Thomas Weißschuh authored
This allows to selectively autoload drivers for ISH devices. Currently all ISH drivers are loaded for all systems having any ISH device. Signed-off-by:
Thomas Weißschuh <linux@weissschuh.net> Acked-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Acked-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz>
-
- Nov 06, 2021
-
-
Kees Cook authored
GCC and Clang can use the "alloc_size" attribute to better inform the results of __builtin_object_size() (for compile-time constant values). Clang can additionally use alloc_size to inform the results of __builtin_dynamic_object_size() (for run-time values). Because GCC sees the frequent use of struct_size() as an allocator size argument, and notices it can return SIZE_MAX (the overflow indication), it complains about these call sites overflowing (since SIZE_MAX is greater than the default -Walloc-size-larger-than=PTRDIFF_MAX). This isn't helpful since we already know a SIZE_MAX will be caught at run-time (this was an intentional design). To deal with this, we must disable this check as it is both a false positive and redundant. (Clang does not have this warning option.) Unfortunately, just checking the -Wno-alloc-size-larger-than is not sufficient to make the __alloc_size attribute behave correctly under older GCC versions. The attribute itself must be disabled in those situations too, as there appears to be no way to reliably silence the SIZE_MAX constant expression cases for GCC versions less than 9.1: In file included from ./include/linux/resource_ext.h:11, from ./include/linux/pci.h:40, from drivers/net/ethernet/intel/ixgbe/ixgbe.h:9, from drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c:4: In function 'kmalloc_node', inlined from 'ixgbe_alloc_q_vector' at ./include/linux/slab.h:743:9: ./include/linux/slab.h:618:9: error: argument 1 value '18446744073709551615' exceeds maximum object size 9223372036854775807 [-Werror=alloc-size-larger-than=] return __kmalloc_node(size, flags, node); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/linux/slab.h: In function 'ixgbe_alloc_q_vector': ./include/linux/slab.h:455:7: note: in a call to allocation function '__kmalloc_node' declared here void *__kmalloc_node(size_t size, gfp_t flags, int node) __assume_slab_alignment __malloc; ^~~~~~~~~~~~~~ Specifically: '-Wno-alloc-size-larger-than' is not correctly handled by GCC < 9.1 https://godbolt.org/z/hqsfG7q84 (doesn't disable) https://godbolt.org/z/P9jdrPTYh (doesn't admit to not knowing about option) https://godbolt.org/z/465TPMWKb (only warns when other warnings appear) '-Walloc-size-larger-than=18446744073709551615' is not handled by GCC < 8.2 https://godbolt.org/z/73hh1EPxz (ignores numeric value) Since anything marked with __alloc_size would also qualify for marking with __malloc, just include __malloc along with it to avoid redundant markings. (Suggested by Linus Torvalds.) Finally, make sure checkpatch.pl doesn't get confused about finding the __alloc_size attribute on functions. (Thanks to Joe Perches.) Link: https://lkml.kernel.org/r/20210930222704.2631604-3-keescook@chromium.org Signed-off-by:
Kees Cook <keescook@chromium.org> Tested-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Andy Whitcroft <apw@canonical.com> Cc: Christoph Lameter <cl@linux.com> Cc: Daniel Micay <danielmicay@gmail.com> Cc: David Rientjes <rientjes@google.com> Cc: Dennis Zhou <dennis@kernel.org> Cc: Dwaipayan Ray <dwaipayanray1@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com> Cc: Pekka Enberg <penberg@kernel.org> Cc: Tejun Heo <tj@kernel.org> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Alexandre Bounine <alex.bou9@gmail.com> Cc: Gustavo A. R. Silva <gustavoars@kernel.org> Cc: Ira Weiny <ira.weiny@intel.com> Cc: Jing Xiangfeng <jingxiangfeng@huawei.com> Cc: John Hubbard <jhubbard@nvidia.com> Cc: kernel test robot <lkp@intel.com> Cc: Matt Porter <mporter@kernel.crashing.org> Cc: Miguel Ojeda <ojeda@kernel.org> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Souptick Joarder <jrdr.linux@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
weidonghui authored
If opps.file is in DOS format, faulting instruction cannot be printed: / # ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- / # ./scripts/decodecode < oops.file [ 0.734345] Code: d0002881 912f9c21 94067e68 d2800001 (b900003f) aarch64-linux-gnu-strip: '/tmp/tmp.5Y9eybnnSi.o': No such file aarch64-linux-gnu-objdump: '/tmp/tmp.5Y9eybnnSi.o': No such file All code ======== 0: d0002881 adrp x1, 0x512000 4: 912f9c21 add x1, x1, #0xbe7 8: 94067e68 bl 0x19f9a8 c: d2800001 mov x1, #0x0 // #0 10: b900003f str wzr, [x1] Code starting with the faulting instruction =========================================== Background: The compilation environment is Ubuntu, and the test environment is Windows. Most logs are generated in the Windows environment. In this way, CR (carriage return) will inevitably appear, which will affect the use of decodecode in the Ubuntu environment. The repaired effect is as follows: / # ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- / # ./scripts/decodecode < oops.file [ 0.734345] Code: d0002881 912f9c21 94067e68 d2800001 (b900003f) All code ======== 0: d0002881 adrp x1, 0x512000 4: 912f9c21 add x1, x1, #0xbe7 8: 94067e68 bl 0x19f9a8 c: d2800001 mov x1, #0x0 // #0 10:* b900003f str wzr, [x1] <-- trapping instruction Code starting with the faulting instruction =========================================== 0: b900003f str wzr, [x1] Link: https://lkml.kernel.org/r/20211008064712.926-1-weidonghui@allwinnertech.com Signed-off-by:
weidonghui <weidonghui@allwinnertech.com> Acked-by:
Borislav Petkov <bp@suse.de> Cc: Marc Zyngier <maz@misterjones.org> Cc: Will Deacon <will@kernel.org> Cc: Rabin Vincent <rabin@rab.in> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Sven Eckelmann authored
If both "mistake" version and "correction" version are the same, a warning message is created by checkpatch which is impossible to fix. But it was noticed that Colan Ian King created a commit e6c0a088 ("ALSA: aloop: Fix spelling mistake "synchronization" -> "synchronization"") which suggests that this spelling mistake was fixed by replacing the word "synchronization" with itself. But the actual diff shows that the mistake in the code was "sychronization". It is rather likely that the "mistake" in spelling.txt should have been the latter. Link: https://lkml.kernel.org/r/20210926065529.6880-1-sven@narfation.org Fixes: 2e74c9433ba8 ("scripts/spelling.txt: add more spellings to spelling.txt") Signed-off-by:
Sven Eckelmann <sven@narfation.org> Reviewed-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Colin Ian King authored
Some of the more common spelling mistakes and typos that I've found while fixing up spelling mistakes in the kernel in the past few months. Link: https://lkml.kernel.org/r/20210907072941.7033-1-colin.king@canonical.com Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Nov 02, 2021
-
-
Jiri Olsa authored
Using new PAHOLE_FLAGS variable to pass extra arguments to pahole for both vmlinux and modules BTF data generation. Adding new scripts/pahole-flags.sh script that detect and prints pahole options. [ fixed issues found by kernel test robot ] Signed-off-by:
Jiri Olsa <jolsa@kernel.org> Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Acked-by:
Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211029125729.70002-1-jolsa@kernel.org
-
- Nov 01, 2021
-
-
Randy Dunlap authored
Support the DECLARE_PHY_INTERFACE_MASK() macro that is used to declare a bitmap by converting the macro to DECLARE_BITMAP(), as has been done for the __ETHTOOL_DECLARE_LINK_MODE_MASK() macro. This fixes a 'make htmldocs' warning: include/linux/phylink.h:82: warning: Function parameter or member 'DECLARE_PHY_INTERFACE_MASK(supported_interfaces' not described in 'phylink_config' that was introduced by commit 38c310eb ("net: phylink: add MAC phy_interface_t bitmap") Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Cc: Russell King (Oracle) <linux@armlinux.org.uk> Link: https://lore.kernel.org/r/45934225-7942-4326-f883-a15378939db9@infradead.org Signed-off-by:
Jonathan Corbet <corbet@lwn.net>
-
- Oct 29, 2021
-
-
Rob Herring authored
This adds the following commits from upstream: 0a3a9d3449c8 checks: Add an interrupt-map check 8fd24744e361 checks: Ensure '#interrupt-cells' only exists in interrupt providers d8d1a9a77863 checks: Drop interrupt provider '#address-cells' check 52a16fd72824 checks: Make interrupt_provider check dependent on interrupts_extended_is_cell 37fd700685da treesource: Maintain phandle label/path on output e33ce1d6a8c7 flattree: Use '\n', not ';' to separate asm pseudo-ops d24cc189dca6 asm: Use assembler macros instead of cpp macros ff3a30c115ad asm: Use .asciz and .ascii instead of .string 5eb5927d81ee fdtdump: fix -Werror=int-to-pointer-cast 0869f8269161 libfdt: Add ALIGNMENT error string 69595a167f06 checks: Fix bus-range check 72d09e2682a4 Makefile: add -Wsign-compare to warning options b587787ef388 checks: Fix signedness comparisons warnings 69bed6c2418f dtc: Wrap phandle validity check 910221185560 fdtget: Fix signedness comparisons warnings d966f08fcd21 tests: Fix signedness comparisons warnings ecfb438c07fa dtc: Fix signedness comparisons warnings: pointer diff 5bec74a6d135 dtc: Fix signedness comparisons warnings: reservednum 24e7f511fd4a fdtdump: Fix signedness comparisons warnings b6910bec1161 Bump version to v1.6.1 21d61d18f968 Fix CID 1461557 4c2ef8f4d14c checks: Introduce is_multiple_of() e59ca36fb70e Make handling of cpp line information more tolerant 0c3fd9b6aceb checks: Drop interrupt_cells_is_cell check 6b3081abc4ac checks: Add check_is_cell() for all phandle+arg properties 2dffc192a77f yamltree: Remove marker ordering dependency 61e513439e40 pylibfdt: Rework "avoid unused variable warning" lines c8bddd106095 tests: add a positive gpio test case ad4abfadb687 checks: replace strstr and strrchr with strends 09c6a6e88718 dtc.h: add strends for suffix matching 9bb9b8d0b4a0 checks: tigthen up nr-gpios prop exception b07b62ee3342 libfdt: Add FDT alignment check to fdt_check_header() a2def5479950 libfdt: Check that the root-node name is empty 4ca61f84dc21 libfdt: Check that there is only one root node 34d708249a91 dtc: Remove -O dtbo support 8e7ff260f755 libfdt: Fix a possible "unchecked return value" warning 88875268c05c checks: Warn on node-name and property name being the same 9d2279e7e6ee checks: Change node-name check to match devicetree spec f527c867a8c6 util: limit gnu_printf format attribute to gcc >= 4.4.0 Reviewed-by:
Frank Rowand <frank.rowand@sony.com> Tested-by:
Frank Rowand <frank.rowand@sony.com> Signed-off-by:
Rob Herring <robh@kernel.org>
-
- Oct 26, 2021
-
-
Mauro Carvalho Chehab authored
tools/testing/selftests/bpf/test_bpftool_synctypes.py use relative patches on the top of BPFTOOL_DIR: BPFTOOL_DIR = os.path.join(LINUX_ROOT, 'tools/bpf/bpftool') Change the script to automatically convert: testing/selftests/bpf -> bpf/bpftool In order to properly check the files used by such script. Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/49b765cbac6ccd22d627573154806ec9389d60f0.1634629094.git.mchehab+huawei@kernel.org Signed-off-by:
Jonathan Corbet <corbet@lwn.net>
-
Mauro Carvalho Chehab authored
There's a warning there from a .gitignore file: tools/perf/.gitignore: Documentation/doc.dep This is not really a cross-reference type of warning, so no need to report it. In a matter of fact, it doesn't make sense at all to even parse hidden files, as some text editors may create such files for their own usage. So, just ignore everything that matches this pattern: /\.* Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/dd0125a931b4fecf8fab6be8aa527faa18f78e43.1634629094.git.mchehab+huawei@kernel.org Signed-off-by:
Jonathan Corbet <corbet@lwn.net>
-
- Oct 24, 2021
-
-
Masahiro Yamada authored
To slim down the top Makefile, split out the code block surrounded by ifdef CONFIG_DEBUG_INFO ... endif. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Reviewed-by:
Nick Desaulniers <ndesauniers@google.com> Reviewed-by:
Sedat Dilek <sedat.dilek@gmail.com>
-
- Oct 21, 2021
-
-
Hengqi Chen authored
The helper is used in tracing programs to cast a socket pointer to a unix_sock pointer. The return value could be NULL if the casting is illegal. Suggested-by:
Yonghong Song <yhs@fb.com> Signed-off-by:
Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Acked-by:
Song Liu <songliubraving@fb.com> Link: https://lore.kernel.org/bpf/20211021134752.1223426-2-hengqi.chen@gmail.com
-
Ye Guojin authored
'tree-ssa-operands.h' included in 'gcc-common.h' is duplicated. it's also included at line 56. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
Ye Guojin <ye.guojin@zte.com.cn> Signed-off-by:
Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20211019082910.998257-1-ye.guojin@zte.com.cn
-
Kees Cook authored
This plugin has no impact on the resulting binary, is disabled under COMPILE_TEST, and is not enabled on any builds I'm aware of. Additionally, given the clarified purpose of GCC plugins in the kernel, remove cyc_complexity. Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Michal Marek <michal.lkml@markovi.net> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: linux-hardening@vger.kernel.org Cc: linux-kbuild@vger.kernel.org Cc: linux-doc@vger.kernel.org Signed-off-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Miguel Ojeda <ojeda@kernel.org> Reviewed-by:
Nathan Chancellor <nathan@kernel.org> Acked-by:
Nick Desaulniers <ndesaulniers@google.com> Acked-by:
Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20211020173554.38122-3-keescook@chromium.org
-
Kees Cook authored
GCC plugins should only exist when some compiler feature needs to be proven but does not exist in either GCC nor Clang. For example, if a desired feature is already in Clang, it should be added to GCC upstream. Document this explicitly. Additionally, mark the plugins with matching upstream GCC features as removable past their respective GCC versions. Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Michal Marek <michal.lkml@markovi.net> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: James Morris <jmorris@namei.org> Cc: "Serge E. Hallyn" <serge@hallyn.com> Cc: Nathan Chancellor <nathan@kernel.org> Cc: linux-hardening@vger.kernel.org Cc: linux-kbuild@vger.kernel.org Cc: linux-doc@vger.kernel.org Cc: linux-security-module@vger.kernel.org Cc: llvm@lists.linux.dev Signed-off-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Nathan Chancellor <nathan@kernel.org> Reviewed-by:
Miguel Ojeda <ojeda@kernel.org> Acked-by:
Nick Desaulniers <ndesaulniers@google.com> Acked-by:
Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20211020173554.38122-2-keescook@chromium.org
-
Mark Rutland authored
Subsequent patches will add specialized handlers for fixups, in addition to the simple PC fixup and BPF handlers we have today. In preparation, this patch adds a new `type` field to struct exception_table_entry, and uses this to distinguish the fixup and BPF cases. A `data` field is also added so that subsequent patches can associate data specific to each exception site (e.g. register numbers). Handlers are named ex_handler_*() for consistency, following the exmaple of x86. At the same time, get_ex_fixup() is split out into a helper so that it can be used by other ex_handler_*() functions ins subsequent patches. This patch will increase the size of the exception tables, which will be remedied by subsequent patches removing redundant fixup code. There should be no functional change as a result of this patch. Since each entry is now 12 bytes in size, we must reduce the alignment of each entry from `.align 3` (i.e. 8 bytes) to `.align 2` (i.e. 4 bytes), which is the natrual alignment of the `insn` and `fixup` fields. The current 8-byte alignment is a holdover from when the `insn` and `fixup` fields was 8 bytes, and while not harmful has not been necessary since commit: 6c94f27a ("arm64: switch to relative exception tables") Similarly, RO_EXCEPTION_TABLE_ALIGN is dropped to 4 bytes. Concurrently with this patch, x86's exception table entry format is being updated (similarly to a 12-byte format, with 32-bytes of absolute data). Once both have been merged it should be possible to unify the sorttable logic for the two. Signed-off-by:
Mark Rutland <mark.rutland@arm.com> Reviewed-by:
Ard Biesheuvel <ardb@kernel.org> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Andrii Nakryiko <andrii@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: James Morse <james.morse@arm.com> Cc: Jean-Philippe Brucker <jean-philippe@linaro.org> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20211019160219.5202-11-mark.rutland@arm.com Signed-off-by:
Will Deacon <will@kernel.org>
-
- Oct 18, 2021
-
-
Kees Cook authored
There are many places where kernel code wants to have several different typed trailing flexible arrays. This would normally be done with multiple flexible arrays in a union, but since GCC and Clang don't (on the surface) allow this, there have been many open-coded workarounds, usually involving neighboring 0-element arrays at the end of a structure. For example, instead of something like this: struct thing { ... union { struct type1 foo[]; struct type2 bar[]; }; }; code works around the compiler with: struct thing { ... struct type1 foo[0]; struct type2 bar[]; }; Another case is when a flexible array is wanted as the single member within a struct (which itself is usually in a union). For example, this would be worked around as: union many { ... struct { struct type3 baz[0]; }; }; These kinds of work-arounds cause problems with size checks against such zero-element arrays (for example when building with -Warray-bounds and -Wzero-length-bounds, and with the coming FORTIFY_SOURCE improvements), so they must all be converted to "real" flexible arrays, avoiding warnings like this: fs/hpfs/anode.c: In function 'hpfs_add_sector_to_btree': fs/hpfs/anode.c:209:27: warning: array subscript 0 is outside the bounds of an interior zero-length array 'struct bplus_internal_node[0]' [-Wzero-length-bounds] 209 | anode->btree.u.internal[0].down = cpu_to_le32(a); | ~~~~~~~~~~~~~~~~~~~~~~~^~~ In file included from fs/hpfs/hpfs_fn.h:26, from fs/hpfs/anode.c:10: fs/hpfs/hpfs.h:412:32: note: while referencing 'internal' 412 | struct bplus_internal_node internal[0]; /* (internal) 2-word entries giving | ^~~~~~~~ drivers/net/can/usb/etas_es58x/es58x_fd.c: In function 'es58x_fd_tx_can_msg': drivers/net/can/usb/etas_es58x/es58x_fd.c:360:35: warning: array subscript 65535 is outside the bounds of an interior zero-length array 'u8[0]' {aka 'unsigned char[]'} [-Wzero-length-bounds] 360 | tx_can_msg = (typeof(tx_can_msg))&es58x_fd_urb_cmd->raw_msg[msg_len]; | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from drivers/net/can/usb/etas_es58x/es58x_core.h:22, from drivers/net/can/usb/etas_es58x/es58x_fd.c:17: drivers/net/can/usb/etas_es58x/es58x_fd.h:231:6: note: while referencing 'raw_msg' 231 | u8 raw_msg[0]; | ^~~~~~~ However, it _is_ entirely possible to have one or more flexible arrays in a struct or union: it just has to be in another struct. And since it cannot be alone in a struct, such a struct must have at least 1 other named member -- but that member can be zero sized. Wrap all this nonsense into the new DECLARE_FLEX_ARRAY() in support of having flexible arrays in unions (or alone in a struct). As with struct_group(), since this is needed in UAPI headers as well, implement the core there, with a non-UAPI wrapper. Additionally update kernel-doc to understand its existence. https://github.com/KSPP/linux/issues/137 Cc: Arnd Bergmann <arnd@arndb.de> Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org> Signed-off-by:
Kees Cook <keescook@chromium.org>
-
Kees Cook authored
While the run-time testing of FORTIFY_SOURCE is already present in LKDTM, there is no testing of the expected compile-time detections. In preparation for correctly supporting FORTIFY_SOURCE under Clang, adding additional FORTIFY_SOURCE defenses, and making sure FORTIFY_SOURCE doesn't silently regress with GCC, introduce a build-time test suite that checks each expected compile-time failure condition. As this is relatively backwards from standard build rules in the sense that a successful test is actually a compile _failure_, create a wrapper script to check for the correct errors, and wire it up as a dummy dependency to lib/string.o, collecting the results into a log file artifact. Signed-off-by:
Kees Cook <keescook@chromium.org>
-
- Oct 16, 2021
-
-
Steven Rostedt authored
I received a build failure for a new patch I'm working on the nds32 architecture, and when I went to test it, I couldn't get to my build error, because it failed to build with a bunch of: Error: invalid operands (*UND* and *UND* sections) for `^' issues with various files. Those files were temporary asm files that looked like: kernel/.tmp_mc_fork.s I decided to look deeper, and found that the "mc" portion of that name stood for "mcount", and was created by the recordmcount.pl script. One that I wrote over a decade ago. Once I knew the source of the problem, I was able to investigate it further. The way the recordmcount.pl script works (BTW, there's a C version that simply modifies the ELF object) is by doing an "objdump" on the object file. Looks for all the calls to "mcount", and creates an offset of those locations from some global variable it can use (usually a global function name, found with <.*>:). Creates a asm file that is a table of references to these locations, using the found variable/function. Compiles it and links it back into the original object file. This asm file is called ".tmp_mc_<object_base_name>.s". The problem here is that the objdump produced by the nds32 object file, contains things that look like: 0000159a <.L3^B1>: 159a: c6 00 beqz38 $r6, 159a <.L3^B1> 159a: R_NDS32_9_PCREL_RELA .text+0x159e 159c: 84 d2 movi55 $r6, #-14 159e: 80 06 mov55 $r0, $r6 15a0: ec 3c addi10.sp #0x3c Where ".L3^B1 is somehow selected as the "global" variable to index off of. Then the assembly file that holds the mcount locations looks like this: .section __mcount_loc,"a",@progbits .align 2 .long .L3^B1 + -5522 .long .L3^B1 + -5384 .long .L3^B1 + -5270 .long .L3^B1 + -5098 .long .L3^B1 + -4970 .long .L3^B1 + -4758 .long .L3^B1 + -4122 [...] And when it is compiled back to an object to link to the original object, the compile fails on the "^" symbol. Simple solution for now, is to have the perl script ignore using function symbols that have an "^" in the name. Link: https://lkml.kernel.org/r/20211014143507.4ad2c0f7@gandalf.local.home Cc: stable@vger.kernel.org Acked-by:
Greentime Hu <green.hu@gmail.com> Fixes: fbf58a52 ("nds32/ftrace: Add RECORD_MCOUNT support") Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org>
-
- Oct 15, 2021
-
-
Kees Cook authored
For files that lack trailing newlines and match a leaking address (e.g. wchan[1]), the leaking_addresses.pl report would run together with the next line, making things look corrupted. Unconditionally remove the newline on input, and write it back out on output. [1] https://lore.kernel.org/all/20210103142726.GC30643@xsang-OptiPlex-9020/ Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20211008111626.151570317@infradead.org
-
- Oct 12, 2021
-
-
Kees Cook authored
Fixes "Compiler Attributes: add __alloc_size() for better bounds checking" so that the __alloc_size() macro is ignored for function prototypes when generating kerndoc. Avoids warnings like: ./include/linux/slab.h:662: warning: Function parameter or member '1' not described in '__alloc_size' ./include/linux/slab.h:662: warning: Function parameter or member '2' not described in '__alloc_size' ./include/linux/slab.h:662: warning: expecting prototype for kcalloc(). Prototype was for __alloc_size() instead Suggested-by:
Matthew Wilcox <willy@infradead.org> Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20211011180650.3603988-1-keescook@chromium.org Signed-off-by:
Jonathan Corbet <corbet@lwn.net>
-
Paweł Jasiak authored
Add tarzst-pkg and perf-tarzst-src-pkg targets to build zstd compressed tarballs. Signed-off-by:
Paweł Jasiak <pawel@jasiak.dev> Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Hui Su authored
update the comments of kallsyms support. Fixes: af73d78b ("kbuild: Remove debug info from kallsyms linking") Signed-off-by:
Hui Su <suhui_kernel@163.com> Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
- Oct 11, 2021
-
-
Masahiro Yamada authored
If this function fails to touch a dummy header due to missing parent directory, then it creates it and touches the file again. This was needed because CONFIG_FOO_BAR was previously tracked by include/config/foo/bar.h. (include/config/foo/ may not exist here) This is no longer the case since commit 0e0345b7 ("kbuild: redo fake deps at include/config/*.h"); now all the fake headers are placed right under include/config/, like include/config/FOO_BAR. Do not try to create parent directory, include/config/, which already exists. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
The if ... else inside the for-loop is unneeded because one empty line is placed after printing the last element of deps_config. Currently, all errors in conf_write_dep() are ignored. Add proper error checks. Rename it to conf_write_autoconf_cmd(), which is more intuitive. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
This function does similar for auto.conf and autoconf.h Create __conf_write_autoconf() helper to factor out the common code. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
For consistency with conf_get_autoconfig_name() Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
Now that sym_escape_string_value() is only used in confdata.c it can be a 'static' function. Rename it escape_string_value() because it is agnostic about (struct sym *). Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
We can reuse __print_symbol() helper to print symbols for listnewconfig. Only the difference is the format for "n" symbols. This prints "CONFIG_FOO=n" instead of "# CONFIG_FOO is not set". Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
I do not think 'struct conf_printer' is so useful. Add simple functions, print_symbol_for_*() to write out one symbol. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
All the call sites of conf_write_heading() pass NULL to the third argument, and it is not used in the function. Also, the print_comment hooks are doing much more complex than needed. Rewrite the code. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
- Oct 08, 2021
-
-
Palmer Dabbelt authored
These can be replaced by statx(). Since rv32 has a 64-bit time_t we just never ended up with them in the first place. This is now an error due to -Werror. Suggested-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Palmer Dabbelt <palmerdabbelt@google.com>
-
- Oct 06, 2021
-
-
Brendan Higgins authored
KUnit and structleak don't play nice, so add a makefile variable for enabling structleak when it complains. Co-developed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Brendan Higgins <brendanhiggins@google.com> Reviewed-by:
David Gow <davidgow@google.com> Signed-off-by:
Shuah Khan <skhan@linuxfoundation.org>
-