aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-04-08io_uring: do not always copy iovec in io_req_map_rw()Xiaoguang Wang1-2/+3
In io_read_prep() or io_write_prep(), io_req_map_rw() takes struct io_async_rw's fast_iov as argument to call io_import_iovec(), and if io_import_iovec() uses struct io_async_rw's fast_iov as valid iovec array, later indeed io_req_map_rw() does not need to do the memcpy operation, because they are same pointers. Signed-off-by: Xiaoguang Wang <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-04-08io_uring: ensure openat sets O_LARGEFILE if neededJens Axboe1-0/+2
OPENAT2 correctly sets O_LARGEFILE if it has to, but that escaped the OPENAT opcode. Dmitry reports that his test case that compares openat() and IORING_OP_OPENAT sees failures on large files: *** sync openat openat succeeded sync write at offset 0 write succeeded sync write at offset 4294967296 write succeeded *** sync openat openat succeeded io_uring write at offset 0 write succeeded io_uring write at offset 4294967296 write succeeded *** io_uring openat openat succeeded sync write at offset 0 write succeeded sync write at offset 4294967296 write failed: File too large *** io_uring openat openat succeeded io_uring write at offset 0 write succeeded io_uring write at offset 4294967296 write failed: File too large Ensure we set O_LARGEFILE, if force_o_largefile() is true. Cc: [email protected] # v5.6 Fixes: 15b71abe7b52 ("io_uring: add support for IORING_OP_OPENAT") Reported-by: Dmitry Kadashev <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-04-09kbuild: add dummy toolchains to enable all cc-option etc. in KconfigMasahiro Yamada4-0/+123
Staring v4.18, Kconfig evaluates compiler capabilities, and hides CONFIG options your compiler does not support. This works well if you configure and build the kernel on the same host machine. It is inconvenient if you prepare the .config that is carried to a different build environment (typically this happens when you package the kernel for distros) because using a different compiler potentially produces different CONFIG options than the real build environment. So, you probably want to make as many options visible as possible. In other words, you need to create a super-set of CONFIG options that cover any build environment. If some of the CONFIG options turned out to be unsupported on the build machine, they are automatically disabled by the nature of Kconfig. However, it is not feasible to get a full-featured compiler for every arch. This issue was discussed here: https://lkml.org/lkml/2019/12/9/620 Other than distros, savedefconfig is also a problem. Some arch sub-systems periodically resync defconfig files. If you use a less-capable compiler for savedefconfig, options that do not meet 'depends on $(cc-option,...)' will be forcibly disabled. So, 'make defconfig && make savedefconfig' may silently change the behavior. This commit adds a set of dummy toolchains that pretend to support any feature. Most of compiler features are tested by cc-option, which simply checks the exit code of $(CC). The dummy tools are shell scripts that always exit with 0. So, $(cc-option, ...) is evaluated as 'y'. There are more complicated checks such as: scripts/gcc-x86_{32,64}-has-stack-protector.sh scripts/gcc-plugin.sh scripts/tools-support-relr.sh scripts/dummy-tools/gcc passes all checks. From the top directory of the source tree, you can do: $ make CROSS_COMPILE=scripts/dummy-tools/ oldconfig Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Philipp Rudo <[email protected]> Tested-by: Jeremy Cline <[email protected]>
2020-04-09kbuild: link lib-y objects to vmlinux forcibly when CONFIG_MODULES=yMasahiro Yamada2-18/+6
Kbuild supports not only obj-y but also lib-y to list objects linked to vmlinux. The difference between them is that all the objects from obj-y are forcibly linked to vmlinux, whereas the objects from lib-y are linked as needed; if there is no user of a lib-y object, it is not linked. lib-y is intended to list utility functions that may be called from all over the place (and may be unused at all), but it is a problem for EXPORT_SYMBOL(). Even if there is no call-site in the vmlinux, we need to keep exported symbols for the use from loadable modules. Commit 7f2084fa55e6 ("[kbuild] handle exports in lib-y objects reliably") worked around it by linking a dummy object, lib-ksyms.o, which contains references to all the symbols exported from lib.a in that directory. It uses the linker script command, EXTERN. Unfortunately, the meaning of EXTERN of ld.lld is different from that of ld.bfd. Therefore, this does not work with LD=ld.lld (CBL issue #515). Anyway, the build rule of lib-ksyms.o is somewhat tricky. So, I want to get rid of it. At first, I was thinking of accumulating lib-y objects into obj-y (or even replacing lib-y with obj-y entirely), but the lib-y syntax is used beyond the ordinary use in lib/ and arch/*/lib/. Examples: - drivers/firmware/efi/libstub/Makefile builds lib.a, which is linked into vmlinux in the own way (arm64), or linked to the decompressor (arm, x86). - arch/alpha/lib/Makefile builds lib.a which is linked not only to vmlinux, but also to bootloaders in arch/alpha/boot/Makefile. - arch/xtensa/boot/lib/Makefile builds lib.a for use from arch/xtensa/boot/boot-redboot/Makefile. One more thing, adding everything to obj-y would increase the vmlinux size of allnoconfig (or tinyconfig). For less impact, I tweaked the destination of lib.a at the top Makefile; when CONFIG_MODULES=y, lib.a goes to KBUILD_VMLINUX_OBJS, which is forcibly linked to vmlinux, otherwise lib.a goes to KBUILD_VMLINUX_LIBS as before. The size impact for normal usecases is quite small since at lease one symbol in every lib-y object is eventually called by someone. In case you are intrested, here are the figures. x86_64_defconfig: text data bss dec hex filename 19566602 5422072 1589328 26578002 1958c52 vmlinux.before 19566932 5422104 1589328 26578364 1958dbc vmlinux.after The case with the biggest impact is allnoconfig + CONFIG_MODULES=y. ARCH=x86 allnoconfig + CONFIG_MODULES=y: text data bss dec hex filename 1175162 254740 1220608 2650510 28718e vmlinux.before 1177974 254836 1220608 2653418 287cea vmlinux.after Hopefully this is still not a big deal. The per-file trimming with the static library is not so effective after all. If fine-grained optimization is desired, some architectures support CONFIG_LD_DEAD_CODE_DATA_ELIMINATION, which trims dead code per-symbol basis. When LTO is supported in mainline, even better optimization will be possible. Link: https://github.com/ClangBuiltLinux/linux/issues/515 Signed-off-by: Masahiro Yamada <[email protected]> Reported-by: kbuild test robot <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]>
2020-04-09MIPS: fw: arc: add __weak to prom_meminit and prom_free_prom_memoryMasahiro Yamada1-2/+2
As far as I understood, prom_meminit() in arch/mips/fw/arc/memory.c is overridden by the one in arch/mips/sgi-ip32/ip32-memory.c if CONFIG_SGI_IP32 is enabled. The use of EXPORT_SYMBOL in static libraries potentially causes a problem for the llvm linker [1]. So, I want to forcibly link lib-y objects to vmlinux when CONFIG_MODULES=y. As a groundwork, we must fix multiple definitions that have previously been hidden by lib-y. The prom_cleanup() in this file is already marked as __weak (because it is overridden by the one in arch/mips/sgi-ip22/ip22-mc.c). I think it should be OK to do the same for these two. [1]: https://github.com/ClangBuiltLinux/linux/issues/515 Reported-by: kbuild test robot <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> Acked-By: Thomas Bogendoerfer <[email protected]>
2020-04-09kbuild: remove -I$(srctree)/tools/include from scripts/MakefileMasahiro Yamada1-4/+0
I do not like to add an extra include path for every tool with no good reason. This should be specified per file. This line was added by commit 6520fe5564ac ("x86, realmode: 16-bit real-mode code support for relocs tool"), which did not touch anything else in scripts/. I see no reason to add this. Also, remove the comment about kallsyms because we do not have any for the rest of programs. Signed-off-by: Masahiro Yamada <[email protected]>
2020-04-09kbuild: do not pass $(KBUILD_CFLAGS) to scripts/mkcompile_hMasahiro Yamada1-1/+1
scripts/mkcompile_h uses $(CC) only for getting the version string. I suspected there was a specific reason why the additional flags were needed, and dug the commit history. This code dates back to at least 2002 [1], but I could not get any more clue. Just get rid of it. [1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=29f3df7eba8ddf91a55183f9967f76fbcc3ab742 Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Kees Cook <[email protected]>
2020-04-09Documentation/llvm: fix the name of llvm-sizeFangrui Song1-1/+1
The tool is called llvm-size, not llvm-objsize. Fixes: fcf1b6a35c16 ("Documentation/llvm: add documentation on building w/ Clang/LLVM") Signed-off-by: Fangrui Song <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2020-04-09kbuild: mkcompile_h: Include $LD version in /proc/versionKees Cook2-2/+6
When doing Clang builds of the kernel, it is possible to link with either ld.bfd (binutils) or ld.lld (LLVM), but it is not possible to discover this from a running kernel. Add the "$LD -v" output to /proc/version. Signed-off-by: Kees Cook <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Tested-by: Nick Desaulniers <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Reviewed-by: Fangrui Song <[email protected]> Reviewed-by: Sedat Dilek <[email protected]> Tested-by: Sedat Dilek <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2020-04-09kconfig: qconf: Fix a few alignment issuesMauro Carvalho Chehab1-6/+7
There are a few items with wrong alignments. Solve them. Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2020-04-09kconfig: qconf: remove some old bogus TODOsMauro Carvalho Chehab1-2/+1
The items described on those TODOs are already solved. So, remove the comments. Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2020-04-09kconfig: qconf: fix support for the split view modeMauro Carvalho Chehab2-7/+28
At least on my tests (building against Qt5.13), it seems to me that, since Kernel 3.14, the split view mode is broken. Maybe it was not a top priority during the conversion time. Anyway, this patch changes the logic in order to properly support the split view mode and the single view mode. Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2020-04-09kconfig: qconf: fix the content of the main widgetMauro Carvalho Chehab1-6/+17
The port to Qt5 tried to preserve the same way as it used to work with Qt3 and Qt4. However, at least with newer versions of Qt5 (5.13), this doesn't work properly. Change the schema by adding a vertical layout, in order for it to start working properly again. Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2020-04-09kconfig: qconf: Change title for the item windowMauro Carvalho Chehab1-1/+9
Both main config window and the item window have "Option" name. That sounds weird, and makes harder to debug issues of a window appearing at the wrong place. So, change the title to reflect the contents of each window. Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2020-04-09kconfig: qconf: clean deprecated warningsMauro Carvalho Chehab1-4/+4
The recommended way to initialize a null string is with QString(). This is there at least since Qt5.5, with is when qconf was ported to Qt5. Fix those warnings: scripts/kconfig/qconf.cc: In member function ‘void ConfigItem::updateMenu()’: scripts/kconfig/qconf.cc:158:31: warning: ‘QString::null’ is deprecated: use QString() [-Wdeprecated-declarations] 158 | setText(noColIdx, QString::null); | ^~~~ In file included from /usr/include/qt5/QtCore/qobject.h:47, from /usr/include/qt5/QtWidgets/qwidget.h:45, from /usr/include/qt5/QtWidgets/qmainwindow.h:44, from /usr/include/qt5/QtWidgets/QMainWindow:1, from scripts/kconfig/qconf.cc:9: Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2020-04-09gcc-plugins: drop support for GCC <= 4.7Masahiro Yamada7-103/+14
Nobody was opposed to raising minimum GCC version to 4.8 [1] So, we will drop GCC <= 4.7 support sooner or later. We always use C++ compiler for building plugins for GCC >= 4.8. This commit drops the plugin support for GCC <= 4.7 a bit earlier, which allows us to dump lots of code. [1] https://lkml.org/lkml/2020/1/23/545 Signed-off-by: Masahiro Yamada <[email protected]> Acked-by: Kees Cook <[email protected]>
2020-04-09kbuild: Enable -Wtautological-compareNathan Chancellor2-2/+1
Currently, we disable -Wtautological-compare, which in turn disables a bunch of more specific tautological comparison warnings that are useful for the kernel such as -Wtautological-bitwise-compare. See clang's documentation below for the other warnings that are suppressed by -Wtautological-compare. Now that all of the major/noisy warnings have been fixed, enable -Wtautological-compare so that more issues can be caught at build time by various continuous integration setups. -Wtautological-constant-out-of-range-compare is kept disabled under a normal build but visible at W=1 because there are places in the kernel where a constant or variable size can change based on the kernel configuration. These are not fixed in a clean/concise way and the ones I have audited so far appear to be harmless. It is not a subgroup but rather just one warning so we do not lose out on much coverage by default. Link: https://github.com/ClangBuiltLinux/linux/issues/488 Link: http://releases.llvm.org/10.0.0/tools/clang/docs/DiagnosticsReference.html#wtautological-compare Link: https://bugs.llvm.org/show_bug.cgi?id=42666 Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2020-04-09x86: update AS_* macros to binutils >=2.23, supporting ADX and AVX2Jason A. Donenfeld21-90/+15
Now that the kernel specifies binutils 2.23 as the minimum version, we can remove ifdefs for AVX2 and ADX throughout. Signed-off-by: Jason A. Donenfeld <[email protected]> Acked-by: Ingo Molnar <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2020-04-089p: document short read behaviour with O_NONBLOCKDominique Martinet1-0/+10
Regular files opened with O_NONBLOCK allow read to return after a single round-trip with the server instead of trying to fill buffer. Add a few lines in 9p documentation to describe that. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Dominique Martinet <[email protected]>
2020-04-09crypto: x86 - clean up poly1305-x86_64-cryptogams.S by 'make clean'Masahiro Yamada1-2/+0
poly1305-x86_64-cryptogams.S is a generated file, so it should be cleaned up by 'make clean'. Assigning it to the variable 'targets' teaches Kbuild that it is a generated file. However, this line is not evaluated when cleaning because scripts/Makefile.clean does not include include/config/auto.conf. Remove the ifneq-conditional, so this file is correctly cleaned up. Signed-off-by: Masahiro Yamada <[email protected]> Acked-by: Herbert Xu <[email protected]> Acked-by: Ingo Molnar <[email protected]>
2020-04-09Documentation/changes: Raise minimum supported binutils version to 2.23Borislav Petkov1-2/+2
The currently minimum-supported binutils version 2.21 has the problem of promoting symbols which are defined outside of a section into absolute. According to Arvind: binutils-2.21 and -2.22. An x86-64 defconfig will fail with Invalid absolute R_X86_64_32S relocation: _etext and after fixing that one, with Invalid absolute R_X86_64_32S relocation: __end_of_kernel_reserve Those two versions of binutils have a bug when it comes to handling symbols defined outside of a section and binutils 2.23 has the proper fix, see: https://sourceware.org/legacy-ml/binutils/2012-06/msg00155.html Therefore, up to the fixed version directly, skipping the broken ones. Currently shipping distros already have the fixed binutils version so there should be no breakage resulting from this. For more details about the whole thing, see the thread in Link. Signed-off-by: Borislav Petkov <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Acked-by: Kees Cook <[email protected]> Acked-by: Jason A. Donenfeld <[email protected]> Acked-by: Nick Desaulniers <[email protected]> Acked-by: Ingo Molnar <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2020-04-09crypto: curve25519 - do not pollute dispatcher based on assemblerJason A. Donenfeld1-4/+2
Since we're doing a static inline dispatch here, we normally branch based on whether or not there's an arch implementation. That would have been fine in general, except the crypto Makefile prior used to turn things off -- despite the Kconfig -- resulting in us needing to also hard code various assembler things into the dispatcher too. The horror! Now that the assembler config options are done by Kconfig, we can get rid of the inconsistency. Signed-off-by: Jason A. Donenfeld <[email protected]> Acked-by: Herbert Xu <[email protected]> Acked-by: Ingo Molnar <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2020-04-09crypto: x86 - rework configuration based on KconfigJason A. Donenfeld2-91/+69
Now that assembler capabilities are probed inside of Kconfig, we can set up proper Kconfig-based dependencies. We also take this opportunity to reorder the Makefile, so that items are grouped logically by primitive. Signed-off-by: Jason A. Donenfeld <[email protected]> Acked-by: Herbert Xu <[email protected]> Acked-by: Ingo Molnar <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2020-04-09x86: add comments about the binutils version to support code in as-instrMasahiro Yamada1-0/+10
We raise the minimal supported binutils version from time to time. The last bump was commit 1fb12b35e5ff ("kbuild: Raise the minimum required binutils version to 2.21"). We have these as-instr tests because binutils 2.21 does not support them. When we bump the binutils version next time, this will be a good hint to find out which one can be dropped. As for the Clang/LLVM builds, we require very new LLVM version, so the LLVM integrated assembler supports all of them. Signed-off-by: Masahiro Yamada <[email protected]> Acked-by: Jason A. Donenfeld <[email protected]> Acked-by: Ingo Molnar <[email protected]> Acked-by: Nick Desaulniers <[email protected]>
2020-04-09x86: probe assembler capabilities via kconfig instead of makefileJason A. Donenfeld4-11/+20
Doing this probing inside of the Makefiles means we have a maze of ifdefs inside the source code and child Makefiles that need to make proper decisions on this too. Instead, we do it at Kconfig time, like many other compiler and assembler options, which allows us to set up the dependencies normally for full compilation units. In the process, the ADX test changes to use %eax instead of %r10 so that it's valid in both 32-bit and 64-bit mode. Signed-off-by: Jason A. Donenfeld <[email protected]> Acked-by: Ingo Molnar <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2020-04-09drm/i915: remove always-defined CONFIG_AS_MOVNTDQAMasahiro Yamada2-8/+0
CONFIG_AS_MOVNTDQA was introduced by commit 0b1de5d58e19 ("drm/i915: Use SSE4.1 movntdqa to accelerate reads from WC memory"). We raise the minimal supported binutils version from time to time. The last bump was commit 1fb12b35e5ff ("kbuild: Raise the minimum required binutils version to 2.21"). I confirmed the code in $(call as-instr,...) can be assembled by the binutils 2.21 assembler and also by LLVM integrated assembler. Remove CONFIG_AS_MOVNTDQA, which is always defined. Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Reviewed-by: Jason A. Donenfeld <[email protected]> Acked-by: Ingo Molnar <[email protected]> Acked-by: Jani Nikula <[email protected]>
2020-04-09x86: remove always-defined CONFIG_AS_AVXMasahiro Yamada13-89/+21
CONFIG_AS_AVX was introduced by commit ea4d26ae24e5 ("raid5: add AVX optimized RAID5 checksumming"). We raise the minimal supported binutils version from time to time. The last bump was commit 1fb12b35e5ff ("kbuild: Raise the minimum required binutils version to 2.21"). I confirmed the code in $(call as-instr,...) can be assembled by the binutils 2.21 assembler and also by LLVM integrated assembler. Remove CONFIG_AS_AVX, which is always defined. Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Jason A. Donenfeld <[email protected]> Acked-by: Ingo Molnar <[email protected]>
2020-04-09x86: remove always-defined CONFIG_AS_SSSE3Masahiro Yamada5-15/+4
CONFIG_AS_SSSE3 was introduced by commit 75aaf4c3e6a4 ("x86/raid6: correctly check for assembler capabilities"). We raise the minimal supported binutils version from time to time. The last bump was commit 1fb12b35e5ff ("kbuild: Raise the minimum required binutils version to 2.21"). I confirmed the code in $(call as-instr,...) can be assembled by the binutils 2.21 assembler and also by LLVM integrated assembler. Remove CONFIG_AS_SSSE3, which is always defined. I added ifdef CONFIG_X86 to lib/raid6/algos.c to avoid link errors on non-x86 architectures. lib/raid6/algos.c is built not only for the kernel but also for testing the library code from userspace. I added -DCONFIG_X86 to lib/raid6/test/Makefile to cator to this usecase. Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Jason A. Donenfeld <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Acked-by: Ingo Molnar <[email protected]>
2020-04-09x86: remove always-defined CONFIG_AS_CFI_SECTIONSMasahiro Yamada2-6/+2
CONFIG_AS_CFI_SECTIONS was introduced by commit 9e565292270a ("x86: Use .cfi_sections for assembly code"). We raise the minimal supported binutils version from time to time. The last bump was commit 1fb12b35e5ff ("kbuild: Raise the minimum required binutils version to 2.21"). I confirmed the code in $(call as-instr,...) can be assembled by the binutils 2.21 assembler and also by LLVM integrated assembler. Remove CONFIG_AS_CFI_SECTIONS, which is always defined. Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Jason A. Donenfeld <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Acked-by: Ingo Molnar <[email protected]>
2020-04-09x86: remove unneeded (CONFIG_AS_)CFI_SIGNAL_FRAMEMasahiro Yamada2-10/+2
Commit 131484c8da97 ("x86/debug: Remove perpetually broken, unmaintainable dwarf annotations") removes all the users of CFI_SIGNAL_FRAME. Remove the CFI_SIGNAL_FRAME and CONFIG_AS_CFI_SIGNAL_FRAME. Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Jason A. Donenfeld <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Acked-by: Ingo Molnar <[email protected]>
2020-04-09x86: remove always-defined CONFIG_AS_CFIMasahiro Yamada2-44/+2
CONFIG_AS_CFI was introduced by commit e2414910f212 ("[PATCH] x86: Detect CFI support in the assembler at runtime"), and extended by commit f0f12d85af85 ("x86_64: Check for .cfi_rel_offset in CFI probe"). We raise the minimal supported binutils version from time to time. The last bump was commit 1fb12b35e5ff ("kbuild: Raise the minimum required binutils version to 2.21"). I confirmed the code in $(call as-instr,...) can be assembled by the binutils 2.21 assembler and also by LLVM integrated assembler. Remove CONFIG_AS_CFI, which is always defined. Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Jason A. Donenfeld <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Acked-by: Ingo Molnar <[email protected]>
2020-04-09x86: remove unneeded defined(__ASSEMBLY__) check from asm/dwarf2.hMasahiro Yamada1-1/+1
This header file has the following check at the top: #ifndef __ASSEMBLY__ #warning "asm/dwarf2.h should be only included in pure assembly files" #endif So, we expect defined(__ASSEMBLY__) is always true. Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Jason A. Donenfeld <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Acked-by: Ingo Molnar <[email protected]>
2020-04-09lib/raid6/test: fix build on distros whose /bin/sh is not bashMasahiro Yamada1-3/+3
You can build a user-space test program for the raid6 library code, like this: $ cd lib/raid6/test $ make The command in $(shell ...) function is evaluated by /bin/sh by default. (or, you can specify the shell by passing SHELL=<shell> from command line) Currently '>&/dev/null' is used to sink both stdout and stderr. Because this code is bash-ism, it only works when /bin/sh is a symbolic link to bash (this is the case on RHEL etc.) This does not work on Ubuntu where /bin/sh is a symbolic link to dash. I see lots of /bin/sh: 1: Syntax error: Bad fd number and warning "your version of binutils lacks ... support" Replace it with portable '>/dev/null 2>&1'. Fixes: 4f8c55c5ad49 ("lib/raid6: build proper files on corresponding arch") Signed-off-by: Masahiro Yamada <[email protected]> Acked-by: H. Peter Anvin (Intel) <[email protected]> Reviewed-by: Jason A. Donenfeld <[email protected]> Acked-by: Ingo Molnar <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]>
2020-04-09sh: remove unneeded uapi asm-generic wrappersMasahiro Yamada2-4/+0
These are listed in include/uapi/asm-generic/Kbuild, so Kbuild will automatically generate them. Signed-off-by: Masahiro Yamada <[email protected]>
2020-04-09h8300: move definition of __kernel_size_t etc. to posix_types.hMasahiro Yamada2-15/+13
These types should be defined in posix_types.h, not in bitsperlong.h . With these defines moved, h8300-specific bitsperlong.h is no longer needed since Kbuild will automatically create a wrapper of include/uapi/asm-generic/bitsperlong.h Signed-off-by: Masahiro Yamada <[email protected]>
2020-04-09sh: use __builtin_constant_p() directly instead of IS_IMMEDIATE()Masahiro Yamada1-5/+3
__builtin_constant_p(nr) is used everywhere now. It does not make much sense to define IS_IMMEDIATE() as its alias. Signed-off-by: Masahiro Yamada <[email protected]>
2020-04-08Merge branch 'nvme-5.7' of git://git.infradead.org/nvme into block-5.7Jens Axboe12-131/+242
Pull NVMe fixes from Christoph. * 'nvme-5.7' of git://git.infradead.org/nvme: nvmet-rdma: fix double free of rdma queue nvme-fc: Revert "add module to ops template to allow module references" nvme: fix deadlock caused by ANA update wrong locking nvmet-rdma: fix bonding failover possible NULL deref nvmet: fix NULL dereference when removing a referral nvme: inherit stable pages constraint in the mpath stack device nvme-tcp: fix possible crash in recv error flow nvme-tcp: don't poll a non-live queue nvme-tcp: fix possible crash in write_zeroes processing nvmet-fc: fix typo in comment nvme-rdma: Replace comma with a semicolon nvme-fcloop: fix deallocation of working context nvme: fix compat address handling in several ioctls
2020-04-08ALSA: hda: Add driver blacklistTakashi Iwai1-0/+16
The recent AMD platform exposes an HD-audio bus but without any actual codecs, which is internally tied with a USB-audio device, supposedly. It results in "no codecs" error of HD-audio bus driver, and it's nothing but a waste of resources. This patch introduces a static blacklist table for skipping such a known bogus PCI SSID entry. As of writing this patch, the known SSIDs are: * 1043:874f - ASUS ROG Zenith II / Strix * 1462:cb59 - MSI TRX40 Creator * 1462:cb60 - MSI TRX40 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206543 Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2020-04-08ALSA: usb-audio: Add mixer workaround for TRX40 and coTakashi Iwai1-0/+28
Some recent boards (supposedly with a new AMD platform) contain the USB audio class 2 device that is often tied with HD-audio. The device exposes an Input Gain Pad control (id=19, control=12) but this node doesn't behave correctly, returning an error for each inquiry of GET_MIN and GET_MAX that should have been mandatory. As a workaround, simply ignore this node by adding a usbmix_name_map table entry. The currently known devices are: * 0414:a002 - Gigabyte TRX40 Aorus Pro WiFi * 0b05:1916 - ASUS ROG Zenith II * 0b05:1917 - ASUS ROG Strix * 0db0:0d64 - MSI TRX40 Creator * 0db0:543d - MSI TRX40 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206543 Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2020-04-08ALSA: hda/realtek - Add quirk for MSI GL63Takashi Iwai1-0/+1
MSI GL63 laptop requires the similar quirk like other MSI models, ALC1220_FIXUP_CLEVO_P950. The board BIOS doesn't provide a PCI SSID for the device, hence we need to take the codec SSID (1462:1275) instead. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207157 Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2020-04-08orangefs: don't mess with I_DIRTY_TIMES in orangefs_flushMike Marshall1-8/+0
Christoph Hellwig noticed that we were doing some unnecessary work in orangefs_flush: orangefs_flush just writes out data on every close(2) call. There is no need to change anything about the dirty state, especially as orangefs doesn't treat I_DIRTY_TIMES special in any way. The code seems to come from partially open coding vfs_fsync. He sent in a patch with the above commit message and also a patch that was a reversion of another Orangefs patch I had sent upstream a while ago. I had to fix his reversion patch so that it would compile which caused his "don't mess with I_DIRTY_TIMES" patch to fail to apply. So here I have just remade his patch and applied it after the fixed reversion patch. Signed-off-by: Mike Marshall <[email protected]>
2020-04-08orangefs: get rid of knob code...Mike Marshall3-62/+7
Christoph Hellwig sent in a reversion of "orangefs: remember count when reading." because: ->read_iter calls can race with each other and one or more ->flush calls. Remove the the scheme to store the read count in the file private data as is is completely racy and can cause use after free or double free conditions Christoph's reversion caused Orangefs not to work or to compile. I added a patch that fixed that, but intel's kbuild test robot pointed out that sending Christoph's patch followed by my patch upstream, it would break bisection because of the failure to compile. So I have combined the reversion plus my patch... here's the commit message that was in my patch: Logically, optimal Orangefs "pages" are 4 megabytes. Reading large Orangefs files 4096 bytes at a time is like trying to kick a dead whale down the beach. Before Christoph's "Revert orangefs: remember count when reading." I tried to give users a knob whereby they could, for example, use "count" in read(2) or bs with dd(1) to get whatever they considered an appropriate amount of bytes at a time from Orangefs and fill as many page cache pages as they could at once. Without the racy code that Christoph reverted Orangefs won't even compile, much less work. So this replaces the logic that used the private file data that Christoph reverted with a static number of bytes to read from Orangefs. I ran tests like the following to determine what a reasonable static number of bytes might be: dd if=/pvfsmnt/asdf of=/dev/null count=128 bs=4194304 dd if=/pvfsmnt/asdf of=/dev/null count=256 bs=2097152 dd if=/pvfsmnt/asdf of=/dev/null count=512 bs=1048576 . . . dd if=/pvfsmnt/asdf of=/dev/null count=4194304 bs=128 Reads seem faster using the static number, so my "knob code" wasn't just racy, it wasn't even a good idea... Signed-off-by: Mike Marshall <[email protected]> Reported-by: kbuild test robot <[email protected]>
2020-04-08cpuidle-haltpoll: Fix small typoYihao Wu1-2/+2
Fix a spelling typo in cpuidle-haltpoll.c. Signed-off-by: Yihao Wu <[email protected]> [ rjw: Subject & changelog ] Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-04-08ACPI, x86/boot: make acpi_nobgrt staticJason Yan1-1/+1
Fix the following sparse warning: arch/x86/kernel/acpi/boot.c:48:5: warning: symbol 'acpi_nobgrt' was not declared. Should it be static? Reported-by: Hulk Robot <[email protected]> Signed-off-by: Jason Yan <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-04-08Documentation: firmware-guide: ACPI: fix table alignment in namespace.rstVilhelm Prytz1-3/+3
Fixe the alignment in the ACPI block diagram (RST table) by adding missing spaces Signed-off-by: Vilhelm Prytz <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-04-08locking/lockdep: Improve 'invalid wait context' splatPeter Zijlstra1-20/+31
The 'invalid wait context' splat doesn't print all the information required to reconstruct / validate the error, specifically the irq-context state is missing. Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2020-04-08locking/refcount: Document interaction with PID_MAX_LIMITJann Horn1-5/+18
Document the circumstances under which refcount_t's saturation mechanism works deterministically. Acked-by: Kees Cook <[email protected]> Acked-by: Will Deacon <[email protected]> Signed-off-by: Jann Horn <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-04-08locking/percpu-rwsem: Fix a task_struct refcountQian Cai1-1/+2
The following commit: 7f26482a872c ("locking/percpu-rwsem: Remove the embedded rwsem") introduced task_struct memory leaks due to messing up the task_struct refcount. At the beginning of percpu_rwsem_wake_function(), it calls get_task_struct(), but if the trylock failed, it will remain in the waitqueue. However, it will run percpu_rwsem_wake_function() again with get_task_struct() to increase the refcount but then only call put_task_struct() once the trylock succeeded. Fix it by adjusting percpu_rwsem_wake_function() a bit to guard against when percpu_rwsem_wait() observing !private, terminating the wait and doing a quick exit() while percpu_rwsem_wake_function() then doing wake_up_process(p) as a use-after-free. Fixes: 7f26482a872c ("locking/percpu-rwsem: Remove the embedded rwsem") Suggested-by: Peter Zijlstra <[email protected]> Signed-off-by: Qian Cai <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-04-08sched/debug: Add task uclamp values to SCHED_DEBUG procfsValentin Schneider1-0/+6
Requested and effective uclamp values can be a bit tricky to decipher when playing with cgroup hierarchies. Add them to a task's procfs when SCHED_DEBUG is enabled. Reviewed-by: Qais Yousef <[email protected]> Signed-off-by: Valentin Schneider <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-04-08sched/debug: Factor out printing formats into common macrosValentin Schneider1-14/+12
The printing macros in debug.c keep redefining the same output format. Collect each output format in a single definition, and reuse that definition in the other macros. While at it, add a layer of parentheses and replace printf's with the newly introduced macros. Reviewed-by: Qais Yousef <[email protected]> Signed-off-by: Valentin Schneider <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.