aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
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]
2020-04-08sched/debug: Remove redundant macro defineValentin Schneider1-12/+0
Most printing macros for procfs are defined globally in debug.c, and they are re-defined (to the exact same thing) within proc_sched_show_task(). Get rid of the duplicate defines. 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/core: Remove unused rq::last_load_update_tickVincent Donnefort2-2/+0
The following commit: 5e83eafbfd3b ("sched/fair: Remove the rq->cpu_load[] update code") eliminated the last use case for rq->last_load_update_tick, so remove the field as well. Reviewed-by: Dietmar Eggemann <[email protected]> Reviewed-by: Vincent Guittot <[email protected]> Signed-off-by: Vincent Donnefort <[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-08workqueue: Remove the warning in wq_worker_sleeping()Sebastian Andrzej Siewior2-3/+6
The kernel test robot triggered a warning with the following race: task-ctx A interrupt-ctx B worker -> process_one_work() -> work_item() -> schedule(); -> sched_submit_work() -> wq_worker_sleeping() -> ->sleeping = 1 atomic_dec_and_test(nr_running) __schedule(); *interrupt* async_page_fault() -> local_irq_enable(); -> schedule(); -> sched_submit_work() -> wq_worker_sleeping() -> if (WARN_ON(->sleeping)) return -> __schedule() -> sched_update_worker() -> wq_worker_running() -> atomic_inc(nr_running); -> ->sleeping = 0; -> sched_update_worker() -> wq_worker_running() if (!->sleeping) return In this context the warning is pointless everything is fine. An interrupt before wq_worker_sleeping() will perform the ->sleeping assignment (0 -> 1 > 0) twice. An interrupt after wq_worker_sleeping() will trigger the warning and nr_running will be decremented (by A) and incremented once (only by B, A will skip it). This is the case until the ->sleeping is zeroed again in wq_worker_running(). Remove the WARN statement because this condition may happen. Document that preemption around wq_worker_sleeping() needs to be disabled to protect ->sleeping and not just as an optimisation. Fixes: 6d25be5782e48 ("sched/core, workqueues: Distangle worker accounting from rq lock") Reported-by: kernel test robot <[email protected]> Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Cc: Tejun Heo <[email protected]> Link: https://lkml.kernel.org/r/20200327074308.GY11705@shao2-debian
2020-04-08sched/fair: Fix negative imbalance in imbalance calculationAubrey Li1-0/+8
A negative imbalance value was observed after imbalance calculation, this happens when the local sched group type is group_fully_busy, and the average load of local group is greater than the selected busiest group. Fix this problem by comparing the average load of the local and busiest group before imbalance calculation formula. Suggested-by: Vincent Guittot <[email protected]> Reviewed-by: Phil Auld <[email protected]> Reviewed-by: Vincent Guittot <[email protected]> Acked-by: Mel Gorman <[email protected]> Signed-off-by: Aubrey Li <[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/fair: Fix race between runtime distribution and assignmentHuaixin Chang1-20/+11
Currently, there is a potential race between distribute_cfs_runtime() and assign_cfs_rq_runtime(). Race happens when cfs_b->runtime is read, distributes without holding lock and finds out there is not enough runtime to charge against after distribution. Because assign_cfs_rq_runtime() might be called during distribution, and use cfs_b->runtime at the same time. Fibtest is the tool to test this race. Assume all gcfs_rq is throttled and cfs period timer runs, slow threads might run and sleep, returning unused cfs_rq runtime and keeping min_cfs_rq_runtime in their local pool. If all this happens sufficiently quickly, cfs_b->runtime will drop a lot. If runtime distributed is large too, over-use of runtime happens. A runtime over-using by about 70 percent of quota is seen when we test fibtest on a 96-core machine. We run fibtest with 1 fast thread and 95 slow threads in test group, configure 10ms quota for this group and see the CPU usage of fibtest is 17.0%, which is far more than the expected 10%. On a smaller machine with 32 cores, we also run fibtest with 96 threads. CPU usage is more than 12%, which is also more than expected 10%. This shows that on similar workloads, this race do affect CPU bandwidth control. Solve this by holding lock inside distribute_cfs_runtime(). Fixes: c06f04c70489 ("sched: Fix potential near-infinite distribute_cfs_runtime() loop") Reviewed-by: Ben Segall <[email protected]> Signed-off-by: Huaixin Chang <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Link: https://lore.kernel.org/lkml/[email protected]/
2020-04-08sched/fair: Align rq->avg_idle and rq->avg_scan_costValentin Schneider3-11/+8
sched/core.c uses update_avg() for rq->avg_idle and sched/fair.c uses an open-coded version (with the exact same decay factor) for rq->avg_scan_cost. On top of that, select_idle_cpu() expects to be able to compare these two fields. The only difference between the two is that rq->avg_scan_cost is computed using a pure division rather than a shift. Turns out it actually matters, first of all because the shifted value can be negative, and the standard has this to say about it: """ The result of E1 >> E2 is E1 right-shifted E2 bit positions. [...] If E1 has a signed type and a negative value, the resulting value is implementation-defined. """ Not only this, but (arithmetic) right shifting a negative value (using 2's complement) is *not* equivalent to dividing it by the corresponding power of 2. Let's look at a few examples: -4 -> 0xF..FC -4 >> 3 -> 0xF..FF == -1 != -4 / 8 -8 -> 0xF..F8 -8 >> 3 -> 0xF..FF == -1 == -8 / 8 -9 -> 0xF..F7 -9 >> 3 -> 0xF..FE == -2 != -9 / 8 Make update_avg() use a division, and export it to the private scheduler header to reuse it where relevant. Note that this still lets compilers use a shift here, but should prevent any unwanted surprise. The disassembly of select_idle_cpu() remains unchanged on arm64, and ttwu_do_wakeup() gains 2 instructions; the diff sort of looks like this: - sub x1, x1, x0 + subs x1, x1, x0 // set condition codes + add x0, x1, #0x7 + csel x0, x0, x1, mi // x0 = x1 < 0 ? x0 : x1 add x0, x3, x0, asr #3 which does the right thing (i.e. gives us the expected result while still using an arithmetic shift) 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.