aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2018-06-22irqdesc: Delete irq_desc_get_msi_desc()John Garry1-5/+0
Function irq_desc_get_msi_desc() is not referenced in the kernel (and does not seem to have been referenced since e39758e0ea76, 3 years ago), so delete it. Signed-off-by: John Garry <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: <[email protected]> Cc: <[email protected]> Cc: <[email protected]> Cc: <[email protected]> Cc: <[email protected]> Cc: <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2018-06-22irqchip/gic-v3-its: Fix reprogramming of redistributors on CPU hotplugMarc Zyngier1-0/+10
Enabling LPIs was made a lot stricter recently, by checking that they are disabled before enabling them. By doing so, the CPU hotplug case was missed altogether, which leaves LPIs enabled on hotplug off (expecting the CPU to eventually come back), and won't write a different value anyway on hotplug on. So skip that check if that particular case is detected Fixes: 6eb486b66a30 ("irqchip/gic-v3: Ensure GICR_CTLR.EnableLPI=0 is observed before enabling") Reported-by: Sumit Garg <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Sumit Garg <[email protected]> Cc: Jason Cooper <[email protected]> Cc: Alexandre Belloni <[email protected]> Cc: Yang Yingliang <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2018-06-22irqchip/gic-v3-its: Only emit VSYNC if targetting a valid collectionMarc Zyngier1-5/+13
Similarily to the SYNC operation, it must be verified that the VPE targetted by a VLPI is backed by a valid collection in the GIC driver data structures. Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: Jason Cooper <[email protected]> Cc: Alexandre Belloni <[email protected]> Cc: Yang Yingliang <[email protected]> Cc: Sumit Garg <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2018-06-22irqchip/gic-v3-its: Only emit SYNC if targetting a valid collectionMarc Zyngier1-6/+19
It is possible, under obscure circumstances, to convince the ITS driver to emit a SYNC operation that targets a collection that is not bound to any redistributor (and the target_address field is zero) because the corresponding CPU has not been seen yet (the system has been booted with max_cpus="something small"). If the ITS is using the linear CPU number as the target, this is not a big deal, as we just end-up issuing a SYNC to CPU0. But if the ITS requires the physical address of the redistributor (with GITS_TYPER.PTA==1), we end-up asking the ITS to write to the physical address zero, which is not exactly a good idea (there has been report of the ITS locking up). This should of course never happen, but hey, this is SW... In order to avoid the above disaster, let's track which collections have been actually initialized, and let's not generate a SYNC if the collection hasn't been properly bound to a redistributor. Take this opportunity to spit our a warning, in the hope that someone may report the issue if it arrises again. Reported-by: Yang Yingliang <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: Jason Cooper <[email protected]> Cc: Alexandre Belloni <[email protected]> Cc: Sumit Garg <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2018-06-22irqchip/gic-v3-its: Don't bind LPI to unavailable NUMA nodeYang Yingliang1-1/+8
On a NUMA system, if an ITS is local to an offline node, the ITS driver may pick an offline CPU to bind the LPI. In this case, pick an online CPU (and the first one will do). But on some systems, binding an LPI to non-local node CPU may cause deadlock (see Cavium erratum 23144). In this case, just fail the activate and return an error code. Signed-off-by: Yang Yingliang <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: Jason Cooper <[email protected]> Cc: Alexandre Belloni <[email protected]> Cc: Sumit Garg <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected]
2018-06-22irqchip/gic-v2m: Fix SPI release on error pathMarc Zyngier1-1/+1
On failing to allocate the required SPIs, the actual number of interrupts should be freed and not its log2 value. Fixes: de337ee30142 ("irqchip/gic-v2m: Add PCI Multi-MSI support") Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: Jason Cooper <[email protected]> Cc: Alexandre Belloni <[email protected]> Cc: Yang Yingliang <[email protected]> Cc: Sumit Garg <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2018-06-22irqchip/ls-scfg-msi: Fix MSI affinity handlingMarc Zyngier1-3/+7
The ls-scfs-msi driver is not dealing with the effective affinity as it should. Let's fix that, and make it clear that the effective affinity is restricted to a single CPU. Also prevent the driver from messing with the internals of the affinity setting infrastructure. Reported-by: Alexandre Belloni <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Alexandre Belloni <[email protected]> Cc: Jason Cooper <[email protected]> Cc: Yang Yingliang <[email protected]> Cc: Sumit Garg <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2018-06-22genirq/debugfs: Add missing IRQCHIP_SUPPORTS_LEVEL_MSI debugMarc Zyngier2-0/+2
Debug is missing the IRQCHIP_SUPPORTS_LEVEL_MSI debug entry, making debugfs slightly less useful. Take this opportunity to also add a missing comment in the definition of IRQCHIP_SUPPORTS_LEVEL_MSI. Fixes: 6988e0e0d283 ("genirq/msi: Limit level-triggered MSI to platform devices") Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: Jason Cooper <[email protected]> Cc: Alexandre Belloni <[email protected]> Cc: Yang Yingliang <[email protected]> Cc: Sumit Garg <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2018-06-22perf/core: Move the inline keyword at the beginning of the function declarationMathieu Malaterre1-3/+3
When building perf with W=1 the following warning triggers: CC kernel/events/ring_buffer.o kernel/events/ring_buffer.c:105:1: warning: ‘inline’ is not at beginning of declaration [-Wold-style-declaration] static bool __always_inline ^~~~~~ ... Move the inline keyword to the beginning of the function declaration. Signed-off-by: Mathieu Malaterre <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2018-06-22Merge tag 'for_v4.18-rc2' of ↵Linus Torvalds8-34/+25
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs Pull udf, quota, ext2 fixes from Jan Kara: "UDF: - fix an oops due to corrupted disk image - two small cleanups quota: - a fixfor lru handling - cleanup ext2: - a warning about a deprecated mount option" * tag 'for_v4.18-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs: udf: Drop unused arguments of udf_delete_aext() udf: Provide function for calculating dir entry length udf: Detect incorrect directory size ext2: add warning when specifying nocheck option quota: Cleanup list iteration in dqcache_shrink_scan() quota: reclaim least recently used dquots
2018-06-22efi/libstub/tpm: Initialize efi_physical_addr_t vars to zero for mixed modeHans de Goede1-1/+1
Commit: 79832f0b5f71 ("efi/libstub/tpm: Initialize pointer variables to zero for mixed mode") fixes a problem with the tpm code on mixed mode (64-bit kernel on 32-bit UEFI), where 64-bit pointer variables are not fully initialized by the 32-bit EFI code. A similar problem applies to the efi_physical_addr_t variables which are written by the ->get_event_log() EFI call. Even though efi_physical_addr_t is 64-bit everywhere, it seems that some 32-bit UEFI implementations only fill in the lower 32 bits when passed a pointer to an efi_physical_addr_t to fill. This commit initializes these to 0 to, to ensure the upper 32 bits are 0 in mixed mode. This fixes recent kernels sometimes hanging during early boot on mixed mode UEFI systems. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Cc: <[email protected]> # v4.16+ Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2018-06-22xen: Remove unnecessary BUG_ON from __unbind_from_irq()Boris Ostrovsky1-2/+0
Commit 910f8befdf5b ("xen/pirq: fix error path cleanup when binding MSIs") fixed a couple of errors in error cleanup path of xen_bind_pirq_msi_to_irq(). This cleanup allowed a call to __unbind_from_irq() with an unbound irq, which would result in triggering the BUG_ON there. Since there is really no reason for the BUG_ON (xen_free_irq() can operate on unbound irqs) we can remove it. Reported-by: Ben Hutchings <[email protected]> Signed-off-by: Boris Ostrovsky <[email protected]> Cc: [email protected] Reviewed-by: Juergen Gross <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2018-06-22xen: add new hypercall buffer mapping deviceJuergen Gross4-1/+223
For passing arbitrary data from user land to the Xen hypervisor the Xen tools today are using mlock()ed buffers. Unfortunately the kernel might change access rights of such buffers for brief periods of time e.g. for page migration or compaction, leading to access faults in the hypervisor, as the hypervisor can't use the locks of the kernel. In order to solve this problem add a new device node to the Xen privcmd driver to easily allocate hypercall buffers via mmap(). The memory is allocated in the kernel and just mapped into user space. Marked as VM_IO the user mapping will not be subject to page migration et al. Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2018-06-22Merge tag 'drm-fixes-2018-06-22' of git://anongit.freedesktop.org/drm/drmLinus Torvalds31-337/+408
Pull drm fixes from Dave Airlie: "Just run of the mill fixes, core: - regression fix in device unplug qxl: - regression fix for might sleep in cursor handling nouveau: - regression fix in multi-screen cursor handling amdgpu: - switch off DC by default on Kaveri and older - some minor fixes i915: - some GEM regression fixes - doublescan mode fixes sun4i: - revert fix for a regression sii8620 bridge: - misc fixes" * tag 'drm-fixes-2018-06-22' of git://anongit.freedesktop.org/drm/drm: (28 commits) drm/bridge/sii8620: fix display of packed pixel modes in MHL2 drm/amdgpu: Make amdgpu_vram_mgr_bo_invisible_size always accurate drm/amdgpu: Refactor amdgpu_vram_mgr_bo_invisible_size helper drm/amdgpu: Update pin_size values before unpinning BO drm/amdgpu:All UVD instances share one idle_work handle drm/amdgpu: Don't default to DC support for Kaveri and older drm/amdgpu: Use kvmalloc_array for allocating VRAM manager nodes array drm/amd/pp: Fix uninitialized variable drm/i915: Enable provoking vertex fix on Gen9 systems. drm/i915: Fix context ban and hang accounting for client drm/i915: Turn off g4x DP port in .post_disable() drm/i915: Disallow interlaced modes on g4x DP outputs drm/i915: Fix PIPESTAT irq ack on i965/g4x drm/i915: Allow DBLSCAN user modes with eDP/LVDS/DSI drm/i915/execlists: Avoid putting the error pointer drm/i915: Apply batch location restrictions before pinning drm/nouveau/kms/nv50-: cursors always use core channel vram ctxdma Revert "drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE" drm/atmel-hlcdc: check stride values in the first plane drm/bridge/sii8620: fix HDMI cable connection to dongle ...
2018-06-22locking/qspinlock: Fix build for anonymous union in older GCC compilersSteven Rostedt (VMware)1-1/+1
One of my tests compiles the kernel with gcc 4.5.3, and I hit the following build error: include/linux/semaphore.h: In function 'sema_init': include/linux/semaphore.h:35:17: error: unknown field 'val' specified in initializer include/linux/semaphore.h:35:17: warning: missing braces around initializer include/linux/semaphore.h:35:17: warning: (near initialization for '(anonymous).raw_lock.<anonymous>.val') I bisected it down to: 625e88be1f41 ("locking/qspinlock: Merge 'struct __qspinlock' into 'struct qspinlock'") ... which makes qspinlock have an anonymous union, which makes initializing it special for older compilers. By adding strategic brackets, it makes the build happy again. Signed-off-by: Steven Rostedt (VMware) <[email protected]> Acked-by: Waiman Long <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Boqun Feng <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra (Intel) <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Will Deacon <[email protected]> Cc: [email protected] Fixes: 625e88be1f41 ("locking/qspinlock: Merge 'struct __qspinlock' into 'struct qspinlock'") Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2018-06-22Merge tag 'drm-misc-fixes-2018-06-21' of ↵Dave Airlie3-218/+118
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Fixes for v4.18-rc2: - A reversion of a commit in drm/sun4i to fix a run-time fault. - Various fixes to the sii8620 bridge. - Small bugfix to correctly check stride in atmel-hlcdc. Signed-off-by: Dave Airlie <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-06-22Merge tag 'drm-intel-fixes-2018-06-21' of ↵Dave Airlie17-77/+204
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes drm/i915 fixes for v4.18-rc2: - Mostly cc: stable display fixes, including a DBLSCAN regression fix - GEM fixes for this merge window Signed-off-by: Dave Airlie <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-06-22Merge tag 'nfs-for-4.18-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfsLinus Torvalds6-16/+59
Pull NFS client bugfixes from Trond Myklebust: "Hightlights include: - fix an rcu deadlock in nfs_delegation_find_inode() - fix NFSv4 deadlocks due to not freeing the session slot in layoutget - don't send layoutreturn if the layout is already invalid - prevent duplicate XID allocation - flexfiles: Don't tie up all the rpciod threads in resends" * tag 'nfs-for-4.18-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfs: pNFS/flexfiles: Process writeback resends from nfsiod context as well pNFS/flexfiles: Don't tie up all the rpciod threads in resends sunrpc: Prevent duplicate XID allocation pNFS: Don't send layoutreturn if the layout is already invalid pNFS: Always free the session slot on error in nfs4_layoutget_handle_exception NFS: Fix an rcu deadlock in nfs_delegation_find_inode()
2018-06-22Merge tag 'pinctrl-v4.18-2' of ↵Linus Torvalds5-12/+22
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control fixes from Linus Walleij: "Some fallout in the pin control subsystem in the first week after the merge window, some minor fixes so I'd like to get it to you ASAP. - fix a serious kernel panic on the Mediatek driver with the external interrupt controller. - fix an uninitialized compiler warning in the owl (actions) driver. - allocation failure in the pinctrl-single driver. - pointer overwrite problem in the i.MX driver. - fix a small compiler warning" * tag 'pinctrl-v4.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: pinctrl: mt7622: fix a kernel panic when pio don't work as EINT controller pinctrl: actions: Fix uninitialized error in owl_pin_config_set() pinctrl: single: Add allocation failure checking of saved_vals pinctrl: devicetree: Fix pctldev pointer overwrite pinctrl: mediatek: remove redundant return value check of platform_get_resource()
2018-06-22Merge tag 'hwmon-for-linus-v4.18-rc2' of ↵Linus Torvalds2-1/+8
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon fixes from Guenter Roeck: - fix a loop limit in nct6775 driver - disable fan support for Dell XPS13 9333 * tag 'hwmon-for-linus-v4.18-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (nct6775) Fix loop limit hwmon: (dell-smm) Disable fan support for Dell XPS13 9333
2018-06-22Merge tag 'acpi-4.18-rc2' of ↵Linus Torvalds3-9/+32
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI fixes from Rafael Wysocki: "These fix a suspend/resume regression in the ACPI driver for Intel SoCs (LPSS), add a new system wakeup quirk to the ACPI EC driver and fix an inline stub of a function in the ACPI processor driver that diverged from the original. Specifics: - Fix a suspend/resume regression in the ACPI driver for Intel SoCs (LPSS) to make it work on systems where some power management quirks should only be applied for runtime PM and suspend-to-idle and not for suspend-to-RAM (Rafael Wysocki). - Add a system wakeup quirk for Thinkpad X1 Carbon 6th to the ACPI EC driver to avoid drainig battery too fast while suspended to idle on those systems (Mika Westerberg). - Fix an inline stub of acpi_processor_ppc_has_changed() to match the original function definition (Brian Norris)" * tag 'acpi-4.18-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI / processor: Finish making acpi_processor_ppc_has_changed() void ACPI / EC: Use ec_no_wakeup on Thinkpad X1 Carbon 6th ACPI / LPSS: Avoid PM quirks on suspend and resume from S3
2018-06-22Merge tag 'pm-4.18-rc2' of ↵Linus Torvalds7-89/+224
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management updates from Rafael Wysocki: "These are mostly fixes, including some fixes for changes made during the recent merge window and some "stable" material, plus some minor extensions of the turbostat utility. Specifics: - Fix the PM core to avoid introducing a runtime PM usage counter imbalance when adding device links during driver probe (Rafael Wysocki). - Fix the operating performance points (OPP) framework to ensure that the regulator voltage is always updated as appropriate when updating clock rates (Waldemar Rymarkiewicz). - Fix the intel_pstate driver to use correct max/min limits for cores with differing maximum frequences (Srinivas Pandruvada). - Fix a typo in the intel_pstate driver documentation (Rafael Wysocki). - Fix two issues with the recently added Kryo cpufreq driver (Ilia Lin). - Fix two recent regressions and some other minor issues in the turbostat utility and extend it to provide some more diagnostic information (Len Brown, Nathan Ciobanu)" * tag 'pm-4.18-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: Documentation: intel_pstate: Fix typo tools/power turbostat: version 18.06.20 tools/power turbostat: add the missing command line switches tools/power turbostat: add single character tokens to help tools/power turbostat: alphabetize the help output tools/power turbostat: fix segfault on 'no node' machines tools/power turbostat: add optional APIC X2APIC columns tools/power turbostat: decode cpuid.1.HT tools/power turbostat: fix show/hide issues resulting from mis-merge PM / OPP: Update voltage in case freq == old_freq cpufreq: intel_pstate: Fix scaling max/min limits with Turbo 3.0 cpufreq: kryo: Add module remove and exit cpufreq: kryo: Fix possible error code dereference PM / core: Fix supplier device runtime PM usage counter imbalance
2018-06-21tracing: Fix SKIP_STACK_VALIDATION=1 build due to bad merge with -mrecord-mcountGreg Thelen1-1/+1
Non gcc-5 builds with CONFIG_STACK_VALIDATION=y and SKIP_STACK_VALIDATION=1 fail. Example output: /bin/sh: init/.tmp_main.o: Permission denied commit 96f60dfa5819 ("trace: Use -mcount-record for dynamic ftrace"), added a mismatched endif. This causes cmd_objtool to get mistakenly set. Relocate endif to balance the newly added -record-mcount check. Link: http://lkml.kernel.org/r/[email protected] Fixes: 96f60dfa5819 ("trace: Use -mcount-record for dynamic ftrace") Acked-by: Andi Kleen <[email protected]> Tested-by: David Rientjes <[email protected]> Signed-off-by: Greg Thelen <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2018-06-21tracing: Fix some errors in histogram documentationJoel Fernandes (Google)1-11/+12
Fix typos, inconsistencies in using quotes, incorrect section number, etc. in the trace histogram documentation. Link: http://lkml.kernel.org/r/[email protected] Reviewed-by: Masami Hiramatsu <[email protected]> Acked-by: Tom Zanussi <[email protected]> Signed-off-by: Joel Fernandes (Google) <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2018-06-21tracing: Use swap macro in update_max_trGustavo A. R. Silva1-5/+1
Make use of the swap macro and remove unnecessary variable _buf_. This makes the code easier to read and maintain. Also, reduces the stack usage. This code was detected with the help of Coccinelle. Link: http://lkml.kernel.org/r/20180209175316.GA18720@embeddedgus Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2018-06-21softirq: Reorder trace_softirqs_on to prevent lockdep splatJoel Fernandes (Google)1-1/+5
I'm able to reproduce a lockdep splat with config options: CONFIG_PROVE_LOCKING=y, CONFIG_DEBUG_LOCK_ALLOC=y and CONFIG_PREEMPTIRQ_EVENTS=y $ echo 1 > /d/tracing/events/preemptirq/preempt_enable/enable [ 26.112609] DEBUG_LOCKS_WARN_ON(current->softirqs_enabled) [ 26.112636] WARNING: CPU: 0 PID: 118 at kernel/locking/lockdep.c:3854 [...] [ 26.144229] Call Trace: [ 26.144926] <IRQ> [ 26.145506] lock_acquire+0x55/0x1b0 [ 26.146499] ? __do_softirq+0x46f/0x4d9 [ 26.147571] ? __do_softirq+0x46f/0x4d9 [ 26.148646] trace_preempt_on+0x8f/0x240 [ 26.149744] ? trace_preempt_on+0x4d/0x240 [ 26.150862] ? __do_softirq+0x46f/0x4d9 [ 26.151930] preempt_count_sub+0x18a/0x1a0 [ 26.152985] __do_softirq+0x46f/0x4d9 [ 26.153937] irq_exit+0x68/0xe0 [ 26.154755] smp_apic_timer_interrupt+0x271/0x280 [ 26.156056] apic_timer_interrupt+0xf/0x20 [ 26.157105] </IRQ> The issue was this: preempt_count = 1 << SOFTIRQ_SHIFT __local_bh_enable(cnt = 1 << SOFTIRQ_SHIFT) { if (softirq_count() == (cnt && SOFTIRQ_MASK)) { trace_softirqs_on() { current->softirqs_enabled = 1; } } preempt_count_sub(cnt) { trace_preempt_on() { tracepoint() { rcu_read_lock_sched() { // jumps into lockdep Where preempt_count still has softirqs disabled, but current->softirqs_enabled is true, and we get a splat. Link: http://lkml.kernel.org/r/[email protected] Cc: Peter Zijlstra <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Cc: Tom Zanussi <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Thomas Glexiner <[email protected]> Cc: Boqun Feng <[email protected]> Cc: Paul McKenney <[email protected]> Cc: Masami Hiramatsu <[email protected]> Cc: Todd Kjos <[email protected]> Cc: Erick Reyes <[email protected]> Cc: Julia Cartwright <[email protected]> Cc: Byungchul Park <[email protected]> Cc: [email protected] Reviewed-by: Steven Rostedt (VMware) <[email protected]> Fixes: d59158162e032 ("tracing: Add support for preempt and irq enable/disable events") Signed-off-by: Joel Fernandes (Google) <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2018-06-21tracing: Check for no filter when processing event filtersSteven Rostedt (VMware)1-1/+9
The syzkaller detected a out-of-bounds issue with the events filter code, specifically here: prog[N].pred = NULL; /* #13 */ prog[N].target = 1; /* TRUE */ prog[N+1].pred = NULL; prog[N+1].target = 0; /* FALSE */ -> prog[N-1].target = N; prog[N-1].when_to_branch = false; As that's the first reference to a "N-1" index, it appears that the code got here with N = 0, which means the filter parser found no filter to parse (which shouldn't ever happen, but apparently it did). Add a new error to the parsing code that will check to make sure that N is not zero before going into this part of the code. If N = 0, then -EINVAL is returned, and a error message is added to the filter. Cc: [email protected] Fixes: 80765597bc587 ("tracing: Rewrite filter logic to be simpler and faster") Reported-by: air icy <[email protected]> bugzilla url: https://bugzilla.kernel.org/show_bug.cgi?id=200019 Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2018-06-21nvme-pci: limit max IO size and segments to avoid high order allocationsJens Axboe3-5/+39
nvme requires an sg table allocation for each request. If the request is large, then the allocation can become quite large. For instance, with our default software settings of 1280KB IO size, we'll need 10248 bytes of sg table. That turns into a 2nd order allocation, which we can't always guarantee. If we fail the allocation, blk-mq will retry it later. But there's no guarantee that we'll EVER be able to allocate that much contigious memory. Limit the IO size such that we never need more than a single page of memory. That's a lot faster and more reliable. Then back that allocation with a mempool, so that we know we'll always be able to succeed the allocation at some point. Signed-off-by: Jens Axboe <[email protected]> Acked-by: Keith Busch <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2018-06-21locking/lockdep: Do not record IRQ state within lockdep codeSteven Rostedt (VMware)1-6/+6
While debugging where things were going wrong with mapping enabling/disabling interrupts with the lockdep state and actual real enabling and disabling interrupts, I had to silent the IRQ disabling/enabling in debug_check_no_locks_freed() because it was always showing up as it was called before the splat was. Use raw_local_irq_save/restore() for not only debug_check_no_locks_freed() but for all internal lockdep functions, as they hide useful information about where interrupts were used incorrectly last. Signed-off-by: Steven Rostedt (VMware) <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Paul E. McKenney <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Will Deacon <[email protected]> Link: https://lkml.kernel.org/lkml/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2018-06-21KVM: arm64: Prevent KVM_COMPAT from being selectedMarc Zyngier1-1/+1
There is very little point in trying to support the 32bit KVM/arm API on arm64, and this was never an anticipated use case. Let's make it clear by not selecting KVM_COMPAT. Acked-by: Mark Rutland <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2018-06-21KVM: Enforce error in ioctl for compat tasks when !KVM_COMPATMarc Zyngier1-10/+9
The current behaviour of the compat ioctls is a bit odd. We provide a compat_ioctl method when KVM_COMPAT is set, and NULL otherwise. But NULL means that the normal, non-compat ioctl should be used directly for compat tasks, and there is no way to actually prevent a compat task from issueing KVM ioctls. This patch changes this behaviour, by always registering a compat_ioctl method, even if KVM_COMPAT is not selected. In that case, the callback will always return -EINVAL. Fixes: de8e5d744051568c8aad ("KVM: Disable compat ioctl for s390") Reported-by: Mark Rutland <[email protected]> Acked-by: Christian Borntraeger <[email protected]> Acked-by: Radim Krčmář <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2018-06-21kernel.h: Fix a typo in commentWei Wang1-1/+1
Signed-off-by: Wei Wang <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Crt Mori <[email protected]> Cc: Josh Poimboeuf <[email protected]> Cc: Kees Cook <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Randy Dunlap <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Cc: [email protected] Link: https://lkml.kernel.org/lkml/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2018-06-21uprobes/x86: Remove incorrect WARN_ON() in uprobe_init_insn()Oleg Nesterov1-1/+1
insn_get_length() has the side-effect of processing the entire instruction but only if it was decoded successfully, otherwise insn_complete() can fail and in this case we need to just return an error without warning. Reported-by: [email protected] Signed-off-by: Oleg Nesterov <[email protected]> Reviewed-by: Masami Hiramatsu <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/lkml/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2018-06-21nvme-pci: move nvme_kill_queues to nvme_remove_dead_ctrlJianchao Wang1-1/+1
There is race between nvme_remove and nvme_reset_work that can lead to io hang. nvme_remove nvme_reset_work -> nvme_remove_dead_ctrl -> nvme_dev_disable -> quiesce request_queue -> queue remove_work -> cancel_work_sync reset_work -> nvme_remove_namespaces -> splice ctrl->namespaces nvme_remove_dead_ctrl_work -> nvme_kill_queues -> nvme_ns_remove do nothing -> blk_cleanup_queue -> blk_freeze_queue Finally, the request_queue is quiesced state when wait freeze, we will get io hang here. To fix it, move the nvme_kill_queues from nvme_remove_dead_ctrl_work to nvme_remove_dead_ctrl. Suggested-by: Keith Busch <[email protected]> Signed-off-by: Jianchao Wang <[email protected]> Reviewed-by: Keith Busch <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2018-06-21x86/platform/UV: Add kernel parameter to set memory block size[email protected]1-0/+11
Add a kernel parameter that allows setting UV memory block size. This is to provide an adjustment for new forms of PMEM and other DIMM memory that might require alignment restrictions other than scanning the global address table for the required minimum alignment. The value set will be further adjusted by both the GAM range table scan as well as restrictions imposed by set_memory_block_size_order(). Signed-off-by: Mike Travis <[email protected]> Reviewed-by: Andrew Banman <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Dimitri Sivanich <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Russ Anderson <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: https://lkml.kernel.org/lkml/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2018-06-21x86/platform/UV: Use new set memory block size function[email protected]1-3/+46
Add a call to the new function to "adjust" the current fixed UV memory block size of 2GB so it can be changed to a different physical boundary. This accommodates changes in the Intel BIOS, and therefore UV BIOS, which now can align boundaries different than the previous UV standard of 2GB. It also flags any UV Global Address boundaries from BIOS that cause a change in the mem block size (boundary). The current boundary of 2GB has been used on UV since the first system release in 2009 with Linux 2.6 and has worked fine. But the new NVDIMM persistent memory modules (PMEM), along with the Intel BIOS changes to support these modules caused the memory block size boundary to be set to a lower limit. Intel only guarantees that this minimum boundary at 64MB though the current Linux limit is 128MB. Note that the default remains 2GB if no changes occur. Signed-off-by: Mike Travis <[email protected]> Reviewed-by: Andrew Banman <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Dimitri Sivanich <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Russ Anderson <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: https://lkml.kernel.org/lkml/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2018-06-21x86/platform/UV: Add adjustable set memory block size function[email protected]2-4/+17
Add a new function to "adjust" the current fixed UV memory block size of 2GB so it can be changed to a different physical boundary. This is out of necessity so arch dependent code can accommodate specific BIOS requirements which can align these new PMEM modules at less than the default boundaries. A "set order" type of function was used to insure that the memory block size will be a power of two value without requiring a validity check. 64GB was chosen as the upper limit for memory block size values to accommodate upcoming 4PB systems which have 6 more bits of physical address space (46 becoming 52). Signed-off-by: Mike Travis <[email protected]> Reviewed-by: Andrew Banman <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Dimitri Sivanich <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Russ Anderson <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: https://lkml.kernel.org/lkml/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2018-06-21x86/spectre_v1: Disable compiler optimizations over array_index_mask_nospec()Dan Williams1-1/+1
Mark Rutland noticed that GCC optimization passes have the potential to elide necessary invocations of the array_index_mask_nospec() instruction sequence, so mark the asm() volatile. Mark explains: "The volatile will inhibit *some* cases where the compiler could lift the array_index_nospec() call out of a branch, e.g. where there are multiple invocations of array_index_nospec() with the same arguments: if (idx < foo) { idx1 = array_idx_nospec(idx, foo) do_something(idx1); } < some other code > if (idx < foo) { idx2 = array_idx_nospec(idx, foo); do_something_else(idx2); } ... since the compiler can determine that the two invocations yield the same result, and reuse the first result (likely the same register as idx was in originally) for the second branch, effectively re-writing the above as: if (idx < foo) { idx = array_idx_nospec(idx, foo); do_something(idx); } < some other code > if (idx < foo) { do_something_else(idx); } ... if we don't take the first branch, then speculatively take the second, we lose the nospec protection. There's more info on volatile asm in the GCC docs: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Volatile " Reported-by: Mark Rutland <[email protected]> Signed-off-by: Dan Williams <[email protected]> Acked-by: Mark Rutland <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Acked-by: Linus Torvalds <[email protected]> Cc: <[email protected]> Cc: Peter Zijlstra <[email protected]> Fixes: babdde2698d4 ("x86: Implement array_index_mask_nospec") Link: https://lkml.kernel.org/lkml/152838798950.14521.4893346294059739135.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Ingo Molnar <[email protected]>
2018-06-21Merge branches 'acpi-soc' and 'acpi-processor'Rafael J. Wysocki2-9/+12
These are a stable-candidate suspend/resume fix of the ACPI driver for Intel SoCs (LPSS) and an inline stub fix for the ACPI processor driver. * acpi-soc: ACPI / LPSS: Avoid PM quirks on suspend and resume from S3 * acpi-processor: ACPI / processor: Finish making acpi_processor_ppc_has_changed() void
2018-06-21Merge branch 'pm-tools'Rafael J. Wysocki2-75/+167
These are turbostat utility updates for 4.18-rc2 including two fixes for recent regressions and some minor extensions. * pm-tools: tools/power turbostat: version 18.06.20 tools/power turbostat: add the missing command line switches tools/power turbostat: add single character tokens to help tools/power turbostat: alphabetize the help output tools/power turbostat: fix segfault on 'no node' machines tools/power turbostat: add optional APIC X2APIC columns tools/power turbostat: decode cpuid.1.HT tools/power turbostat: fix show/hide issues resulting from mis-merge
2018-06-21x86/pti: Don't report XenPV as vulnerableJiri Kosina1-0/+4
Xen PV domain kernel is not by design affected by meltdown as it's enforcing split CR3 itself. Let's not report such systems as "Vulnerable" in sysfs (we're also already forcing PTI to off in X86_HYPER_XEN_PV cases); the security of the system ultimately depends on presence of mitigation in the Hypervisor, which can't be easily detected from DomU; let's report that. Reported-and-tested-by: Mike Latimer <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Acked-by: Juergen Gross <[email protected]> Cc: Borislav Petkov <[email protected]> Link: https://lkml.kernel.org/r/[email protected] [ Merge the user-visible string into a single line. ] Signed-off-by: Ingo Molnar <[email protected]>
2018-06-21Merge branches 'pm-core' and 'pm-opp'Rafael J. Wysocki2-5/+12
These are a PM core fix and an OPP framework fix for 4.18-rc2, both "stable" material. * pm-core: PM / core: Fix supplier device runtime PM usage counter imbalance * pm-opp: PM / OPP: Update voltage in case freq == old_freq
2018-06-21x86/build: Remove unnecessary preparation for purgatoryMasahiro Yamada1-5/+0
kexec-purgatory.c is properly generated when Kbuild descend into the arch/x86/purgatory/. Thus the 'archprepare' target is redundant. Signed-off-by: Masahiro Yamada <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Michal Marek <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Sam Ravnborg <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/lkml/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2018-06-21Revert "kexec/purgatory: Add clean-up for purgatory directory"Masahiro Yamada1-1/+0
Reverts the following commit: b0108f9e93d0 ("kexec: purgatory: add clean-up for purgatory directory") ... which incorrectly stated that the kexec-purgatory.c and purgatory.ro files were not removed after 'make mrproper'. In fact, they are. You can confirm it after reverting it. $ make mrproper $ touch arch/x86/purgatory/kexec-purgatory.c $ touch arch/x86/purgatory/purgatory.ro $ make mrproper CLEAN arch/x86/purgatory $ ls arch/x86/purgatory/ entry64.S Makefile purgatory.c setup-x86_64.S stack.S string.c This is obvious from the build system point of view. arch/x86/Makefile adds 'arch/x86' to core-y. Hence 'make clean' descends like this: arch/x86/Kbuild -> arch/x86/purgatory/Makefile Signed-off-by: Masahiro Yamada <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Michal Marek <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Sam Ravnborg <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/lkml/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2018-06-21KVM: arm/arm64: add WARN_ON if size is not PAGE_SIZE aligned in ↵Jia He1-0/+2
unmap_stage2_range There is a panic in armv8a server(QDF2400) under memory pressure tests (start 20 guests and run memhog in the host). ---------------------------------begin-------------------------------- [35380.800950] BUG: Bad page state in process qemu-kvm pfn:dd0b6 [35380.805825] page:ffff7fe003742d80 count:-4871 mapcount:-2126053375 mapping: (null) index:0x0 [35380.815024] flags: 0x1fffc00000000000() [35380.818845] raw: 1fffc00000000000 0000000000000000 0000000000000000 ffffecf981470000 [35380.826569] raw: dead000000000100 dead000000000200 ffff8017c001c000 0000000000000000 [35380.805825] page:ffff7fe003742d80 count:-4871 mapcount:-2126053375 mapping: (null) index:0x0 [35380.815024] flags: 0x1fffc00000000000() [35380.818845] raw: 1fffc00000000000 0000000000000000 0000000000000000 ffffecf981470000 [35380.826569] raw: dead000000000100 dead000000000200 ffff8017c001c000 0000000000000000 [35380.834294] page dumped because: nonzero _refcount [...] --------------------------------end-------------------------------------- The root cause might be what was fixed at [1]. But from the KVM points of view, it would be better if the issue was caught earlier. If the size is not PAGE_SIZE aligned, unmap_stage2_range might unmap the wrong(more or less) page range. Hence it caused the "BUG: Bad page state" Let's WARN in that case, so that the issue is obvious. [1] https://lkml.org/lkml/2018/5/3/1042 Reviewed-by: Suzuki K Poulose <[email protected]> Signed-off-by: [email protected] [maz: tidied up commit message] Signed-off-by: Marc Zyngier <[email protected]>
2018-06-21rseq/cleanup: Do not abort rseq c.s. in child on fork()Mathieu Desnoyers1-4/+1
Considering that we explicitly forbid system calls in rseq critical sections, it is not valid to issue a fork or clone system call within a rseq critical section, so rseq_fork() is not required to restart an active rseq c.s. in the child process. Signed-off-by: Mathieu Desnoyers <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Ben Maurer <[email protected]> Cc: Boqun Feng <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Chris Lameter <[email protected]> Cc: Dave Watson <[email protected]> Cc: Joel Fernandes <[email protected]> Cc: Josh Triplett <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Michael Kerrisk <[email protected]> Cc: Paul E . McKenney <[email protected]> Cc: Paul Turner <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Russell King <[email protected]> Cc: Shuah Khan <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Will Deacon <[email protected]> Cc: [email protected] Cc: [email protected] Link: https://lore.kernel.org/lkml/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2018-06-21rseq/selftests/arm: Align 'struct rseq_cs' on 32 bytesMathieu Desnoyers1-0/+1
uapi/linux/rseq.h aligns 'struct rseq_cs' on 32 bytes. Satisfy this alignment requirement in its definition within the rseq-arm.h inline assembly as well. Signed-off-by: Mathieu Desnoyers <[email protected]> Cc: Andrew Hunter <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Ben Maurer <[email protected]> Cc: Boqun Feng <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Chris Lameter <[email protected]> Cc: Dave Watson <[email protected]> Cc: Joel Fernandes <[email protected]> Cc: Josh Triplett <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Michael Kerrisk <[email protected]> Cc: Paul E . McKenney <[email protected]> Cc: Paul Turner <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Russell King <[email protected]> Cc: Shuah Khan <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Will Deacon <[email protected]> Cc: [email protected] Cc: [email protected] Link: https://lore.kernel.org/lkml/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2018-06-21rseq/selftests: Make run_param_test.sh executableMathieu Desnoyers1-0/+0
The executable bit of the run_param_test.sh script got lost in the merge. Signed-off-by: Mathieu Desnoyers <[email protected]> Cc: Andrew Hunter <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Ben Maurer <[email protected]> Cc: Boqun Feng <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Chris Lameter <[email protected]> Cc: Dave Watson <[email protected]> Cc: Joel Fernandes <[email protected]> Cc: Josh Triplett <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Michael Kerrisk <[email protected]> Cc: Paul E . McKenney <[email protected]> Cc: Paul Turner <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Russell King <[email protected]> Cc: Shuah Khan <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Will Deacon <[email protected]> Cc: [email protected] Cc: [email protected] Link: https://lore.kernel.org/lkml/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2018-06-21x86/xen: Add call of speculative_store_bypass_ht_init() to PV pathsJuergen Gross1-0/+5
Commit: 1f50ddb4f418 ("x86/speculation: Handle HT correctly on AMD") ... added speculative_store_bypass_ht_init() to the per-CPU initialization sequence. speculative_store_bypass_ht_init() needs to be called on each CPU for PV guests, too. Reported-by: Brian Woods <[email protected]> Tested-by: Brian Woods <[email protected]> Signed-off-by: Juergen Gross <[email protected]> Cc: <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Cc: [email protected] Fixes: 1f50ddb4f4189243c05926b842dc1a0332195f31 ("x86/speculation: Handle HT correctly on AMD") Link: https://lore.kernel.org/lkml/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2018-06-21drm/bridge/sii8620: fix display of packed pixel modes in MHL2Maciej Purski1-16/+1
Currently packed pixel modes in MHL2 can't be displayed. The device automatically recognizes output format, so setting format other than RGB causes failure. Fix it by writing proper values to registers. Tested on MHL1 and MHL2 using various vendors' dongles both in DVI and HDMI mode. Signed-off-by: Maciej Purski <[email protected]> Signed-off-by: Andrzej Hajda <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.