summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2017-03-01kvm: convert kvm.users_count from atomic_t to refcount_tElena Reshetova
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova <elena.reshetova@intel.com> Signed-off-by: Hans Liljestrand <ishkamiel@gmail.com> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: David Windsor <dwindsor@gmail.com> Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
2017-03-01watchdog: retu: restore MFD dependencyArnd Bergmann
The retu watchdog calls into the respective mfd driver, but fails to link if that is diabled: drivers/watchdog/built-in.o: In function `retu_wdt_set_timeout': ziirave_wdt.c:(.text+0x8c88): undefined reference to `retu_write' ziirave_wdt.c:(.text+0x8c88): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `retu_write' drivers/watchdog/built-in.o: In function `retu_wdt_start': ziirave_wdt.c:(.text+0x8cc8): undefined reference to `retu_write' ziirave_wdt.c:(.text+0x8cc8): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `retu_write' This restores the dependency as it was before Fixes: da2a68b3eb47 ("watchdog: Enable COMPILE_TEST where possible") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-03-01watchdog: db8500: add back prmcu dependencyArnd Bergmann
When the db8500 watchdog is enabled without the PRCMU, we get a lot of warnings about duplicate or missing helper functions: In file included from drivers/watchdog/ux500_wdt.c:21:0: include/linux/mfd/dbx500-prcmu.h:422:19: error: redefinition of 'prcmu_abb_read' static inline int prcmu_abb_read(u8 slave, u8 reg, u8 *value, u8 size) This restores the dependency as it was. Fixes: da2a68b3eb47 ("watchdog: Enable COMPILE_TEST where possible") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-03-01watchdog: kempld: fix gcc-4.3 buildArnd Bergmann
gcc-4.3 can't decide whether the constant value in kempld_prescaler[PRESCALER_21] is built-time constant or not, and gets confused by the logic in do_div(): drivers/watchdog/kempld_wdt.o: In function `kempld_wdt_set_stage_timeout': kempld_wdt.c:(.text.kempld_wdt_set_stage_timeout+0x130): undefined reference to `__aeabi_uldivmod' This adds a call to ACCESS_ONCE() to force it to not consider it to be constant, and leaves the more efficient normal case in place for modern compilers, using an #ifdef to annotate why we do this hack. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-03-01watchdog: softdog: fire watchdog even if softirqs do not get to runNiklas Cassel
Checking for timer expiration is done from the softirq TIMER_SOFTIRQ. Since commit 4cd13c21b207 ("softirq: Let ksoftirqd do its job"), pending softirqs are no longer always handled immediately, instead, if there are pending softirqs, and ksoftirqd is in state TASK_RUNNING, the handling of the softirqs are deferred, and are instead supposed to be handled by ksoftirqd, when ksoftirqd gets scheduled. If a user space process with a real-time policy starts to misbehave by never relinquishing the CPU while ksoftirqd is in state TASK_RUNNING, what will happen is that all softirqs will get deferred, while ksoftirqd, which is supposed to handle the deferred softirqs, will never get to run. To make sure that the watchdog is able to fire even when we do not get to run softirqs, replace the timers with hrtimers. Signed-off-by: Niklas Cassel <niklas.cassel@axis.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-03-01watchdog: kempld: revert to full dependencyArnd Bergmann
The kempld watchdog driver requires the respective MFD driver: drivers/watchdog/built-in.o: In function `kempld_wdt_probe': kempld_wdt.c:(.text+0x5c78): undefined reference to `kempld_get_mutex' kempld_wdt.c:(.text+0x5c84): undefined reference to `kempld_read8' kempld_wdt.c:(.text+0x5c8e): undefined reference to `kempld_release_mutex' kempld_wdt.c:(.text+0x5d1c): undefined reference to `kempld_read8' kempld_wdt.c:(.text+0x5d2c): undefined reference to `kempld_write8' This adds the Kconfig dependency back. Fixes: da2a68b3eb47 ("watchdog: Enable COMPILE_TEST where possible") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-03-01watchdog: bcm2835: add CONFIG_OF dependencyArnd Bergmann
Without CONFIG_OF, the driver fails to link: drivers/watchdog/built-in.o: In function `bcm2835_power_off': bcm2835_wdt.c:(.text+0x1946): undefined reference to `of_find_device_by_node' This adds a new dependency, to allow the COMPILE_TEST check to succeed. Fixes: da2a68b3eb47 ("watchdog: Enable COMPILE_TEST where possible") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-03-01watchdog: sp805: add back AMBA dependencyArnd Bergmann
The driver fails to link if ARM_AMBA is disabled: drivers/watchdog/sp805_wdt.o: In function `sp805_wdt_driver_init': sp805_wdt.c:(.init.text+0x4): undefined reference to `amba_driver_register' It seems that the COMPILE_TEST was added in the wrong place, as there is no architecture dependency, but a bus dependency. This moves the dependency accordingly. Fixes: da2a68b3eb47 ("watchdog: Enable COMPILE_TEST where possible") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-03-01watchdog: menf21bmc: add I2C dependencyArnd Bergmann
This driver fails to link when CONFIG_I2C is disabled or a loadable module while the watchdog is built-in: drivers/watchdog/built-in.o: In function `menf21bmc_wdt_shutdown': menf21bmc_wdt.c:(.text+0x9b44): undefined reference to `i2c_smbus_write_word_data' menf21bmc_wdt.c:(.text+0x9b44): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `i2c_smbus_write_word_data' This adds a Kconfig dependency for it, to enforce a valid configuration. Fixes: da2a68b3eb47 ("watchdog: Enable COMPILE_TEST where possible") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-03-01watchdog: geode: restore hard CS5535_MFGPT dependencyArnd Bergmann
Wtihout CONFIG_CS5535_MFGPT, the driver does not link right: drivers/watchdog/built-in.o: In function `geodewdt_probe': geodewdt.c:(.init.text+0xca3): undefined reference to `cs5535_mfgpt_alloc_timer' geodewdt.c:(.init.text+0xcd4): undefined reference to `cs5535_mfgpt_write' geodewdt.c:(.init.text+0xcef): undefined reference to `cs5535_mfgpt_toggle_event' This adds back the dependency on this base driver. Fixes: da2a68b3eb47 ("watchdog: Enable COMPILE_TEST where possible") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-03-01watchdog: wm831x watchdog really needs mfdArnd Bergmann
The wm831x watchdog driver can now be built without the wm831x mfd driver, which results in a link error: (.text+0x1a95c): undefined reference to `wm831x_set_bits' (.text+0x1a95c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `wm831x_set_bits' (.text+0x1a968): undefined reference to `wm831x_reg_lock' (.text+0x1a968): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `wm831x_reg_lock' (.text+0x1a9dc): undefined reference to `wm831x_reg_unlock' (.text+0x1a9dc): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `wm831x_reg_unlock' This adds back the dependency that was removed. We can still build test this driver on all architectures by enabling the MFD driver for it first. Fixes: da2a68b3eb47 ("watchdog: Enable COMPILE_TEST where possible") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-03-01objtool, compiler.h: Fix __unreachable section relocation sizeJosh Poimboeuf
Linus reported the following commit broke module loading on his laptop: d1091c7fa3d5 ("objtool: Improve detection of BUG() and other dead ends") It showed errors like the following: module: overflow in relocation type 10 val ffffffffc02afc81 module: 'nvme' likely not compiled with -mcmodel=kernel The problem is that the __unreachable section addresses are stored using the '.long' asm directive, which isn't big enough for .text section kernel addresses. Use relative addresses instead: ".long %c0b - .\t\n" Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: d1091c7fa3d5 ("objtool: Improve detection of BUG() and other dead ends") Link: http://lkml.kernel.org/r/20170301060504.oltm3iws6fmubnom@treble Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-03-01KVM: x86: never specify a sample period for virtualized in_tx_cp countersRobert O'Callahan
pmc_reprogram_counter() always sets a sample period based on the value of pmc->counter. However, hsw_hw_config() rejects sample periods less than 2^31 - 1. So for example, if a KVM guest does struct perf_event_attr attr; memset(&attr, 0, sizeof(attr)); attr.type = PERF_TYPE_RAW; attr.size = sizeof(attr); attr.config = 0x2005101c4; // conditional branches retired IN_TXCP attr.sample_period = 0; int fd = syscall(__NR_perf_event_open, &attr, 0, -1, -1, 0); ioctl(fd, PERF_EVENT_IOC_DISABLE, 0); ioctl(fd, PERF_EVENT_IOC_ENABLE, 0); the guest kernel counts some conditional branch events, then updates the virtual PMU register with a nonzero count. The host reaches pmc_reprogram_counter() with nonzero pmc->counter, triggers EOPNOTSUPP in hsw_hw_config(), prints "kvm_pmu: event creation failed" in pmc_reprogram_counter(), and silently (from the guest's point of view) stops counting events. We fix event counting by forcing attr.sample_period to always be zero for in_tx_cp counters. Sampling doesn't work, but it already didn't work and can't be fixed without major changes to the approach in hsw_hw_config(). Signed-off-by: Robert O'Callahan <robert@ocallahan.org> Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
2017-03-01timerfd: Only check CAP_WAKE_ALARM when it is neededStephen Smalley
timerfd_create() and do_timerfd_settime() evaluate capable(CAP_WAKE_ALARM) unconditionally although CAP_WAKE_ALARM is only required for CLOCK_REALTIME_ALARM and CLOCK_BOOTTIME_ALARM. This can cause extraneous audit messages when using a LSM such as SELinux, incorrectly causes PF_SUPERPRIV to be set even when no privilege was exercised, and is inefficient. Flip the order of the tests in both functions so that we only call capable() if the capability is truly required for the operation. Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> Cc: linux-security-module@vger.kernel.org Cc: selinux@tycho.nsa.gov Link: http://lkml.kernel.org/r/1487344439-22293-1-git-send-email-sds@tycho.nsa.gov Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-03-01crypto: testmgr - Pad aes_ccm_enc_tv_template vectorLaura Abbott
Running with KASAN and crypto tests currently gives BUG: KASAN: global-out-of-bounds in __test_aead+0x9d9/0x2200 at addr ffffffff8212fca0 Read of size 16 by task cryptomgr_test/1107 Address belongs to variable 0xffffffff8212fca0 CPU: 0 PID: 1107 Comm: cryptomgr_test Not tainted 4.10.0+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014 Call Trace: dump_stack+0x63/0x8a kasan_report.part.1+0x4a7/0x4e0 ? __test_aead+0x9d9/0x2200 ? crypto_ccm_init_crypt+0x218/0x3c0 [ccm] kasan_report+0x20/0x30 check_memory_region+0x13c/0x1a0 memcpy+0x23/0x50 __test_aead+0x9d9/0x2200 ? kasan_unpoison_shadow+0x35/0x50 ? alg_test_akcipher+0xf0/0xf0 ? crypto_skcipher_init_tfm+0x2e3/0x310 ? crypto_spawn_tfm2+0x37/0x60 ? crypto_ccm_init_tfm+0xa9/0xd0 [ccm] ? crypto_aead_init_tfm+0x7b/0x90 ? crypto_alloc_tfm+0xc4/0x190 test_aead+0x28/0xc0 alg_test_aead+0x54/0xd0 alg_test+0x1eb/0x3d0 ? alg_find_test+0x90/0x90 ? __sched_text_start+0x8/0x8 ? __wake_up_common+0x70/0xb0 cryptomgr_test+0x4d/0x60 kthread+0x173/0x1c0 ? crypto_acomp_scomp_free_ctx+0x60/0x60 ? kthread_create_on_node+0xa0/0xa0 ret_from_fork+0x2c/0x40 Memory state around the buggy address: ffffffff8212fb80: 00 00 00 00 01 fa fa fa fa fa fa fa 00 00 00 00 ffffffff8212fc00: 00 01 fa fa fa fa fa fa 00 00 00 00 01 fa fa fa >ffffffff8212fc80: fa fa fa fa 00 05 fa fa fa fa fa fa 00 00 00 00 ^ ffffffff8212fd00: 01 fa fa fa fa fa fa fa 00 00 00 00 01 fa fa fa ffffffff8212fd80: fa fa fa fa 00 00 00 00 00 05 fa fa fa fa fa fa This always happens on the same IV which is less than 16 bytes. Per Ard, "CCM IVs are 16 bytes, but due to the way they are constructed internally, the final couple of bytes of input IV are dont-cares. Apparently, we do read all 16 bytes, which triggers the KASAN errors." Fix this by padding the IV with null bytes to be at least 16 bytes. Cc: stable@vger.kernel.org Fixes: 0bc5a6c5c79a ("crypto: testmgr - Disable rfc4309 test and convert test vectors") Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Laura Abbott <labbott@redhat.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-03-01crypto: arm/crc32 - add build time test for CRC instruction supportArd Biesheuvel
The accelerated CRC32 module for ARM may use either the scalar CRC32 instructions, the NEON 64x64 to 128 bit polynomial multiplication (vmull.p64) instruction, or both, depending on what the current CPU supports. However, this also requires support in binutils, and as it turns out, versions of binutils exist that support the vmull.p64 instruction but not the crc32 instructions. So refactor the Makefile logic so that this module only gets built if binutils has support for both. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-03-01crypto: arm/crc32 - fix build error with outdated binutilsArd Biesheuvel
Annotate a vmov instruction with an explicit element size of 32 bits. This is inferred by recent toolchains, but apparently, older versions need some help figuring this out. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-03-01x86/boot: Correct setup_header.start_sys nameBorislav Petkov
It is called start_sys_seg elsewhere so rename it to that. It is an obsolete field so we could just as well directly call it __u16 __pad... No functional change. Signed-off-by: Borislav Petkov <bp@suse.de> Link: http://lkml.kernel.org/r/20170221183639.16554-1-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-03-01x86/purgatory: Fix sparse warning, symbol not declaredTobin C. Harding
Sparse emits warning, 'symbol not declared' for a function that has neither file scope nor a forward declaration. The functions only call site is an ASM file. Add a header file with the function declaration. Include the header file in the C source file defining the function in order to fix the sparse warning. Include the header file in ASM file containing the call site to document the usage. Signed-off-by: Tobin C. Harding <me@tobin.cc> Link: http://lkml.kernel.org/r/1487545956-2547-3-git-send-email-me@tobin.cc Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-03-01x86/purgatory: Make functions and variables staticTobin C. Harding
Sparse emits several 'symbol not declared' warnings for various functions and variables. Add static keyword to functions and variables which have file scope only. Signed-off-by: Tobin C. Harding <me@tobin.cc> Link: http://lkml.kernel.org/r/1487545956-2547-2-git-send-email-me@tobin.cc Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-03-01x86/events: Remove last remnants of old filenamesBorislav Petkov
Update to the new file paths, remove them from introductory comments. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20170218113140.8051-1-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-03-01x86/pkeys: Check against max pkey to avoid overflowsDave Hansen
Kirill reported a warning from UBSAN about undefined behavior when using protection keys. He is running on hardware that actually has support for it, which is not widely available. The warning triggers because of very large shifts of integers when doing a pkey_free() of a large, invalid value. This happens because we never check that the pkey "fits" into the mm_pkey_allocation_map(). I do not believe there is any danger here of anything bad happening other than some aliasing issues where somebody could do: pkey_free(35); and the kernel would effectively execute: pkey_free(8); While this might be confusing to an app that was doing something stupid, it has to do something stupid and the effects are limited to the app shooting itself in the foot. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: stable@vger.kernel.org Cc: linux-kselftest@vger.kernel.org Cc: shuah@kernel.org Cc: kirill.shutemov@linux.intel.com Link: http://lkml.kernel.org/r/20170223222603.A022ED65@viggo.jf.intel.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-03-01x86/ioapic: Split IOAPIC hot-removal into two stepsRui Wang
The hot removal of IOAPIC is handling PCI and ACPI removal in one go. That only works when the PCI drivers released the interrupt resources, but breaks when a IOAPIC interrupt is still associated to a PCI device. The new pcibios_release_device() callback allows to solve that problem by splitting the removal into two steps: 1) PCI removal: Release all PCI resources including eventually not yet released IOAPIC interrupts via the new pcibios_release_device() callback. 2) ACPI removal: After release of all PCI resources the ACPI resources can be released without issue. [ tglx: Rewrote changelog ] Signed-off-by: Rui Wang <rui.y.wang@intel.com> Cc: tony.luck@intel.com Cc: linux-pci@vger.kernel.org Cc: rjw@rjwysocki.net Cc: linux-acpi@vger.kernel.org Cc: fengguang.wu@intel.com Cc: helgaas@kernel.org Cc: kbuild-all@01.org Cc: bhelgaas@google.com Link: http://lkml.kernel.org/r/1488288869-31290-3-git-send-email-rui.y.wang@intel.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-03-01x86/PCI: Implement pcibios_release_device to release IRQ from IOAPICRui Wang
The revert of 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()") causes a problem for IOAPIC hotplug. The problem is that IRQs are allocated and freed in pci_enable_device() and pci_disable_device(). But there are some drivers which don't call pci_disable_device(), and they have good reasons not calling it, so if they're using IOAPIC their IRQs won't have a chance to be released from the IOAPIC. When this happens IOAPIC hot-removal fails with a kernel stack dump and an error message like this: [149335.697989] pin16 on IOAPIC2 is still in use. It turns out that we can fix it in a different way without moving IRQ allocation into pcibios_alloc_irq(), thus avoiding the regression of 991de2e59090. We can keep the allocation and freeing of IRQs as is within pci_enable_device()/pci_disable_device(), without breaking any previous assumption of the rest of the system, keeping compatibility with both the legacy and the modern drivers. We can accomplish this by implementing the existing __weak hook of pcibios_release_device() thus when a pci device is about to be deleted we get notified in the hook and take the chance to release its IRQ, if any, from the IOAPIC. Implement pcibios_release_device() for x86 to release any IRQ not released by the driver. Signed-off-by: Rui Wang <rui.y.wang@intel.com> Cc: tony.luck@intel.com Cc: linux-pci@vger.kernel.org Cc: rjw@rjwysocki.net Cc: linux-acpi@vger.kernel.org Cc: fengguang.wu@intel.com Cc: helgaas@kernel.org Cc: kbuild-all@01.org Cc: bhelgaas@google.com Link: http://lkml.kernel.org/r/1488288869-31290-2-git-send-email-rui.y.wang@intel.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-03-01x86/intel_rdt: Remove duplicate inclusion of linux/cpu.hMasanari Iida
Signed-off-by: Masanari Iida <standby24x7@gmail.com> Cc: fenghua.yu@intel.com Link: http://lkml.kernel.org/r/20170227130703.26968-1-standby24x7@gmail.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-03-01x86/vmware: Remove duplicate inclusion of asm/timer.hMasanari Iida
Signed-off-by: Masanari Iida <standby24x7@gmail.com> Cc: akataria@vmware.com Cc: virtualization@lists.linux-foundation.org Link: http://lkml.kernel.org/r/20170227122922.26230-1-standby24x7@gmail.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-03-01x86/hyperv: Hide unused labelArnd Bergmann
This new 32-bit warning just showed up: arch/x86/hyperv/hv_init.c: In function 'hyperv_init': arch/x86/hyperv/hv_init.c:167:1: error: label 'register_msr_cs' defined but not used [-Werror=unused-label] The easiest solution is to move the label up into the existing #ifdef that has the goto. Fixes: dee863b571b0 ("hv: export current Hyper-V clocksource") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Stephen Hemminger <sthemmin@microsoft.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Haiyang Zhang <haiyangz@microsoft.com> Cc: devel@linuxdriverproject.org Cc: Vitaly Kuznetsov <vkuznets@redhat.com> Cc: "K. Y. Srinivasan" <kys@microsoft.com> Link: http://lkml.kernel.org/r/20170214211736.2641241-1-arnd@arndb.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-03-01x86/reboot/quirks: Add ASUS EeeBook X205TA reboot quirkMatjaz Hegedic
Without the parameter reboot=a, ASUS EeeBook X205TA will hang when it should reboot. This adds the appropriate quirk, thus fixing the problem. Signed-off-by: Matjaz Hegedic <matjaz.hegedic@gmail.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-03-01x86/platform/uv/BAU: Fix HUB errors by remove initial write to sw-ack registerAndrew Banman
Writing to the software acknowledge clear register when there are no pending messages causes a HUB error to assert. The original intent of this write was to clear the pending bits before start of operation, but this is an incorrect method and has been determined to be unnecessary. Signed-off-by: Andrew Banman <abanman@hpe.com> Acked-by: Mike Travis <mike.travis@hpe.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: akpm@linux-foundation.org Cc: rja@hpe.com Cc: sivanich@hpe.com Link: http://lkml.kernel.org/r/1487351269-181133-1-git-send-email-abanman@hpe.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-03-01perf/core: Rename CONFIG_[UK]PROBE_EVENT to CONFIG_[UK]PROBE_EVENTSAnton Blanchard
We have uses of CONFIG_UPROBE_EVENT and CONFIG_KPROBE_EVENT as well as CONFIG_UPROBE_EVENTS and CONFIG_KPROBE_EVENTS. Consistently use the plurals. Signed-off-by: Anton Blanchard <anton@samba.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: acme@kernel.org Cc: alexander.shishkin@linux.intel.com Cc: davem@davemloft.net Cc: sparclinux@vger.kernel.org Link: http://lkml.kernel.org/r/20170216060050.20866-1-anton@ozlabs.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-03-01x86/selftests: Add clobbers for int80 on x86_64Dmitry Safonov
Kernel erases R8..R11 registers prior returning to userspace from int80: https://lkml.org/lkml/2009/10/1/164 GCC can reuse these registers and doesn't expect them to change during syscall invocation. I met this kind of bug in CRIU once GCC 6.1 and CLANG stored local variables in those registers and the kernel zerofied them during syscall: https://github.com/xemul/criu/commit/990d33f1a1cdd17bca6c2eb059ab3be2564f7fa2 By that reason I suggest to add those registers to clobbers in selftests. Also, as noted by Andy - removed unneeded clobber for flags in INT $0x80 inline asm. Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com> Acked-by: Andy Lutomirski <luto@kernel.org> Cc: 0x7f454c46@gmail.com Cc: Borislav Petkov <bp@alien8.de> Cc: Borislav Petkov <bp@suse.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Shuah Khan <shuah@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-kselftest@vger.kernel.org Link: http://lkml.kernel.org/r/20170213101336.20486-1-dsafonov@virtuozzo.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-03-01x86/apic: Simplify enable_IR_x2apic(), remove try_to_enable_IR()Dou Liyang
The following commit: 2e63ad4bd5dd ("x86/apic: Do not init irq remapping if ioapic is disabled") ... added a check for skipped IO-APIC setup to enable_IR_x2apic(), but this check is also duplicated in try_to_enable_IR() - and it will never succeed in calling irq_remapping_enable(). Remove the whole irq_remapping_enable() complication: if the IO-APIC is disabled we cannot enable IRQ remapping. Signed-off-by: Dou Liyang <douly.fnst@cn.fujitsu.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: bp@alien8.de Cc: nicstange@gmail.com Cc: wanpeng.li@hotmail.com Link: http://lkml.kernel.org/r/1487841401-1543-1-git-send-email-douly.fnst@cn.fujitsu.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-03-01x86/apic: Fix a warning message in logical CPU IDs allocationDou Liyang
The current warning message in allocate_logical_cpuid() is somewhat confusing: Only 1 processors supported.Processor 2/0x2 and the rest are ignored. As it might imply that there's only one CPU in the system - while what we ran into here is a kernel limitation. Fix the warning message to clarify all that: APIC: NR_CPUS/possible_cpus limit of 2 reached. Processor 2/0x2 and the rest are ignored. ( Also update the error return from -1 to -EINVAL, which is the more canonical return value. ) Signed-off-by: Dou Liyang <douly.fnst@cn.fujitsu.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: bp@alien8.de Cc: nicstange@gmail.com Cc: wanpeng.li@hotmail.com Link: http://lkml.kernel.org/r/1488261052-25753-1-git-send-email-douly.fnst@cn.fujitsu.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-03-01irqchip/crossbar: Fix incorrect type of local variablesFranck Demathieu
The max and entry variables are unsigned according to the dt-bindings. Fix following 3 sparse issues (-Wtypesign): drivers/irqchip/irq-crossbar.c:222:52: warning: incorrect type in argument 3 (different signedness) drivers/irqchip/irq-crossbar.c:222:52: expected unsigned int [usertype] *out_value drivers/irqchip/irq-crossbar.c:222:52: got int *<noident> drivers/irqchip/irq-crossbar.c:245:56: warning: incorrect type in argument 4 (different signedness) drivers/irqchip/irq-crossbar.c:245:56: expected unsigned int [usertype] *out_value drivers/irqchip/irq-crossbar.c:245:56: got int *<noident> drivers/irqchip/irq-crossbar.c:263:56: warning: incorrect type in argument 4 (different signedness) drivers/irqchip/irq-crossbar.c:263:56: expected unsigned int [usertype] *out_value drivers/irqchip/irq-crossbar.c:263:56: got int *<noident> Signed-off-by: Franck Demathieu <fdemathieu@gmail.com> Cc: marc.zyngier@arm.com Cc: jason@lakedaemon.net Link: http://lkml.kernel.org/r/20170223094855.6546-1-fdemathieu@gmail.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-03-01x86/kdebugfs: Move boot params hierarchy under (debugfs)/x86/Borislav Petkov
... since this is all x86-specific data and it makes sense to have it under x86/ logically instead in the toplevel debugfs dir. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20170227225058.27289-1-bp@alien8.de Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-03-01kprobes/x86: Fix kernel panic when certain exception-handling addresses are ↵Masami Hiramatsu
probed Fix to the exception table entry check by using probed address instead of the address of copied instruction. This bug may cause unexpected kernel panic if user probe an address where an exception can happen which should be fixup by __ex_table (e.g. copy_from_user.) Unless user puts a kprobe on such address, this doesn't cause any problem. This bug has been introduced years ago, by commit: 464846888d9a ("x86/kprobes: Fix a bug which can modify kernel code permanently"). Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: 464846888d9a ("x86/kprobes: Fix a bug which can modify kernel code permanently") Link: http://lkml.kernel.org/r/148829899399.28855.12581062400757221722.stgit@devbox Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-03-01nfit, libnvdimm: fix interleave set cookie calculationDan Williams
The interleave-set cookie is a sum that sanity checks the composition of an interleave set has not changed from when the namespace was initially created. The checksum is calculated by sorting the DIMMs by their location in the interleave-set. The comparison for the sort must be 64-bit wide, not byte-by-byte as performed by memcmp() in the broken case. Fix the implementation to accept correct cookie values in addition to the Linux "memcmp" order cookies, but only allow correct cookies to be generated going forward. It does mean that namespaces created by third-party-tooling, or created by newer kernels with this fix, will not validate on older kernels. However, there are a couple mitigating conditions: 1/ platforms with namespace-label capable NVDIMMs are not widely available. 2/ interleave-sets with a single-dimm are by definition not affected (nothing to sort). This covers the QEMU-KVM NVDIMM emulation case. The cookie stored in the namespace label will be fixed by any write the namespace label, the most straightforward way to achieve this is to write to the "alt_name" attribute of a namespace in sysfs. Cc: <stable@vger.kernel.org> Fixes: eaf961536e16 ("libnvdimm, nfit: add interleave-set state-tracking infrastructure") Reported-by: Nicholas Moulin <nicholas.w.moulin@linux.intel.com> Tested-by: Nicholas Moulin <nicholas.w.moulin@linux.intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2017-03-01locking/refcounts: Change WARN() to WARN_ONCE()Ingo Molnar
Linus noticed that the new refcount.h APIs used WARN(), which would turn into a dmesg DoS if it triggers frequently on some buggy driver. So make sure we only warn once. These warnings are never supposed to happen, so it's typically not a problem to lose subsequent warnings. Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Elena Reshetova <elena.reshetova@intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/CA+55aFzbYUTZ=oqZ2YgDjY0C2_n6ODhTfqj6V+m5xWmDxsuB0w@mail.gmail.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-03-01staging: fsl-mc: fix warning in DT ranges parserArnd Bergmann
The fsl-mc-bus driver in staging contains a copy of the standard 'ranges' property parsing algorithm with a hack to treat a missing property the same way as an empty one. This code produces false-positive warnings for me in an allmodconfig build: drivers/staging/fsl-mc/bus/fsl-mc-bus.c: In function 'fsl_mc_bus_probe': drivers/staging/fsl-mc/bus/fsl-mc-bus.c:645:6: error: 'mc_size_cells' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/staging/fsl-mc/bus/fsl-mc-bus.c:682:8: error: 'mc_addr_cells' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/staging/fsl-mc/bus/fsl-mc-bus.c:644:6: note: 'mc_addr_cells' was declared here drivers/staging/fsl-mc/bus/fsl-mc-bus.c:684:8: error: 'paddr_cells' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/staging/fsl-mc/bus/fsl-mc-bus.c:643:6: note: 'paddr_cells' was declared here To avoid the warnings, I'm simplifying the argument handling to pass the number of valid ranges in the property as the function return code rather than passing it by reference. With this change, gcc can see that we don't evaluate the cell numbers for an missing ranges property. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Laurentiu Tudor <laurentiu.tudor@nxp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-01MAINTAINERS: Remove Noralf Trønnes as fbtft maintainerNoralf Trønnes
Due to personal reasons I'm unable to continue as fbtft maintainer. Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-01tools/testing/nvdimm: make iset cookie predictableDan Williams
For testing changes to the iset cookie algorithm we need a value that is constant from run-to-run. Stop including dynamic data in the emulated region_offset values. Also, pick values that sort in a different order depending on whether the comparison is a memcmp() of two 8-byte arrays or subtraction of two 64-bit values. Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2017-03-01tools/power turbostat: version 17.02.24Len Brown
The turbostat before this last set of changes is obsolete. This new version can do a lot more, but it also has some different defaults, that might catch some off-guard. So it seems a good time to give a new version number. Signed-off-by: Len Brown <len.brown@intel.com>
2017-03-01tools/power turbostat: bugfix: --add u32 was printed as u64Len Brown
When the "u32" keyword is used with --add, it means that the output should be truncated to 32-bits. This was not happening and all 64-bits were printed. Also, when no column name was used for an added MSR, The default column name was in deximal, eg. MSR16. Users report that they tend to use hex MSR numbers, so print them in hex. To always fit into the columns, use the syntax M0x10. Note that the user can always supply any column header that they want. eg --add msr0x10,MY_TSC Signed-off-by: Len Brown <len.brown@intel.com>
2017-03-01tools/power turbostat: show error on execLen Brown
When turbostat is run in one-shot command mode, the parent takes the 'before' counter snapshot, fork/exec/wait for the child to exit, takes the 'after' counter snapshot, and prints the results. however, if the child fails to exec the command, it immediately returns, without indicating that anythign was wrong. Add an error message showing that exec failed: sudo turbostat sleeeep 4 ... turbostat: exec sleeeep: No such file or directory ... Note that the parent will still print out the statistics, because it can't tell the difference between the failed exec and a command that is purposefully returning the same status. Unfortunately, this may obscure the error message. However, if the --out parameter is used, the error message is evident on stderr. Reported-by: Wendy Wang <wendy.wang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2017-03-01tools/power turbostat: dump p-state software configLen Brown
cpu1: cpufreq driver: acpi-cpufreq cpu1: cpufreq governor: ondemand cpufreq boost: 1 or cpu0: cpufreq driver: intel_pstate cpu0: cpufreq governor: powersave cpufreq intel_pstate no_turbo: 0 Signed-off-by: Len Brown <len.brown@intel.com>
2017-03-01tools/power turbostat: show package number, even without --debugLen Brown
On multi-package systems, the "Package" column was being displayed only if --debug was used. Show it always. Signed-off-by: Len Brown <len.brown@intel.com>
2017-03-01tools/power turbostat: support "--hide C1" etc.Len Brown
Originally, the only way to hide the sysfs C-state statistics columns was with "--hide sysfs". This was because we process "--hide" before we probe for those columns. hack --hide to remember deferred hide requests, and apply them when sysfs is probed. "--hide sysfs" is still available as short-hand to refer to the entire group of counters. The down-side of this change is that we no longer error check for bogus --hide column names. But the user will quickly figure that out if a column they mean to hide is still there... Signed-off-by: Len Brown <len.brown@intel.com>
2017-03-01tools/power turbostat: move --Package and --processor into the --cpu optionLen Brown
--Package is now "--cpu package", which will display just the 1st CPU in each package --processor is not "--cpu core" which will display just the 1st CPU in each core Signed-off-by: Len Brown <len.brown@intel.com>
2017-03-01tools/power turbostat: turbostat.8 updateLen Brown
update examples to show recently updated features. In particular --add --show --hide --cpu --list Signed-off-by: Len Brown <len.brown@intel.com>
2017-03-01tools/power turbostat: update --list featureLen Brown
Make it possible to take the entire un-edited output from `turbostat --list` and feed it to "turbostat --show" or "turbostat --hide". To do this, the leading comma was removed (no mater what columns are active) and also they dynamic C-state "C1, C2, C3" etc are replaced by the string "sysfs", which refers to them as a group. Signed-off-by: Len Brown <len.brown@intel.com>
generated by cgit (git 2.34.1) at 2025-09-12 05:15:21 +0000