summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2016-10-20arm64: remove pr_cont abuse from mem_initMark Rutland
All the lines printed by mem_init are independent, with each ending with a newline. While they logically form a large block, none are actually continuations of previous lines. The kernel-side printk code and the userspace demsg tool differ in their handling of KERN_CONT following a newline, and while this isn't always a problem kernel-side, it does cause difficulty for userspace. Using pr_cont causes the userspace tool to not print line prefix (e.g. timestamps) even when following a newline, mis-aligning the output and making it harder to read, e.g. [ 0.000000] Virtual kernel memory layout: [ 0.000000] modules : 0xffff000000000000 - 0xffff000008000000 ( 128 MB) vmalloc : 0xffff000008000000 - 0xffff7dffbfff0000 (129022 GB) .text : 0xffff000008080000 - 0xffff0000088b0000 ( 8384 KB) .rodata : 0xffff0000088b0000 - 0xffff000008c50000 ( 3712 KB) .init : 0xffff000008c50000 - 0xffff000008d50000 ( 1024 KB) .data : 0xffff000008d50000 - 0xffff000008e25200 ( 853 KB) .bss : 0xffff000008e25200 - 0xffff000008e6bec0 ( 284 KB) fixed : 0xffff7dfffe7fd000 - 0xffff7dfffec00000 ( 4108 KB) PCI I/O : 0xffff7dfffee00000 - 0xffff7dffffe00000 ( 16 MB) vmemmap : 0xffff7e0000000000 - 0xffff800000000000 ( 2048 GB maximum) 0xffff7e0000000000 - 0xffff7e0026000000 ( 608 MB actual) memory : 0xffff800000000000 - 0xffff800980000000 ( 38912 MB) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1 Fix this by using pr_notice consistently for all lines, which both the kernel and userspace are happy with. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: James Morse <james.morse@arm.com> Cc: Kefeng Wang <wangkefeng.wang@huawei.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-10-20arm64: fix show_regs fallout from KERN_CONT changesMark Rutland
Recently in commit 4bcc595ccd80decb ("printk: reinstate KERN_CONT for printing continuation lines"), the behaviour of printk changed w.r.t. KERN_CONT. Now, KERN_CONT is mandatory to continue existing lines. Without this, prefixes are inserted, making output illegible, e.g. [ 1007.069010] pc : [<ffff00000871898c>] lr : [<ffff000008718948>] pstate: 40000145 [ 1007.076329] sp : ffff000008d53ec0 [ 1007.079606] x29: ffff000008d53ec0 [ 1007.082797] x28: 0000000080c50018 [ 1007.086160] [ 1007.087630] x27: ffff000008e0c7f8 [ 1007.090820] x26: ffff80097631ca00 [ 1007.094183] [ 1007.095653] x25: 0000000000000001 [ 1007.098843] x24: 000000ea68b61cac [ 1007.102206] ... or when dumped with the userpace dmesg tool, which has slightly different implicit newline behaviour. e.g. [ 1007.069010] pc : [<ffff00000871898c>] lr : [<ffff000008718948>] pstate: 40000145 [ 1007.076329] sp : ffff000008d53ec0 [ 1007.079606] x29: ffff000008d53ec0 [ 1007.082797] x28: 0000000080c50018 [ 1007.086160] [ 1007.087630] x27: ffff000008e0c7f8 [ 1007.090820] x26: ffff80097631ca00 [ 1007.094183] [ 1007.095653] x25: 0000000000000001 [ 1007.098843] x24: 000000ea68b61cac [ 1007.102206] We can't simply always use KERN_CONT for lines which may or may not be continuations. That causes line prefixes (e.g. timestamps) to be supressed, and the alignment of all but the first line will be broken. For even more fun, we can't simply insert some dummy empty-string printk calls, as GCC warns for an empty printk string, and even if we pass KERN_DEFAULT explcitly to silence the warning, the prefix gets swallowed unless there is an additional part to the string. Instead, we must manually iterate over pairs of registers, which gives us the legible output we want in either case, e.g. [ 169.771790] pc : [<ffff00000871898c>] lr : [<ffff000008718948>] pstate: 40000145 [ 169.779109] sp : ffff000008d53ec0 [ 169.782386] x29: ffff000008d53ec0 x28: 0000000080c50018 [ 169.787650] x27: ffff000008e0c7f8 x26: ffff80097631de00 [ 169.792913] x25: 0000000000000001 x24: 00000027827b2cf4 Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-10-20Merge tag 'gvt-next-fix-2016-10-20' of https://github.com/01org/gvt-linux ↵Daniel Vetter
into drm-intel-next-queued gvt-next-fix-2016-10-20 This contains fix for first pull request. - clean up header mess between i915 core and gvt - new MAINTAINERS item - new kernel-doc section - fix compiling warnings - gvt gem fix series from Chris - fix for i915 intel_engine_cs change - some sparse fixes from Changbin Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2016-10-20drm/i915: Add a sunset clause to GPU hang loggingChris Wilson
If the kernel is old, more than a few releases old, chances are that the user is using an old kernel for a good reason, despite there being GPU hangs. After 180days since driver release stop suggesting that they should send those reports upstream. [Since Daniel acked this I expect he will pick up the dim patch to automatically update the DRIVER_TIMESTAMP everytime we tag a new release.] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161014134428.29582-1-chris@chris-wilson.co.uk Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2016-10-20kvm: x86: memset whole irq_eoiJiri Slaby
gcc 7 warns: arch/x86/kvm/ioapic.c: In function 'kvm_ioapic_reset': arch/x86/kvm/ioapic.c:597:2: warning: 'memset' used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size] And it is right. Memset whole array using sizeof operator. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: x86@kernel.org Cc: kvm@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> [Added x86 subject tag] Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
2016-10-20kvm/x86: Fix unused variable warning in kvm_timer_init()Borislav Petkov
When CONFIG_CPU_FREQ is not set, int cpu is unused and gcc rightfully warns about it: arch/x86/kvm/x86.c: In function ‘kvm_timer_init’: arch/x86/kvm/x86.c:5697:6: warning: unused variable ‘cpu’ [-Wunused-variable] int cpu; ^~~ But since it is used only in the CONFIG_CPU_FREQ block, simply move it there, thus squashing the warning too. Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
2016-10-20drm/imx: ipuv3-plane: disable local alpha for planes without alpha channelPhilipp Zabel
Without this patch, after enabling the overlay plane with an RGBA framebuffer, switching to a framebuffer without alpha channel would cause the plane to vanish, since the pixel local alpha is constant zero in that case. Disable local alpha again when setting an opaque framebuffer. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-10-20drm/imx: ipuv3-plane: make sure x/y offsets are even in case of chroma ↵Philipp Zabel
subsampling Odd x/y offsets are not allowed for horizontally/vertically chroma subsampled planar YUV formats. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Acked-by: Liu Ying <gnuiyl@gmail.com>
2016-10-20gpio / ACPI: fix returned error from acpi_dev_gpio_irq_get()David Arcari
acpi_dev_gpio_irq_get() currently ignores the error returned by acpi_get_gpiod_by_index() and overwrites it with -ENOENT. Problem is this error can be -EPROBE_DEFER, which just blows up some drivers when the module ordering is not correct. Cc: stable@vger.kernel.org Signed-off-by: David Arcari <darcari@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-10-20gpio: mockup: add sysfs dependencyArnd Bergmann
Building the gpio-mockup driver without SYSFS results in a harmless Kconfig warning: warning: (GPIO_MOCKUP) selects GPIO_SYSFS which has unmet direct dependencies (GPIOLIB && SYSFS) We can easily avoid that warning by adding a dependency on SYSFS. Fixes: 0f98dd1b27d2 ("gpio/mockup: add virtual gpio device") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-10-20gpio: stmpe: || vs && typoDan Carpenter
&& was obviously intended here. Fixes: 6936e1f88d23 ('gpio: stmpe: Write int status register only when needed') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Patrice Chotard <patrice.chotard@st.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-10-20gpio: mxs: Unmap region obtained by of_iomapArvind Yadav
Free memory mapping, if mxs_gpio_probe is not successful. Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-10-20gpio/board.txt: point to gpiod_set_valuePavel Machek
gpiod_set_value() is preffered interface these days, so add a pointer. Also fix a missing ). Signed-off-by: Pavel Machek <pavel@ucw.cz> [Fixed some grammar and reworded] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-10-20drm/i915: Stop reporting error details in dmesg as well as the error-stateChris Wilson
As we already capture all the information from the registers into the error-state, also dumping that to dmesg just generates noise that upsets CI and users alike (and doesn't provide us with any more information). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20161019125203.28851-1-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
2016-10-20sched/core, x86: Make struct thread_info arch specific againHeiko Carstens
The following commit: c65eacbe290b ("sched/core: Allow putting thread_info into task_struct") ... made 'struct thread_info' a generic struct with only a single ::flags member, if CONFIG_THREAD_INFO_IN_TASK_STRUCT=y is selected. This change however seems to be quite x86 centric, since at least the generic preemption code (asm-generic/preempt.h) assumes that struct thread_info also has a preempt_count member, which apparently was not true for x86. We could add a bit more #ifdefs to solve this problem too, but it seems to be much simpler to make struct thread_info arch specific again. This also makes the conversion to THREAD_INFO_IN_TASK_STRUCT a bit easier for architectures that have a couple of arch specific stuff in their thread_info definition. The arch specific stuff _could_ be moved to thread_struct. However keeping them in thread_info makes it easier: accessing thread_info members is simple, since it is at the beginning of the task_struct, while the thread_struct is at the end. At least on s390 the offsets needed to access members of the thread_struct (with task_struct as base) are too large for various asm instructions. This is not a problem when keeping these members within thread_info. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: keescook@chromium.org Cc: linux-arch@vger.kernel.org Link: http://lkml.kernel.org/r/1476901693-8492-2-git-send-email-mark.rutland@arm.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-20x86/signal: Remove bogus user_64bit_mode() check from sigaction_compat_abi()Dmitry Safonov
The recent introduction of SA_X32/IA32 sa_flags added a check for user_64bit_mode() into sigaction_compat_abi(). user_64bit_mode() is true for native 64-bit processes and x32 processes. Due to that the function returns w/o setting the SA_X32_ABI flag for X32 processes. In consequence the kernel attempts to deliver the signal to the X32 process in native 64-bit mode causing the process to segfault. Remove the check, so the actual check for X32 mode which sets the ABI flag can be reached. There is no side effect for native 64-bit mode. [ tglx: Rewrote changelog ] Fixes: 6846351052e6 ("x86/signal: Add SA_{X32,IA32}_ABI sa_flags") Reported-by: Mikulas Patocka <mpatocka@redhat.com> Tested-by: Adam Borowski <kilobyte@angband.pl> Signed-off-by: Dmitry Safonov <0x7f454c46@gmail.com> Cc: Dmitry Safonov <dsafonov@virtuozzo.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: linux-mm@kvack.org Cc: Cyrill Gorcunov <gorcunov@openvz.org> Cc: Pavel Emelyanov <xemul@virtuozzo.com> Link: http://lkml.kernel.org/r/CAJwJo6Z8ZWPqNfT6t-i8GW1MKxQrKDUagQqnZ%2B0%2B697%3DMyVeGg@mail.gmail.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-20arm64: kernel: force ET_DYN ELF type for CONFIG_RELOCATABLE=yArd Biesheuvel
GNU ld used to set the ELF file type to ET_DYN for PIE executables, which is the same file type used for shared libraries. However, this was changed recently, and now PIE executables are emitted as ET_EXEC instead. The distinction is only relevant for ELF loaders, and so there is little reason to care about the difference when building the kernel, which is why the change has gone unnoticed until now. However, debuggers do use the ELF binary, and expect ET_EXEC type files to appear in memory at the exact offset described in the ELF metadata. This means source level debugging is no longer possible when KASLR is in effect or when executing the stub. So add the -shared LD option when building with CONFIG_RELOCATABLE=y. This forces the ELF file type to be set to ET_DYN (which is what you get when building with binutils 2.24 and earlier anyway), and has no other ill effects. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-10-20irqchip/gic: Add missing \n to CPU IF adjustment messageMarc Zyngier
It really looks bad without a newline. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2016-10-20ALSA: hda - Fix headset mic detection problem for two Dell laptopsHui Wang
They uses the codec ALC255, and have the different pin cfg definition from the ones in the existing pin quirk table. Now adding them into the table to fix the problem. Cc: stable@vger.kernel.org Signed-off-by: Hui Wang <hui.wang@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-10-20irqchip/jcore: Don't show Kconfig menu item for driverRich Felker
Core drivers for J-Core SoCs will be selected implicitly via CONFIG_SH_JCORE_SOC instead. Based on a corresponding change to the clocksource/timer driver requested by Daniel Lezcano. Signed-off-by: Rich Felker <dalias@libc.org> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: linux-sh@vger.kernel.org Link: http://lkml.kernel.org/r/883a3d17084003e3cf21bab73ec12828fe4ff6c6.1476899495.git.dalias@libc.org Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2016-10-20drm/i915/gvt: do not ignore return value of create_scratch_pageDu, Changbin
Function create_scratch_page() may fail in some cases. Signed-off-by: Du, Changbin <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2016-10-20drm/i915/gvt: fix spare warnings on odd constant _Bool castDu, Changbin
The function return values should has type int if it return a integer value. Signed-off-by: Du, Changbin <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2016-10-20drm/i915/gvt: mark symbols static where possibleDu, Changbin
Mark all local functions & variables as static. Signed-off-by: Du, Changbin <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2016-10-20drm/i915/gvt: fix sparse warnings on different address spacesDu, Changbin
Add proper __iomem annotation for pointers obtained via ioremap(). Signed-off-by: Du, Changbin <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2016-10-20drm/i915/gvt: properly access enabled intel_engine_csZhenyu Wang
Switch to use new for_each_engine() helper to properly access enabled intel_engine_cs as i915 core has changed that to be dynamic managed. At GVT-g init time would still depend on ring mask to determine engine list as it's earlier. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2016-10-20drm/i915/gvt: Remove defunct vmap_batch()Chris Wilson
This code was removed from i915_cmd_parser.c but still an obsolete version wound up being duplicated into gvt/cmd_parser.c. Good riddance. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2016-10-20drm/i915/gvt: Use common mapping routines for shadow_bb objectChris Wilson
We have the ability to map an object, so use it rather than opencode it badly. Note that the object remains permanently pinned, this is poor practise. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2016-10-20drm/i915/gvt: Use common mapping routines for indirect_ctx objectChris Wilson
We have the ability to map an object, so use it rather than opencode it badly. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2016-10-20drm/i915/gvt: Stop waiting whilst holding struct_mutexChris Wilson
For whatever reason, the gvt scheduler runs synchronously. At the very least, lets run synchronously without holding the struct_mutex. v2: cut'n'paste mutex_lock instead of unlock. Replace long hold of struct_mutex with a mutex to serialise the worker threads. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2016-10-20drm/i915/gvt: Stop checking for impossible interrupts from a kthreadChris Wilson
The kthread will not be interrupted, don't even bother checking. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2016-10-20drm/i915/gvt: Hold a reference on the requestChris Wilson
The workload took a pointer to the request, and even waited upon, without holding a reference on the request. Take that reference explicitly and fix up the error path following request allocation that missed flushing the request. v2: [zhenyuw] - drop request put in error path for dispatch, as main thread caller will handle it identically to a real request. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2016-10-20drm/i915/gvt: Remove dangerous unpin of backing storage of bound GPU objectChris Wilson
Unpinning the pages prior to the object being release from the GPU may allow the GPU to read and write into system pages (i.e. use after free by the hw). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2016-10-20drm/i915/gvt: Use the returned VMA to provide the virtual addressChris Wilson
The purpose of returning the just-pinned VMA is so that we can use the information within, like its address. Also it should be tracked and used as the cookie to unpin... Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2016-10-20drm/i915/gvt: i915_gem_object_create() returns an error pointerChris Wilson
On failure from i915_gem_object_create(), we need to check for an error pointer not NULL. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2016-10-20drm/i915/gvt: Add runtime pm around fencesChris Wilson
Manipulating the fence_list requires the runtime wakelock, as does writing to the fence registers. Acquire a wakelock for the former, and assert that the device is awake for the latter. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2016-10-20Documentation/gpu: Add section for Intel GVT-g host supportZhenyu Wang
Update with brief overview and reference for more detailed arch design documents. Add new section for Intel GVT-g host support. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2016-10-20drm/i915/gvt: Fix warning on obsolete function usageZhenyu Wang
Don't use obsolete drm_gem_object_unreference() but switch to i915_gem_object_put(). Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2016-10-20MAINTAINERS: Add new Intel GVT-g driver maintainerZhenyu Wang
This adds new item for Intel GVT-g driver maintainer info. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2016-10-20drm/i915/gvt: clean up intel_gvt.h as interface for i915 coreZhenyu Wang
i915 core should only call functions and structures exposed through intel_gvt.h. Remove internal gvt.h and i915_pvinfo.h. Change for internal intel_gvt structure as private handler which not requires to expose gvt internal structure for i915 core. v2: Fix per Chris's comment - carefully handle dev_priv->gvt assignment - add necessary bracket for macro helper - forward declartion struct intel_gvt - keep free operation within same file handling alloc v3: fix use after free and remove intel_gvt.initialized v4: change to_gvt() to an inline Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2016-10-20USB: serial: cp210x: fix tiocmget error handlingJohan Hovold
The current tiocmget implementation would fail to report errors up the stack and instead leaked a few bits from the stack as a mask of modem-status flags. Fixes: 39a66b8d22a3 ("[PATCH] USB: CP2101 Add support for flow control") Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2016-10-20arm64: suspend: Reconfigure PSTATE after resume from idleJames Morse
The suspend/resume path in kernel/sleep.S, as used by cpu-idle, does not save/restore PSTATE. As a result of this cpufeatures that were detected and have bits in PSTATE get lost when we resume from idle. UAO gets set appropriately on the next context switch. PAN will be re-enabled next time we return from user-space, but on a preemptible kernel we may run work accessing user space before this point. Add code to re-enable theses two features in __cpu_suspend_exit(). We re-use uao_thread_switch() passing current. Signed-off-by: James Morse <james.morse@arm.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-10-20arm64: mm: Set PSTATE.PAN from the cpu_enable_pan() callJames Morse
Commit 338d4f49d6f7 ("arm64: kernel: Add support for Privileged Access Never") enabled PAN by enabling the 'SPAN' feature-bit in SCTLR_EL1. This means the PSTATE.PAN bit won't be set until the next return to the kernel from userspace. On a preemptible kernel we may schedule work that accesses userspace on a CPU before it has done this. Now that cpufeature enable() calls are scheduled via stop_machine(), we can set PSTATE.PAN from the cpu_enable_pan() call. Add WARN_ON_ONCE(in_interrupt()) to check the PSTATE value we updated is not immediately discarded. Reported-by: Tony Thompson <anthony.thompson@arm.com> Reported-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: James Morse <james.morse@arm.com> [will: fixed typo in comment] Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-10-20arm64: cpufeature: Schedule enable() calls instead of calling them via IPIJames Morse
The enable() call for a cpufeature/errata is called using on_each_cpu(). This issues a cross-call IPI to get the work done. Implicitly, this stashes the running PSTATE in SPSR when the CPU receives the IPI, and restores it when we return. This means an enable() call can never modify PSTATE. To allow PAN to do this, change the on_each_cpu() call to use stop_machine(). This schedules the work on each CPU which allows us to modify PSTATE. This involves changing the protype of all the enable() functions. enable_cpu_capabilities() is called during boot and enables the feature on all online CPUs. This path now uses stop_machine(). CPU features for hotplug'd CPUs are enabled by verify_local_cpu_features() which only acts on the local CPU, and can already modify the running PSTATE as it is called from secondary_start_kernel(). Reported-by: Tony Thompson <anthony.thompson@arm.com> Reported-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: James Morse <james.morse@arm.com> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-10-20arm64: Cortex-A53 errata workaround: check for kernel addressesAndre Przywara
Commit 7dd01aef0557 ("arm64: trap userspace "dc cvau" cache operation on errata-affected core") adds code to execute cache maintenance instructions in the kernel on behalf of userland on CPUs with certain ARM CPU errata. It turns out that the address hasn't been checked to be a valid user space address, allowing userland to clean cache lines in kernel space. Fix this by introducing an address check before executing the instructions on behalf of userland. Since the address doesn't come via a syscall parameter, we can't just reject tagged pointers and instead have to remove the tag when checking against the user address limit. Cc: <stable@vger.kernel.org> Fixes: 7dd01aef0557 ("arm64: trap userspace "dc cvau" cache operation on errata-affected core") Reported-by: Kristina Martsenko <kristina.martsenko@arm.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com> [will: rework commit message + replace access_ok with max_user_addr()] Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-10-20Bluetooth: btwilink: Fix probe return valueJacob Siverskog
Probe functions should return 0 on success. This driver's probe returns the value returned by hci_register_dev(), which is the hci index. This works for systems with only one hci device (id = 0) but for systems where the btwilink device ends up with an id larger than 0, things will start to fall apart. Make the probe function return 0 on success. Signed-off-by: Jacob Siverskog <jacob@teenage.engineering> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2016-10-20mm: Change vm_is_stack_for_task() to vm_is_stack_for_current()Andy Lutomirski
Asking for a non-current task's stack can't be done without races unless the task is frozen in kernel mode. As far as I know, vm_is_stack_for_task() never had a safe non-current use case. The __unused annotation is because some KSTK_ESP implementations ignore their parameter, which IMO is further justification for this patch. Signed-off-by: Andy Lutomirski <luto@kernel.org> Acked-by: Thomas Gleixner <tglx@linutronix.de> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Jann Horn <jann@thejh.net> Cc: Kees Cook <keescook@chromium.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Linux API <linux-api@vger.kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Tycho Andersen <tycho.andersen@canonical.com> Link: http://lkml.kernel.org/r/4c3f68f426e6c061ca98b4fc7ef85ffbb0a25b0c.1475257877.git.luto@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-20fs/proc: Stop trying to report thread stacksAndy Lutomirski
This reverts more of: b76437579d13 ("procfs: mark thread stack correctly in proc/<pid>/maps") ... which was partially reverted by: 65376df58217 ("proc: revert /proc/<pid>/maps [stack:TID] annotation") Originally, /proc/PID/task/TID/maps was the same as /proc/TID/maps. In current kernels, /proc/PID/maps (or /proc/TID/maps even for threads) shows "[stack]" for VMAs in the mm's stack address range. In contrast, /proc/PID/task/TID/maps uses KSTK_ESP to guess the target thread's stack's VMA. This is racy, probably returns garbage and, on arches with CONFIG_TASK_INFO_IN_THREAD=y, is also crash-prone: KSTK_ESP is not safe to use on tasks that aren't known to be running ordinary process-context kernel code. This patch removes the difference and just shows "[stack]" for VMAs in the mm's stack range. This is IMO much more sensible -- the actual "stack" address really is treated specially by the VM code, and the current thread stack isn't even well-defined for programs that frequently switch stacks on their own. Reported-by: Jann Horn <jann@thejh.net> Signed-off-by: Andy Lutomirski <luto@kernel.org> Acked-by: Thomas Gleixner <tglx@linutronix.de> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Kees Cook <keescook@chromium.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Linux API <linux-api@vger.kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Tycho Andersen <tycho.andersen@canonical.com> Link: http://lkml.kernel.org/r/3e678474ec14e0a0ec34c611016753eea2e1b8ba.1475257877.git.luto@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-20fs/proc: Stop reporting eip and esp in /proc/PID/statAndy Lutomirski
Reporting these fields on a non-current task is dangerous. If the task is in any state other than normal kernel code, they may contain garbage or even kernel addresses on some architectures. (x86_64 used to do this. I bet lots of architectures still do.) With CONFIG_THREAD_INFO_IN_TASK=y, it can OOPS, too. As far as I know, there are no use programs that make any material use of these fields, so just get rid of them. Reported-by: Jann Horn <jann@thejh.net> Signed-off-by: Andy Lutomirski <luto@kernel.org> Acked-by: Thomas Gleixner <tglx@linutronix.de> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Kees Cook <keescook@chromium.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Linux API <linux-api@vger.kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Cc: Tycho Andersen <tycho.andersen@canonical.com> Link: http://lkml.kernel.org/r/a5fed4c3f4e33ed25d4bb03567e329bc5a712bcc.1475257877.git.luto@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-20drm/i915: Handle early failure during intel_get_load_detect_pipeChris Wilson
In the error path, we have to be ready to handle an error before either the state or restore_state have been allocated. [ 397.001342] BUG: unable to handle kernel NULL pointer dereference at (null) [ 397.001419] IP: [<ffffffffa04347b4>] intel_get_load_detect_pipe+0xe4/0x610 [i915] [ 397.001502] PGD 136a2a067 [ 397.001523] PUD 134b5f067 [ 397.001546] PMD 0 [ 397.001569] Oops: 0002 [#1] PREEMPT SMP [ 397.001599] Modules linked in: snd_hda_intel i915 cdc_ncm usbnet mii x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core snd_pcm lpc_ich mei_me mei sdhci_pci sdhci mmc_core e1000e ptp pps_core [last unloaded: i915] [ 397.001902] CPU: 1 PID: 9287 Comm: kms_force_conne Tainted: G U 4.9.0-rc1-CI-CI_DRM_1730+ #1 [ 397.001965] Hardware name: LENOVO 2356GCG/2356GCG, BIOS G7ET31WW (1.13 ) 07/02/2012 [ 397.002017] task: ffff880138c38040 task.stack: ffffc900083e4000 [ 397.002057] RIP: 0010:[<ffffffffa04347b4>] [<ffffffffa04347b4>] intel_get_load_detect_pipe+0xe4/0x610 [i915] [ 397.002153] RSP: 0018:ffffc900083e7ae8 EFLAGS: 00010286 [ 397.002191] RAX: 00000000ffffffdd RBX: ffffc900083e7bc8 RCX: 0000000000000006 [ 397.002239] RDX: 0000000000000006 RSI: ffff880138c388b8 RDI: ffffc900083e79e0 [ 397.002287] RBP: ffffc900083e7b78 R08: 0000000000000000 R09: 0000000000000000 [ 397.002335] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 [ 397.002386] R13: ffff8801305e1158 R14: 00000000ffffffdd R15: 0000000000000000 [ 397.002434] FS: 00007fea1b03c740(0000) GS:ffff88013e240000(0000) knlGS:0000000000000000 [ 397.002488] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 397.002528] CR2: 0000000000000000 CR3: 00000001361da000 CR4: 00000000001406e0 [ 397.002576] Stack: [ 397.002592] ffff88013046f180 0000000000000000 ffffc900083e7bc0 0000000000000000 [ 397.002655] 0000000000000000 ffff8801306bd038 ffff88012e980000 ffffc90000000001 [ 397.002718] ffffc90000000000 ffff880136b8ca88 ffff88012e980890 ffff88012e980540 [ 397.002780] Call Trace: [ 397.002828] [<ffffffffa044e8c4>] intel_crt_detect+0x3c4/0x8f0 [i915] [ 397.002876] [<ffffffff810e37fa>] ? vprintk_default+0x1a/0x20 [ 397.002918] [<ffffffff8116eb68>] ? printk+0x43/0x4b [ 397.002956] [<ffffffff81546b06>] drm_helper_probe_single_connector_modes+0x406/0x4f0 [ 397.003014] [<ffffffff81819c09>] ? mutex_unlock+0x9/0x10 [ 397.003054] [<ffffffff815723dc>] drm_mode_getconnector+0x33c/0x3c0 [ 397.003099] [<ffffffff810ed59d>] ? debug_lockdep_rcu_enabled+0x1d/0x20 [ 397.003147] [<ffffffff811a6bae>] ? __might_fault+0x3e/0x90 [ 397.003191] [<ffffffff8155aaf6>] drm_ioctl+0x1f6/0x480 [ 397.003231] [<ffffffff815720a0>] ? drm_mode_connector_property_set_ioctl+0x30/0x30 [ 397.003285] [<ffffffff8120308e>] do_vfs_ioctl+0x8e/0x690 [ 397.003324] [<ffffffff810a102c>] ? task_work_run+0x8c/0xb0 [ 397.003366] [<ffffffff810d6d92>] ? trace_hardirqs_on_caller+0x122/0x1b0 [ 397.003412] [<ffffffff812036cc>] SyS_ioctl+0x3c/0x70 [ 397.003451] [<ffffffff8181df2e>] entry_SYSCALL_64_fastpath+0x1c/0xb1 [ 397.003496] Code: 85 c0 41 89 c6 75 57 49 8b 85 f0 00 00 00 48 89 de 45 31 ff 48 8d 78 20 e8 1a 89 13 e1 45 31 c9 85 c0 41 89 c6 0f 84 2f 01 00 00 <f0> 41 83 29 01 74 53 f0 41 83 2f 01 74 2d 41 83 fe dd 75 35 48 [ 397.003837] RIP [<ffffffffa04347b4>] intel_get_load_detect_pipe+0xe4/0x610 [i915] [ 397.003921] RSP <ffffc900083e7ae8> [ 397.003947] CR2: 0000000000000000 Testcase: igt/kms_force_connector_basic/force-load-detect # ivb-3720m Fixes: 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state" Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161019113743.19847-1-chris@chris-wilson.co.uk
2016-10-20drm/fb_cma_helper: do not free fbdev if there is noneStefan Agner
If fbdev emulation is not in use (or not built-in), fb_helper.fbdev is NULL. Don't call calling drm_fbdev_cma_defio_fini in this case. Signed-off-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161020003221.2941-2-stefan@agner.ch
generated by cgit (git 2.34.1) at 2025-09-15 02:58:43 +0000