sync with linus #1
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If the current cpu is the one which has the hrtimer based broadcast queued then we better return busy immediately instead of going through loops and hoops to figure that out. [ Split out from a larger combo patch ] Tested-by: Sudeep Holla <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: Suzuki Poulose <[email protected]> Cc: Lorenzo Pieralisi <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Preeti U Murthy <[email protected]> Cc: Ingo Molnar <[email protected]> Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1507070929360.3916@nanos
Andriy reported that on a virtual machine the warning about negative expiry time in the clock events programming code triggered: hpet: hpet0 irq 40 for MSI hpet: hpet1 irq 41 for MSI Switching to clocksource hpet WARNING: at kernel/time/clockevents.c:239 [<ffffffff810ce6eb>] clockevents_program_event+0xdb/0xf0 [<ffffffff810cf211>] tick_handle_periodic_broadcast+0x41/0x50 [<ffffffff81016525>] timer_interrupt+0x15/0x20 When the second hpet is installed as a per cpu timer the broadcast event is not longer required and stopped, which sets the next_evt of the broadcast device to KTIME_MAX. If after that a spurious interrupt happens on the broadcast device, then the current code blindly handles it and tries to reprogram the broadcast device afterwards, which adds the period to next_evt. KTIME_MAX + period results in a negative expiry value causing the WARN_ON in the clockevents code to trigger. Add a proper check for the state of the broadcast device into the interrupt handler and return if the interrupt is spurious. [ Folded in pointer fix from Sudeep ] Reported-by: Andriy Gapon <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: Sudeep Holla <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Preeti U Murthy <[email protected]> Link: http://lkml.kernel.org/r/[email protected]
The firmware only reports hover condition while the very first contact is approaching the surface; the hover is not reported for the subsequent contacts. Therefore we should not be using ABS_MT_DISTANCE to report hover but rather its single-touch counterpart ABS_DISTANCE. Signed-off-by: Duson Lin <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>
CC arch/mips/loongson64/lemote-2f/clock.o
/home/ralf/src/linux/linux-mips/arch/mips/loongson64/lemote-2f/clock.c:18:40: fatal error: asm/mach-loongson/loongson.h: No such file or directory
#include <asm/mach-loongson/loongson.h>
^
compilation terminated.
Signed-off-by: Ralf Baechle <[email protected]>
Signed-off-by: Ralf Baechle <[email protected]>
Making tick_broadcast_oneshot_control() independent from CONFIG_GENERIC_CLOCKEVENTS_BROADCAST broke the build for CONFIG_GENERIC_CLOCKEVENTS=n because the function is not defined there. Provide a proper stub inline. Fixes: f32dd11 'tick/broadcast: Make idle check independent from mode and config' Reported-by: kbuild test robot <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]>
* pm-wakeirq: PM / wakeirq: Avoid setting power.wakeirq too hastily
* acpi-pnp: ACPI / PNP: Reserve ACPI resources at the fs_initcall_sync stage * acpi-soc: ACPI / LPSS: Fix up acpi_lpss_create_device() * pm-domains: PM / Domains: Avoid infinite loops in attach/detach code * pm-sleep: PM / hibernate: clarify resume documentation
* acpi-scan: ata: ahci_platform: Add ACPI _CLS matching ACPI / scan: Add support for ACPI _CLS device matching
In function mei_nfc_host_exit mei_cl_remove_device cannot be called under the device mutex as device removing flow invokes the device driver remove handler that calls in turn to mei_cl_disable_device which naturally acquires the device mutex. Also remove mei_cl_bus_remove_devices which has the same issue, but is never executed as currently the only device on the mei client bus is NFC and a new device cannot be easily added till the bus revamp is completed. This fixes regression caused by commit be9b720 ("mei_phy: move all nfc logic from mei driver to nfc") Prior to this change the nfc driver remove handler called to no-op disable function while actual nfc device was disabled directly from the mei driver. Reported-by: Linus Torvalds <[email protected]> Acked-by: Greg Kroah-Hartman <[email protected]> Cc: Samuel Ortiz <[email protected]> Signed-off-by: Tomas Winkler <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
Pull ARM updates from Russell King: "These are late by a week; they should have been merged during the merge window, but unfortunately, the ARM kernel build/boot farms were indicating random failures, and it wasn't clear whether the cause was something in these changes or something during the merge window. This is a set of merge window fixes with some documentation additions" * 'for-linus' of git://ftp.arm.linux.org.uk/~rmk/linux-arm: ARM: avoid unwanted GCC memset()/memcpy() optimisations for IO variants ARM: pgtable: document mapping types ARM: io: convert ioremap*() to functions ARM: io: fix ioremap_wt() implementation ARM: io: document ARM specific behaviour of ioremap*() implementations ARM: fix lockdep unannotated irqs-off warning ARM: 8397/1: fix vdsomunge not to depend on glibc specific error.h ARM: add helpful message when truncating physical memory ARM: add help text for HIGHPTE configuration entry ARM: fix DEBUG_SET_MODULE_RONX build dependencies ARM: 8396/1: use phys_addr_t in pfn_to_kaddr() ARM: 8394/1: update memblock limit after mapping lowmem ARM: 8393/1: smp: Fix suspicious RCU usage with ipi tracepoints
Incorrect register offset used for sthi407 clockgenC Signed-off-by: Pankaj Dev <[email protected]> Signed-off-by: Gabriel Fernandez <[email protected]> Fixes: 51306d5 ("clk: st: STiH407: Support for clockgenC0") Signed-off-by: Stephen Boyd <[email protected]>
Commit 46e12c0 (MIPS: O32 / 32-bit: Always copy 4 stack arguments.) change the O32 syscall handler to always load four arguments from the userspace stack even for syscalls that require fewer or no arguments to be copied. This removes a large table from kernel space and need to maintain it. It appeared that it was ok the implementation chosen requires 16 bytes of readable stack space above the user stack pointer. Turned out a few threading implementations munmap the user stack before the thread exits resulting in errors due to the unreadable stack. We now treat any failed load as a if the loaded value was zero and let the actual syscall deal with the situation. Signed-off-by: Ralf Baechle <[email protected]>
…tate area This patch makes the mmap call fail outright if the requested region is larger than the problem state area assigned to the context so the error is reported immediately rather than waiting for an attempt to access an address out of bounds. Although we never expect users to map more than the assigned problem state area and are not aware of anyone doing this (other than for testing), this does have the potential to break users if someone has used a larger range regardless. I'm submitting it for consideration, but if this change is not considered acceptable the previous patch is sufficient to prevent access out of bounds without breaking anyone. Signed-off-by: Ian Munsie <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
It was discovered that if a process mmaped their problem state area they were able to access one page more than expected, potentially allowing them to access the problem state area of an unrelated process. This was due to a simple off by one error in the mmap fault handler introduced in 0712dc7 ("cxl: Fix issues when unmapping contexts"), which is fixed in this patch. Cc: [email protected] Fixes: 0712dc7 ("cxl: Fix issues when unmapping contexts") Signed-off-by: Ian Munsie <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
The sysfs attributes for the 24x7 counters are dynamically allocated. Initialize the attributes using sysfs_attr_init() to fix following warning which occurs when CONFIG_DEBUG_LOCK_VMALLOC=y. [ 0.346249] audit: initializing netlink subsys (disabled) [ 0.346284] audit: type=2000 audit(1436295254.340:1): initialized [ 0.346489] BUG: key c0000000efe90198 not in .data! [ 0.346491] DEBUG_LOCKS_WARN_ON(1) [ 0.346502] ------------[ cut here ]------------ [ 0.346504] WARNING: at ../kernel/locking/lockdep.c:3002 [ 0.346506] Modules linked in: Reported-by: Gustavo Luiz Duarte <[email protected]> Signed-off-by: Sukadev Bhattiprolu <[email protected]> Tested-by: Gustavo Luiz Duarte <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
Now that we have a shared powerpc tree on kernel.org, point folks at that as the primary place to look for powerpc stuff. Signed-off-by: Michael Ellerman <[email protected]>
This patch fixes a host of reentrancy bugs in the nx driver. The following algorithms are affected: * CCM * GCM * CTR * XCBC * SHA256 * SHA512 The crypto API allows a single transform to be used by multiple threads simultaneously. For example, IPsec will use a single tfm to process packets for a given SA. As packets may arrive on multiple CPUs that tfm must be reentrant. The nx driver does try to deal with this by using a spin lock. Unfortunately only the basic AES/CBC/ECB algorithms do this in the correct way. The symptom of these bugs may range from the generation of incorrect output to memory corruption. Cc: [email protected] Signed-off-by: Herbert Xu <[email protected]>
So scripts/get_maintainer.pl shows the Netfilter mailing lists. Reported-by: Julien Grall <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]>
…lidate_ipv6 The commit efb6de9 "netfilter: bridge: forward IPv6 fragmented packets" introduced a new function br_validate_ipv6 which take a reference on the inet6 device. Although, the reference is not released at the end. This will result to the impossibility to destroy any netdevice using ipv6 and bridge. It's possible to directly retrieve the inet6 device without taking a reference as all netfilter hooks are protected by rcu_read_lock via nf_hook_slow. Spotted while trying to destroy a Xen guest on the upstream Linux: "unregister_netdevice: waiting for vif1.0 to become free. Usage count = 1" Signed-off-by: Julien Grall <[email protected]> Cc: Bernhard Thaler <[email protected]> Cc: Pablo Neira Ayuso <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: Bob Liu <[email protected]> Acked-by: Stephen Hemminger <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]>
Signed-off-by: Sébastien Hinderer <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Samuel Thibault <[email protected]> Cc: Thomas Gleixner <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
When rotated and partial views were added no one spotted the resume path which assumes only one GGTT VMA per object and hence is now skipping rebind of alternative views. Signed-off-by: Tvrtko Ursulin <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
When a cpu goes up some architectures (e.g. x86) have to walk the irq space to set up the vector space for the cpu. While this needs extra protection at the architecture level we can avoid a few race conditions by preventing the concurrent allocation/free of irq descriptors and the associated data. When a cpu goes down it moves the interrupts which are targeted to this cpu away by reassigning the affinities. While this happens interrupts can be allocated and freed, which opens a can of race conditions in the code which reassignes the affinities because interrupt descriptors might be freed underneath. Example: CPU1 CPU2 cpu_up/down irq_desc = irq_to_desc(irq); remove_from_radix_tree(desc); raw_spin_lock(&desc->lock); free(desc); We could protect the irq descriptors with RCU, but that would require a full tree change of all accesses to interrupt descriptors. But fortunately these kind of race conditions are rather limited to a few things like cpu hotplug. The normal setup/teardown is very well serialized. So the simpler and obvious solution is: Prevent allocation and freeing of interrupt descriptors accross cpu hotplug. Signed-off-by: Thomas Gleixner <[email protected]> Acked-by: Peter Zijlstra <[email protected]> Cc: xiao jin <[email protected]> Cc: Joerg Roedel <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Yanmin Zhang <[email protected]> Link: http://lkml.kernel.org/r/[email protected]
This was lost in commit ce22dba Author: Maarten Lankhorst <[email protected]> Date: Tue Apr 21 17:12:56 2015 +0300 drm/i915: Move toggling planes out of crtc enable/disable. and we still need that crtc->active check since the overall modeset flow doesn't yet take dpms state into account properly. Fixes WARNING backtraces on at least bdw/hsw due to the ips disabling code being upset about being run on a switched-off pipe. We don't need a corresponding change on the enable side since with the old setCrtc semantics we always force-enable the pipe after a modeset. And the dpms function intel_crtc_control already checks for ->active. Reported-by: Linus Torvalds <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Ander Conselvan de Oliveira <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
Since commit 8c7b5cc Author: Ander Conselvan de Oliveira <[email protected]> Date: Tue Apr 21 17:13:19 2015 +0300 drm/i915: Use atomic helpers for computing changed flags we compute the plane state for a modeset before actually committing any changes, which means crtc->active won't be correct yet. Looking at future work in the modeset conversion targetting 4.3 the only places where crtc_state->active isn't accurate is when disabling other CRTCs than the one the modeset is for (when stealing connectors). Which isn't the case here. And that's also confirmed by an audit, we do unconditionally update crtc_state->active for the current pipe. We also don't need to update any other plane check functions since we only ever add the primary state to the modeset update right now. Cc: Ander Conselvan de Oliveira <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Jani Nikula <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
Fengguang Wu's tests triggered a bug in the branch tracer's start up test when CONFIG_DEBUG_PREEMPT set. This was because that config adds some debug logic in the per cpu field, which calls back into the branch tracer. The branch tracer has its own recursive checks, but uses a per cpu variable to implement it. If retrieving the per cpu variable calls back into the branch tracer, you can see how things will break. Instead of using a per cpu variable, use the trace_recursion field of the current task struct. Simply set a bit when entering the branch tracing and clear it when leaving. If the bit is set on entry, just don't do the tracing. There's also the case with lockdep, as the local_irq_save() called before the recursion can also trigger code that can call back into the function. Changing that to a raw_local_irq_save() will protect that as well. This prevents the recursion and the inevitable crash that follows. Link: http://lkml.kernel.org/r/[email protected] Cc: [email protected] # 3.10+ Reported-by: Fengguang Wu <[email protected]> Tested-by: Fengguang Wu <[email protected]> Signed-off-by: Steven Rostedt <[email protected]>
The "fix" in commit 0b08c5e ("audit: Fix check of return value of strnlen_user()") didn't fix anything, it broke things. As reported by Steven Rostedt: "Yes, strnlen_user() returns 0 on fault, but if you look at what len is set to, than you would notice that on fault len would be -1" because we just subtracted one from the return value. So testing against 0 doesn't test for a fault condition, it tests against a perfectly valid empty string. Also fix up the usual braindamage wrt using WARN_ON() inside a conditional - make it part of the conditional and remove the explicit unlikely() (which is already part of the WARN_ON*() logic, exactly so that you don't have to write unreadable code. Reported-and-tested-by: Steven Rostedt <[email protected]> Cc: Jan Kara <[email protected]> Cc: Paul Moore <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
Trying to resolve issues with missed vblanks and impossible values inside delivered kms pageflip completion events showed that radeon's irq handling sometimes doesn't handle valid irqs, but silently skips them. This was observed for vblank interrupts. Although those irqs have corresponding events queued in the gpu's irq ring at time of interrupt, and therefore the corresponding handling code gets triggered by these events, the handling code sometimes silently skipped processing the irq. The reason for those skips is that the handling code double-checks for each irq event if the corresponding irq status bits in the irq status registers are set. Sometimes those bits are not set at time of check for valid irqs, maybe due to some hardware race on some setups? The problem only seems to happen on some machine + card combos sometimes, e.g., never happened during my testing of different PC cards of the DCE-2/3/4 generation a year ago, but happens consistently now on two different Apple Mac cards (RV730, DCE-3, Apple iMac and Evergreen JUNIPER, DCE-4 in a Apple MacPro). It also doesn't happen at each interrupt but only occassionally every couple of hundred or thousand vblank interrupts. This results in XOrg warning messages like "[ 7084.472] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion event has impossible msc 420120 < target_msc 420121" as well as skipped frames and problems for applications that use kms pageflip events or vblank events, e.g., users of DRI2 and DRI3/Present, Waylands Weston compositor, etc. See also https://bugs.freedesktop.org/show_bug.cgi?id=85203 After some talking to Alex and Michel, we decided to fix this by turning the double-check for asserted irq status bits into a warning. Whenever a irq event is queued in the IH ring, always execute the corresponding interrupt handler. Still check the irq status bits, but only to log a DRM_DEBUG message on a mismatch. This fixed the problems reliably on both previously failing cards, RV-730 dual-head tested on both crtcs (pipes D1 and D2) and a triple-output Juniper HD-5770 card tested on all three available crtcs (D1/D2/D3). The r600 and evergreen irq handling is therefore tested, but the cik an si handling is only compile tested due to lack of hw. Reviewed-by: Christian König <[email protected]> Signed-off-by: Mario Kleiner <[email protected]> CC: Michel Dänzer <[email protected]> CC: Alex Deucher <[email protected]> CC: <[email protected]> # v3.16+ Signed-off-by: Alex Deucher <[email protected]>
This is a translation of the patch ... "drm/radeon: Handle irqs only based on irq ring, not irq status regs." ... for the vblank irq handling, to fix the same problem described in that patch on the new driver. Only compile tested due to lack of suitable hw. Reviewed-by: Christian König <[email protected]> Signed-off-by: Mario Kleiner <[email protected]> CC: Michel Dänzer <[email protected]> CC: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
We don't need to call the (expensive) radeon_bo_wait, checking the fences via RCU is much faster. The reservation done by radeon_bo_wait does not save us from any race conditions. Reviewed-by: Christian König <[email protected]> Signed-off-by: Grigori Goronzy <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.