aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
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]
2020-04-08perf/core: Disable page faults when getting phys addressJiri Olsa1-3/+6
We hit following warning when running tests on kernel compiled with CONFIG_DEBUG_ATOMIC_SLEEP=y: WARNING: CPU: 19 PID: 4472 at mm/gup.c:2381 __get_user_pages_fast+0x1a4/0x200 CPU: 19 PID: 4472 Comm: dummy Not tainted 5.6.0-rc6+ #3 RIP: 0010:__get_user_pages_fast+0x1a4/0x200 ... Call Trace: perf_prepare_sample+0xff1/0x1d90 perf_event_output_forward+0xe8/0x210 __perf_event_overflow+0x11a/0x310 __intel_pmu_pebs_event+0x657/0x850 intel_pmu_drain_pebs_nhm+0x7de/0x11d0 handle_pmi_common+0x1b2/0x650 intel_pmu_handle_irq+0x17b/0x370 perf_event_nmi_handler+0x40/0x60 nmi_handle+0x192/0x590 default_do_nmi+0x6d/0x150 do_nmi+0x2f9/0x3c0 nmi+0x8e/0xd7 While __get_user_pages_fast() is IRQ-safe, it calls access_ok(), which warns on: WARN_ON_ONCE(!in_task() && !pagefault_disabled()) Peter suggested disabling page faults around __get_user_pages_fast(), which gets rid of the warning in access_ok() call. Suggested-by: Peter Zijlstra <[email protected]> Signed-off-by: Jiri Olsa <[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-08perf/x86/intel/uncore: Add Ice Lake server uncore supportKan Liang3-0/+522
The uncore subsystem in Ice Lake server is similar to previous server. There are some differences in config register encoding and pci device IDs. The uncore PMON units in Ice Lake server include Ubox, Chabox, IIO, IRP, M2PCIE, PCU, M2M, PCIE3 and IMC. - For CHA, filter 1 register has been removed. The filter 0 register can be used by and of CHA events to be filterd by Thread/Core-ID. To do so, the control register's tid_en bit must be set to 1. - For IIO, there are some changes on event constraints. The MSR address and MSR offsets among counters are also changed. - For IRP, the MSR address and MSR offsets among counters are changed. - For M2PCIE, the counters are accessed by MSR now. Add new MSR address and MSR offsets. Change event constraints. - To determine the number of CHAs, have to read CAPID6(Low) and CAPID7 (High) now. - For M2M, update the PCICFG address and Device ID. - For UPI, update the PCICFG address, Device ID and counter address. - For M3UPI, update the PCICFG address, Device ID, counter address and event constraints. - For IMC, update the formular to calculate MMIO BAR address, which is MMIO_BASE + specific MEM_BAR offset. Signed-off-by: Kan Liang <[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-08perf/cgroup: Correct indirection in perf_less_group_idx()Ian Rogers1-1/+2
The void* in perf_less_group_idx() is to a member in the array which points at a perf_event*, as such it is a perf_event**. Reported-By: John Sperbeck <[email protected]> Fixes: 6eef8a7116de ("perf/core: Use min_heap in visit_groups_merge()") Signed-off-by: Ian Rogers <[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-08perf/core: Fix event cgroup trackingPeter Zijlstra1-27/+43
Song reports that installing cgroup events is broken since: db0503e4f675 ("perf/core: Optimize perf_install_in_event()") The problem being that cgroup events try to track cpuctx->cgrp even for disabled events, which is pointless and actively harmful since the above commit. Rework the code to have explicit enable/disable hooks for cgroup events, such that we can limit cgroup tracking to active events. More specifically, since the above commit disabled events are no longer added to their context from the 'right' CPU, and we can't access things like the current cgroup for a remote CPU. Cc: <[email protected]> # v5.5+ Fixes: db0503e4f675 ("perf/core: Optimize perf_install_in_event()") Reported-by: Song Liu <[email protected]> Tested-by: Song Liu <[email protected]> Reviewed-by: Song Liu <[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-08x86/xen: make xen_pvmmu_arch_setup() staticJason Yan1-1/+1
Fix the following sparse warning: arch/x86/xen/setup.c:998:12: warning: symbol 'xen_pvmmu_arch_setup' was not declared. Should it be static? Reported-by: Hulk Robot <[email protected]> Signed-off-by: Jason Yan <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Juergen Gross <[email protected]>
2020-04-07Merge tag 'drm-next-2020-04-08' of git://anongit.freedesktop.org/drm/drmLinus Torvalds65-227/+538
Pull drm fixes from Dave Airlie: "This is a set of fixes that have queued up, I think I might have another pull with some more before rc1 but I'd like to dequeue what I have now just in case Easter is more eggciting that expected. The main thing in here is a fix for a longstanding nouveau power management issues on certain laptops, it should help runtime suspend/resume for a lot of people. There is also a reverted patch for some drm_mm behaviour in atomic contexts. Summary: core: - revert drm_mm atomic patch - dt binding fixes fbcon: - null ptr error fix i915: - GVT fixes nouveau: - runpm fix - svm fixes amdgpu: - HDCP fixes - gfx10 fix - Misc display fixes - BACO fixes amdkfd: - Fix memory leak vboxvideo: - remove conflicting fbs vc4: - mode validation fix xen: - fix PTR_ERR usage" * tag 'drm-next-2020-04-08' of git://anongit.freedesktop.org/drm/drm: (41 commits) drm/nouveau/kms/nv50-: wait for FIFO space on PIO channels drm/nouveau/nvif: protect waits against GPU falling off the bus drm/nouveau/nvif: access PTIMER through usermode class, if available drm/nouveau/gr/gp107,gp108: implement workaround for HW hanging during init drm/nouveau: workaround runpm fail by disabling PCI power management on certain intel bridges drm/nouveau/svm: remove useless SVM range check drm/nouveau/svm: check for SVM initialized before migrating drm/nouveau/svm: fix vma range check for migration drm/nouveau: remove checks for return value of debugfs functions drm/nouveau/ttm: evict other IO mappings when running out of BAR1 space drm/amdkfd: kfree the wrong pointer drm/amd/display: increase HDCP authentication delay drm/amd/display: Correctly cancel future watchdog and callback events drm/amd/display: Don't try hdcp1.4 when content_type is set to type1 drm/amd/powerplay: move the ASIC specific nbio operation out of smu_v11_0.c drm/amd/powerplay: drop redundant BIF doorbell interrupt operations drm/amd/display: Fix dcn21 num_states drm/amd/display: Enable BT2020 in COLOR_ENCODING property drm/amd/display: LFC not working on 2.0x range monitors (v2) drm/amd/display: Support plane level CTM ...
Powered by cgit, Gruvboxed by Blaster4385.