Pull arm64 fixes from Catalin Marinas:
- Cache invalidation fix for early CPU boot status update (incorrect
cacheline)
- of_put_node() missing in the spin_table code
- EL1/El2 early init inconsistency when Virtualisation Host Extensions
are present
- RCU warning fix in the arm_pmu.c driver
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64: Fix EL1/EL2 early init inconsistencies with VHE
drivers/perf: arm-pmu: fix RCU usage on pmu resume from low-power
arm64: spin-table: add missing of_node_put()
arm64: fix invalidation of wrong __early_cpu_boot_status cacheline
Pull powerpc fixes from Michael Ellerman:
"Three powerpc cpu feature fixes from Anton Blanchard:
- scan_features() updated incorrect bits for REAL_LE
- update cpu_user_features2 in scan_features()
- update TM user feature bits in scan_features()"
* tag 'powerpc-4.6-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
powerpc: Update TM user feature bits in scan_features()
powerpc: Update cpu_user_features2 in scan_features()
powerpc: scan_features() updates incorrect bits for REAL_LE
Pull IOMMU fixes from Joerg Roedel:
"The fixes include:
- Two patches to revert the use of default domains in the ARM SMMU
driver. Enabling this caused regressions which need more thorough
fixing. So the regressions are fixed for now by disabling the use
of default domains.
- A fix for a v4.4 regression in the AMD IOMMU driver which broke
devices behind invisible PCIe-to-PCI bridges with IOMMU enabled"
* tag 'iommu-fixes-v4.6-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
iommu/arm-smmu: Don't allocate resources for bypass domains
iommu/arm-smmu: Fix stream-match conflict with IOMMU_DOMAIN_DMA
iommu/amd: Fix checking of pci dma aliases
Pull drm fixes from Dave Airlie:
"i915, nouveau and amdgpu/radeon fixes in this:
nouveau:
Two fixes, one for a regression with dithering and one for a bug
hit by the userspace drivers.
i915:
A few fixes, mostly things heading for stable, two important
skylake GT3/4 hangs.
radeon/amdgpu:
Some audio, suspend/resume and some runtime PM fixes, along with
two patches to harden the userptr ABI a bit"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: (24 commits)
drm: Loongson-3 doesn't fully support wc memory
drm/nouveau/gr/gf100: select a stream master to fixup tfb offset queries
amdgpu/uvd: add uvd fw version for amdgpu
drm/amdgpu: forbid mapping of userptr bo through radeon device file
drm/radeon: forbid mapping of userptr bo through radeon device file
drm/amdgpu: bump the afmt limit for CZ, ST, Polaris
drm/amdgpu: use defines for CRTCs and AMFT blocks
drm/dp/mst: Validate port in drm_dp_payload_send_msg()
drm/nouveau/kms: fix setting of default values for dithering properties
drm/radeon: print a message if ATPX dGPU power control is missing
Revert "drm/radeon: disable runtime pm on PX laptops without dGPU power control"
drm/amdgpu/acp: fix resume on CZ systems with AZ audio
drm/radeon: add a quirk for a XFX R9 270X
drm/radeon: print pci revision as well as pci ids on driver load
drm/i915: Use fw_domains_put_with_fifo() on HSW
drm/i915: Force ringbuffers to not be at offset 0
drm/i915: Adjust size of PIPE_CONTROL used for gen8 render seqno write
drm/i915/skl: Fix spurious gpu hang with gt3/gt4 revs
drm/i915/skl: Fix rc6 based gpu/system hang
drm/i915/userptr: Hold mmref whilst calling get-user-pages
...
Pull sound fixes from Takashi Iwai:
"Again a relatively calm week without surprise: most of fixes are about
HD-audio, including fixes for Cirrus codec regression and a race over
regmap access. Although both change are slightly unintuitive, the
risk of further breakage is quite low, I hope.
Other than that, all the rest are trivial"
* tag 'sound-4.6-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: hda - Fix possible race on regmap bypass flip
ALSA: pcxhr: Fix missing mutex unlock
ALSA: hda - add PCI ID for Intel Broxton-T
ALSA: hda - Keep powering up ADCs on Cirrus codecs
ALSA: hda/realtek - Add ALC3234 headset mode for Optiplex 9020m
ALSA - hda: hdmi check NULL pointer in hdmi_set_chmap
ALSA: hda - Don't trust the reported actual power state
Felipe writes:
usb: fixes for v4.6-rc5
No more major fixes left. Out of the 6 fixes we have
here, 4 are on dwc3.
The most important is the memory leak fix in
dwc3/debugfs.c. We also have a fix for PHY handling
in suspend/resume and a fix for dwc3-omap's error
handling.
Suspend/resume also had the potential to trigger a
NULL pointer dereference on dwc3; that's also fixed
now.
Our good ol' ffs function gets a use-after-free fix
while the generic composite.c layer has a robustness
fix by making sure reserved fields of a possible SSP
device capability descriptor is cleared to 0.
Huge pages are not normally available to PV guests. Not suppressing
hugetlbfs use results in an endless loop of page faults when user mode
code tries to access a hugetlbfs mapped area (since the hypervisor
denies such PTEs to be created, but error indications can't be
propagated out of xen_set_pte_at(), just like for various of its
siblings), and - once killed in an oops like this:
kernel BUG at .../fs/hugetlbfs/inode.c:428!
invalid opcode: 0000 [#1] SMP
...
RIP: e030:[<ffffffff811c333b>] [<ffffffff811c333b>] remove_inode_hugepages+0x25b/0x320
...
Call Trace:
[<ffffffff811c3415>] hugetlbfs_evict_inode+0x15/0x40
[<ffffffff81167b3d>] evict+0xbd/0x1b0
[<ffffffff8116514a>] __dentry_kill+0x19a/0x1f0
[<ffffffff81165b0e>] dput+0x1fe/0x220
[<ffffffff81150535>] __fput+0x155/0x200
[<ffffffff81079fc0>] task_work_run+0x60/0xa0
[<ffffffff81063510>] do_exit+0x160/0x400
[<ffffffff810637eb>] do_group_exit+0x3b/0xa0
[<ffffffff8106e8bd>] get_signal+0x1ed/0x470
[<ffffffff8100f854>] do_signal+0x14/0x110
[<ffffffff810030e9>] prepare_exit_to_usermode+0xe9/0xf0
[<ffffffff814178a5>] retint_user+0x8/0x13
This is CVE-2016-3961 / XSA-174.
Reported-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Juergen Gross <JGross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Luis R. Rodriguez <mcgrof@suse.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Toshi Kani <toshi.kani@hp.com>
Cc: stable@vger.kernel.org
Cc: xen-devel <xen-devel@lists.xenproject.org>
Link: http://lkml.kernel.org/r/57188ED802000078000E431C@prv-mh.provo.novell.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The recent introduction of the hotplug thread which invokes the callbacks on
the plugged cpu, cased the following regression:
If takedown_cpu() fails, then we run into several issues:
1) The rollback of the target cpu states is not invoked. That leaves the smp
threads and the hotplug thread in disabled state.
2) notify_online() is executed due to a missing skip_onerr flag. That causes
that both CPU_DOWN_FAILED and CPU_ONLINE notifications are invoked which
confuses quite some notifiers.
3) The CPU_DOWN_FAILED notification is not invoked on the target CPU. That's
not an issue per se, but it is inconsistent and in consequence blocks the
patches which rely on these states being invoked on the target CPU and not
on the controlling cpu. It also does not preserve the strict call order on
rollback which is problematic for the ongoing state machine conversion as
well.
To fix this we add a rollback flag to the remote callback machinery and invoke
the rollback including the CPU_DOWN_FAILED notification on the remote
cpu. Further mark the notify online state with 'skip_onerr' so we don't get a
double invokation.
This workaround will go away once we moved the unplug invocation to the target
cpu itself.
[ tglx: Massaged changelog and moved the CPU_DOWN_FAILED notifiaction to the
target cpu ]
Fixes: 4cb28ced23 ("cpu/hotplug: Create hotplug threads")
Reported-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: linux-s390@vger.kernel.org
Cc: rt@linutronix.de
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Anna-Maria Gleixner <anna-maria@linutronix.de>
Link: http://lkml.kernel.org/r/20160408124015.GA21960@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Commit 0881841f7e introduced a regression by inverting a test check
after calling clocksource_mmio_init(). That results on the system to
hang at boot time.
Fix it by inverting the test again.
Fixes: 0881841f7e ("Replace code by clocksource_mmio_init")
Reported-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Misc radeon and amdgpu bug fixes for 4.6.
* 'drm-fixes-4.6' of git://people.freedesktop.org/~agd5f/linux:
amdgpu/uvd: add uvd fw version for amdgpu
drm/amdgpu: forbid mapping of userptr bo through radeon device file
drm/radeon: forbid mapping of userptr bo through radeon device file
drm/amdgpu: bump the afmt limit for CZ, ST, Polaris
drm/amdgpu: use defines for CRTCs and AMFT blocks
drm/radeon: print a message if ATPX dGPU power control is missing
Revert "drm/radeon: disable runtime pm on PX laptops without dGPU power control"
drm/amdgpu/acp: fix resume on CZ systems with AZ audio
drm/radeon: add a quirk for a XFX R9 270X
drm/radeon: print pci revision as well as pci ids on driver load
drm/amdgpu: when suspending, if uvd/vce was running. need to cancel delay work.
drm/radeon: fix initial connector audio value
Allowing userptr bo which are basicly a list of page from some vma
(so either anonymous page or file backed page) would lead to serious
corruption of kernel structures and counters (because we overwrite
the page->mapping field when mapping buffer).
This will already block if the buffer was populated before anyone does
try to mmap it because then TTM_PAGE_FLAG_SG would be set in in the
ttm_tt flags. But that flag is check before ttm_tt_populate in the ttm
vm fault handler.
So to be safe just add a check to verify_access() callback.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Allowing userptr bo which are basicly a list of page from some vma
(so either anonymous page or file backed page) would lead to serious
corruption of kernel structures and counters (because we overwrite
the page->mapping field when mapping buffer).
This will already block if the buffer was populated before anyone does
try to mmap it because then TTM_PAGE_FLAG_SG would be set in in the
ttm_tt flags. But that flag is check before ttm_tt_populate in the ttm
vm fault handler.
So to be safe just add a check to verify_access() callback.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
With the joys of things running concurrently, there's always a chance
that the port we get passed in drm_dp_payload_send_msg() isn't actually
valid anymore. Because of this, we need to make sure we validate the
reference to the port before we use it otherwise we risk running into
various race conditions. For instance, on the Dell MST monitor I have
here for testing, hotplugging it enough times causes us to kernel panic:
[drm:intel_mst_enable_dp] 1
[drm:drm_dp_update_payload_part2] payload 0 1
[drm:intel_get_hpd_pins] hotplug event received, stat 0x00200000, dig 0x10101011, pins 0x00000020
[drm:intel_hpd_irq_handler] digital hpd port B - short
[drm:intel_dp_hpd_pulse] got hpd irq on port B - short
[drm:intel_dp_check_mst_status] got esi 00 10 00
[drm:drm_dp_update_payload_part2] payload 1 1
general protection fault: 0000 [#1] SMP
…
Call Trace:
[<ffffffffa012b632>] drm_dp_update_payload_part2+0xc2/0x130 [drm_kms_helper]
[<ffffffffa032ef08>] intel_mst_enable_dp+0xf8/0x180 [i915]
[<ffffffffa0310dbd>] haswell_crtc_enable+0x3ed/0x8c0 [i915]
[<ffffffffa030c84d>] intel_atomic_commit+0x5ad/0x1590 [i915]
[<ffffffffa01db877>] ? drm_atomic_set_crtc_for_connector+0x57/0xe0 [drm]
[<ffffffffa01dc4e7>] drm_atomic_commit+0x37/0x60 [drm]
[<ffffffffa0130a3a>] drm_atomic_helper_set_config+0x7a/0xb0 [drm_kms_helper]
[<ffffffffa01cc482>] drm_mode_set_config_internal+0x62/0x100 [drm]
[<ffffffffa01d02ad>] drm_mode_setcrtc+0x3cd/0x4e0 [drm]
[<ffffffffa01c18e3>] drm_ioctl+0x143/0x510 [drm]
[<ffffffffa01cfee0>] ? drm_mode_setplane+0x1b0/0x1b0 [drm]
[<ffffffff810f79a7>] ? hrtimer_start_range_ns+0x1b7/0x3a0
[<ffffffff81212962>] do_vfs_ioctl+0x92/0x570
[<ffffffff81590852>] ? __sys_recvmsg+0x42/0x80
[<ffffffff81212eb9>] SyS_ioctl+0x79/0x90
[<ffffffff816b4e32>] entry_SYSCALL_64_fastpath+0x1a/0xa4
RIP [<ffffffffa012b026>] drm_dp_payload_send_msg+0x146/0x1f0 [drm_kms_helper]
Which occurs because of the hotplug event shown in the log, which ends
up causing DRM's dp helpers to drop the port we're updating the payload
on and panic.
CC: stable@vger.kernel.org
Signed-off-by: Lyude <cpaul@redhat.com>
Reviewed-by: David Airlie <airlied@linux.ie>
Signed-off-by: Dave Airlie <airlied@redhat.com>