| Age | Commit message (Collapse) | Author |
|---|
|
While glibc's pthread implementation is rather forgiving about repeat
thread joining, Bionic has recently become much more strict. To deal with
this, actually track which threads have been successfully joined and kill
the rest at teardown.
Based on a patch from Paul Lawrence.
Cc: Paul Lawrence <paullawrence@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
|
|
This just cleans up the core dumping logic to avoid the braces around
the RET_KILL case.
Signed-off-by: Kees Cook <keescook@chromium.org>
|
|
When a module filter is added to set_ftrace_filter, if the module is not
loaded, it is cached. This should be considered an active filter, and
function tracing should be filtered by this. That is, if a cached module
filter is the only filter set, then no function tracing should be happening,
as all the functions available will be filtered out.
This makes sense, as the reason to add a cached module filter, is to trace
the module when you load it. There shouldn't be any other tracing happening
until then.
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
|
|
If a module is cached in the set_ftrace_filter, and that module is loaded,
then enable tracing on that module as if the cached module text was written
into set_ftrace_filter just as the module is loaded.
# echo ":mod:kvm_intel" >
# cat /sys/kernel/tracing/set_ftrace_filter
#### all functions enabled ####
:mod:kvm_intel
# modprobe kvm_intel
# cat /sys/kernel/tracing/set_ftrace_filter
vmx_get_rflags [kvm_intel]
vmx_get_pkru [kvm_intel]
vmx_get_interrupt_shadow [kvm_intel]
vmx_rdtscp_supported [kvm_intel]
vmx_invpcid_supported [kvm_intel]
[..]
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
|
|
When writing in a module filter into set_ftrace_filter for a module that is
not yet loaded, it it cached, and will be executed when the module is loaded
(although that is not implemented yet at this commit). Display the list of
cached modules to be traced.
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
|
|
This is the start of the infrastructure work to allow for tracing module
functions before it is loaded.
Currently the following command:
# echo :mod:some-mod > set_ftrace_filter
will enable tracing of all functions within the module "some-mod" if it is
loaded. What we want, is if the module is not loaded, that line will be
saved. When the module is loaded, then the "some-mod" will have that line
executed on it, so that the functions within it starts being traced.
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
|
|
This patch fix the following warning:
kernel/module.c: In function 'add_usage_links':
kernel/module.c:1653:6: warning: variable 'nowarn' set but not used [-Wunused-but-set-variable]
[jeyu: folded in first patch since it only swapped the function order
so that del_usage_links can be called from add_usage_links]
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Signed-off-by: Jessica Yu <jeyu@kernel.org>
|
|
Michael reported the segfault when kernel.kptr_restrict=2 is set.
$ perf record ls
...
perf: Segmentation fault
Obtained 16 stack frames.
./perf(dump_stack+0x2d) [0x5068df]
./perf(sighandler_dump_stack+0x2d) [0x5069bf]
./perf() [0x43e47b]
/lib64/libc.so.6(+0x3594f) [0x7f762004794f]
/lib64/libc.so.6(strlen+0x26) [0x7f762009ef86]
/lib64/libc.so.6(__strdup+0xd) [0x7f762009ecbd]
./perf(maps__set_kallsyms_ref_reloc_sym+0x4d) [0x51590f]
./perf(machine__create_kernel_maps+0x136) [0x50a7de]
./perf(perf_session__create_kernel_maps+0x2c) [0x510a81]
./perf(perf_session__new+0x13d) [0x510e23]
./perf() [0x43fd61]
./perf(cmd_record+0x704) [0x441823]
./perf() [0x4bc1a0]
./perf() [0x4bc40d]
./perf() [0x4bc55f]
./perf(main+0x2d5) [0x4bc939]
Segmentation fault (core dumped)
The reason is that with kernel.kptr_restrict=2, we don't get
the symbol from machine__get_running_kernel_start, which we
want to use in maps__set_kallsyms_ref_reloc_sym and we crash.
Check the symbol name value before calling
maps__set_kallsyms_ref_reloc_sym() and succeed without ref_reloc_sym
being set. It's safe because we check its existence before we use it.
Reported-by: Michael Petlan <mpetlan@redhat.com>
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/20170626095153.553-1-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
The function sbi_send() is local to just pnd2_edac.c and does not need
to be in global scope, so make it static.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Link: http://lkml.kernel.org/r/20170623084855.9197-1-colin.king@canonical.com
Signed-off-by: Borislav Petkov <bp@suse.de>
|
|
Check the correct variable when handling a potential error from
debugfs_create_file(). Most likely a copy-paste botch.
[ Rewrite commit message. ]
Fixes: 011d82611172 ("RAS: Add a Corrected Errors Collector")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20170623062440.6726-1-christophe.jaillet@wanadoo.fr
|
|
The MCE severity gives a hint as to how to handle the error. The
notifier blocks can then use the severity to decide on an action.
It's not necessary for machine_check_poll() to filter errors for
the notifier chain, since each block will check its own set of
conditions before handling an error.
Also, there isn't any urgency for machine_check_poll() to make decisions
based on severity like in do_machine_check().
If we can assume that a severity is set then we can use it in more
notifier blocks. For example, the CEC block could check for a "KEEP"
severity rather than checking bits in the status. This isn't possible
now since the severity is not set except for "DEFFRRED/UCNA" errors with
a valid address.
Save the severity since we have it, and let the notifier blocks decide
if they want to do anything.
Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1498074402-98633-1-git-send-email-Yazen.Ghannam@amd.com
|
|
The helper function __load_ucode_amd() and pointer intel_ucode_patch do
not need to be in global scope, so make them static.
Fixes those sparse warnings:
"symbol '__load_ucode_amd' was not declared. Should it be static?"
"symbol 'intel_ucode_patch' was not declared. Should it be static?"
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20170622095736.11937-1-colin.king@canonical.com
|
|
Check irq state in enable/disable/unmask/mask_irq to avoid unnecessary
low level irq function calls.
This has two advantages:
- Conditionals are faster than hardware access
- Solves issues with the underlying refcounting of the pinctrl
infrastructure
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: tfiga@chromium.org
Cc: briannorris@chromium.org
Cc: dianders@chromium.org
Link: http://lkml.kernel.org/r/1498476814-12563-2-git-send-email-jeffy.chen@rock-chips.com
|
|
Larry Finger reported that his Powerbook G4 was no longer booting with v4.12-rc,
userspace was up but giving weird errors such as:
udevd[64]: starting version 175
udevd[64]: Unable to receive ctrl message: Bad address.
modprobe: chdir(4.12-rc1): No such file or directory
He bisected the problem to commit 3448890c32c3 ("powerpc: get rid of zeroing,
switch to RAW_COPY_USER").
Al identified that the problem is actually a miscompilation by GCC 4.6.3, which
is exposed by the above commit.
Al also pointed out that inlining copy_to/from_user() is probably of little or
no benefit, which is correct. Using Anton's copy_to_user benchmark, with a
pathological single byte copy, we see a small increase in performance
by *removing* inlining:
Before (inlined):
# time ./copy_to_user -w -l 1 -i 10000000 ( x 3 )
real 0m22.063s
real 0m22.059s
real 0m22.076s
After:
# time ./copy_to_user -w -l 1 -i 10000000 ( x 3 )
real 0m21.325s
real 0m21.299s
real 0m21.364s
So as a small performance improvement and to avoid the miscompilation, drop
inlining copy_to/from_user() on 32-bit.
Fixes: 3448890c32c3 ("powerpc: get rid of zeroing, switch to RAW_COPY_USER")
Reported-by: Larry Finger <Larry.Finger@lwfinger.net>
Suggested-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
The hash table created during vmw_cmdbuf_res_man_create was
never freed. This causes memory leak in context creation.
Added the corresponding drm_ht_remove in vmw_cmdbuf_res_man_destroy.
Tested for memory leak by running piglit overnight and kernel
memory is not inflated which earlier was.
Cc: <stable@vger.kernel.org>
Signed-off-by: Deepak Rawat <drawat@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
|
|
The irq default state is set to disabled when allocating irq desc, but the
masked state flag is not set. This is inconsistent vs. the state tracking
logic which is used to prevent unnecessary calls to hardware level irq chip
functions.
Set the masked state flag as well.
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: tfiga@chromium.org
Cc: briannorris@chromium.org
Cc: dianders@chromium.org
Link: http://lkml.kernel.org/r/1498476814-12563-1-git-send-email-jeffy.chen@rock-chips.com
|
|
This reverts commit bb4a64b79f3b9973316e775f6c2910a98b6a562a.
The whole series is broken, so back it all out.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This reverts commit c6ce019edb0c9c09b8150011d4f66181952631e9.
The whole series is broken, so back it all out.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This reverts commit 48d3cfb3189a88e1670f609f8bd7d55839d531cf.
The whole series is broken, so back it all out.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This reverts commit be6faff74cda2ac1838c0f85dca3c3ce4975fa73.
The whole series is broken, so back it all out.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This reverts commit 10a8593a76c7719e110e334f84a6ef2068dd4c0f.
The whole series is broken, so back it all out.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This reverts commit b32cdde14edec1c75a2190a39e810bf41fa29a7a.
The whole series is broken, so back it all out.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This reverts commit 7eba570ece326ea0da2da72f1d4142100c145827.
The whole series is broken, so back it all out.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This reverts commit af4376710cc5188c42eb473676f6c9d2a16692c4.
The whole series is broken, so back it all out.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This reverts commit b065307fe0ad7859f01ce8560e6bdc590324561a.
The whole series is broken, so back it all out.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This reverts commit 5776aad3fe1bb87f3e4816cde8735647597da336.
The whole series is broken, so back it all out.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This reverts commit 7d6e221d73904aedcbd46ce2db6a545be55d2296.
The whole series is broken, so back it all out.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This reverts commit 9b1aa45539fb8389deb79e4a939bfc05ee45aeb5.
The whole series is broken, so back it all out.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This reverts commit 1877e4ba2d0890244284eea101681b6f990aa2be.
The whole series is broken, so back it all out.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Merge in arm64 ACPI RAS support (APEI/GHES) from Tyler Baicar.
|
|
Merge in arm64 perf updates:
* xgene system PMUv3 support
* 16-bit events for ARMv8.1
|
|
We have a Lenovo machine with the codec ALC294 on it, without the
patch, the Node 0x0b is regarded as the loopback mixer, but the Node
0x0b in this codec is "Vendor Defined Widget" instead of the audio
mixer, please see the log below:
Node 0x0b [Vendor Defined Widget] wcaps 0xf00000: Mono
Control: name="Beep Playback Volume", index=0, device=0
ControlAmp: chs=3, dir=In, idx=4, ofs=0
Control: name="Beep Playback Switch", index=0, device=0
ControlAmp: chs=3, dir=In, idx=4, ofs=0
And I have consulted with Realtek, so far the ALC234/274/294 all don't
have loopback mixer.
Cc: Kailang Yang <kailang@realtek.com>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Since commit:
af2cf278ef4f ("x86/mm/hotplug: Don't remove PGD entries in remove_pagetable()")
we no longer free PUDs so that we do not have to synchronize
all PGDs on hot-remove/vfree().
But the new 5-level page table patchset reverted that for 4-level
page tables, in the following commit:
f2a6a7050109: ("x86: Convert the rest of the code to support p4d_t")
This patch restores the damage and disables free_pud() if we are in the
4-level page table case, thus avoiding BUG_ON() after hot-remove.
Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
[ Clarified the changelog and the code comments. ]
Reviewed-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Logan Gunthorpe <logang@deltatee.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/20170624180514.3821-1-jglisse@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
ARM64 depends on the macro __AARCH64EB__ being defined or not
to correctly select or define endian-specific macros, structures
or pieces of code.
This macro is predefined by the compiler but sparse knows nothing
about it and thus may pre-process files differently from what
gcc would.
Fix this by passing '-D__AARCH64EL__' or '-D__AARCH64EB__' to
sparse depending of the endianness of the kernel, like defined
by GCC.
Note: In most case it won't change anything since most arm64 use
little-endian (but an allyesconfig would use big-endian!).
CC: Catalin Marinas <catalin.marinas@arm.com>
CC: Will Deacon <will.deacon@arm.com>
CC: linux-arm-kernel@lists.infradead.org
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
|
|
The "supported input formats" table in dw_hdmi.h was incorrectly formatted,
using "+" signs where "|" needs to be. That, in turn, causes the PDF build
to fail.
Fixes: def23aa7e982 ("drm: bridge: dw-hdmi: Switch to V4L bus format and encodings")
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170623140013.0703107a@lwn.net
|
|
If we write a relocation into the buffer, we require our own implicit
synchronisation added after the start of the execbuf, outside of the
user's control. As we may end up clflushing, or doing the patch itself
on the GPU, asynchronously we need to look at the implicit serialisation
on obj->resv and hence need to disable EXEC_OBJECT_ASYNC for this
object.
If the user does trigger a stall for relocations, we make sure the stall
is complete enough so that the batch is not submitted before we complete
those relocations.
Fixes: 77ae9957897d ("drm/i915: Enable userspace to opt-out of implicit fencing")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
(cherry picked from commit 071750e550af46b5d3a84ad56c2a108c3e136284)
[danvet: Resolve conflicts, resolution reviewed by Tvrtko on irc.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Thierry bisected boot failures to this simplification commit.
Reverts: 3f1d472055bb ("ktime: Simplify ktime_compare implementation")
Reported-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Mariusz Skamra <mariuszx.skamra@intel.com>
|
|
commit 2889caa92321 ("drm/i915: Eliminate lots of iterations over the
execobjects array") jiggled around the error handling and replace a test
that we cleaned up properly after ourselves with an assertion. That
assertion failed because in the release function (moments after the
assertion) we were indeed forgetting to mark the vma as cleared. The
consequence was when testing an invalid relocation address, we would try
to release the vma twice (following the couple of attempts to verify the
address) and on the second release notice that the first release was
incomplete.
Testcase: igt/gem_reloc_overflow/invalid-address
Fixes: 2889caa92321 ("drm/i915: Eliminate lots of iterations over the execobjects array")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170622104722.2583-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
(cherry picked from commit 51d05e1b29676a0425749a1533b87e3ad3c6f176)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
i915_vma_move_to_active() takes the execobject flags and not a boolean!
Instead of passing EXEC_OBJECT_WRITE we passed true [i.e.
EXEC_OBJECT_NEEDS_FENCE] causing us to start tracking the
vma->last_fence access and since we forgot to clear that on unbinding,
we caused a use-after-free.
[ 321.263854] BUG: KASAN: use-after-free in i915_gem_request_retire+0x1728/0x1740 [i915]
[ 321.264001] Read of size 8 at addr ffff880100fc67d8 by task gem_exec_reloc/2868
[ 321.264181] CPU: 0 PID: 2868 Comm: gem_exec_reloc Not tainted 4.12.0-rc6-CI-Custom_2759+ #1
[ 321.264195] Hardware name: GIGABYTE GB-BXBT-1900/MZBAYAB-00, BIOS F6 02/17/2015
[ 321.264208] Call Trace:
[ 321.264234] dump_stack+0x67/0x99
[ 321.264260] print_address_description+0x77/0x290
[ 321.264437] ? i915_gem_request_retire+0x1728/0x1740 [i915]
[ 321.264459] kasan_report+0x269/0x350
[ 321.264487] __asan_report_load8_noabort+0x14/0x20
[ 321.264660] i915_gem_request_retire+0x1728/0x1740 [i915]
[ 321.264841] ? intel_ring_context_pin+0x131/0x690 [i915]
[ 321.265021] i915_gem_request_alloc+0x2c6/0x1220 [i915]
[ 321.265044] ? _raw_spin_unlock_irqrestore+0x3d/0x60
[ 321.265226] i915_gem_do_execbuffer+0xac0/0x2a20 [i915]
[ 321.265250] ? __lock_acquire+0xceb/0x5450
[ 321.265269] ? entry_SYSCALL_64_fastpath+0x1c/0xb1
[ 321.265291] ? kvmalloc_node+0x6b/0x80
[ 321.265310] ? kvmalloc_node+0x6b/0x80
[ 321.265489] ? eb_relocate_slow+0xbe0/0xbe0 [i915]
[ 321.265520] ? ___slab_alloc.constprop.28+0x2ab/0x3d0
[ 321.265549] ? debug_check_no_locks_freed+0x280/0x280
[ 321.265591] ? __might_fault+0xc6/0x1b0
[ 321.265782] i915_gem_execbuffer2+0x14a/0x3f0 [i915]
[ 321.265815] drm_ioctl+0x4ba/0xaa0
[ 321.265986] ? i915_gem_execbuffer+0xde0/0xde0 [i915]
[ 321.266017] ? drm_getunique+0x270/0x270
[ 321.266068] do_vfs_ioctl+0x17f/0xfa0
[ 321.266091] ? __fget+0x1ba/0x330
[ 321.266112] ? lock_acquire+0x390/0x390
[ 321.266133] ? ioctl_preallocate+0x1d0/0x1d0
[ 321.266164] ? __fget+0x1db/0x330
[ 321.266194] ? __fget_light+0x79/0x1f0
[ 321.266219] SyS_ioctl+0x3c/0x70
[ 321.266247] entry_SYSCALL_64_fastpath+0x1c/0xb1
[ 321.266265] RIP: 0033:0x7fcede207357
[ 321.266279] RSP: 002b:00007ffef0effe58 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 321.266307] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fcede207357
[ 321.266321] RDX: 00007ffef0effef0 RSI: 0000000040406469 RDI: 0000000000000004
[ 321.266335] RBP: ffffffff812097c6 R08: 0000000000000008 R09: 0000000000000000
[ 321.266349] R10: 0000000000000008 R11: 0000000000000246 R12: ffff880116bcff98
[ 321.266363] R13: ffffffff81cb7cb3 R14: ffff880116bcff70 R15: 0000000000000000
[ 321.266385] ? __this_cpu_preempt_check+0x13/0x20
[ 321.266406] ? trace_hardirqs_off_caller+0x1d6/0x2c0
[ 321.266487] Allocated by task 2868:
[ 321.266568] save_stack_trace+0x16/0x20
[ 321.266586] kasan_kmalloc+0xee/0x180
[ 321.266602] kasan_slab_alloc+0x12/0x20
[ 321.266620] kmem_cache_alloc+0xc7/0x2e0
[ 321.266795] i915_vma_instance+0x28c/0x1540 [i915]
[ 321.266964] eb_lookup_vmas+0x5a7/0x2250 [i915]
[ 321.267130] i915_gem_do_execbuffer+0x69a/0x2a20 [i915]
[ 321.267296] i915_gem_execbuffer2+0x14a/0x3f0 [i915]
[ 321.267315] drm_ioctl+0x4ba/0xaa0
[ 321.267333] do_vfs_ioctl+0x17f/0xfa0
[ 321.267350] SyS_ioctl+0x3c/0x70
[ 321.267369] entry_SYSCALL_64_fastpath+0x1c/0xb1
[ 321.267428] Freed by task 177:
[ 321.267502] save_stack_trace+0x16/0x20
[ 321.267521] kasan_slab_free+0xad/0x180
[ 321.267539] kmem_cache_free+0xc5/0x340
[ 321.267710] i915_vma_unbind+0x666/0x10a0 [i915]
[ 321.267880] i915_vma_close+0x23a/0x2f0 [i915]
[ 321.268048] __i915_gem_free_objects+0x17d/0xc70 [i915]
[ 321.268215] __i915_gem_free_work+0x49/0x70 [i915]
[ 321.268234] process_one_work+0x66f/0x1410
[ 321.268252] worker_thread+0xe1/0xe90
[ 321.268269] kthread+0x304/0x410
[ 321.268285] ret_from_fork+0x27/0x40
[ 321.268346] The buggy address belongs to the object at ffff880100fc6640
which belongs to the cache i915_vma of size 656
[ 321.268550] The buggy address is located 408 bytes inside of
656-byte region [ffff880100fc6640, ffff880100fc68d0)
[ 321.268741] The buggy address belongs to the page:
[ 321.268837] page:ffffea000403f000 count:1 mapcount:0 mapping: (null) index:0xffff880100fc5980 compound_mapcount: 0
[ 321.269045] flags: 0x8000000000008100(slab|head)
[ 321.269147] raw: 8000000000008100 0000000000000000 ffff880100fc5980 00000001001e001d
[ 321.269312] raw: ffffea0004038e20 ffff880116b46240 ffff88011646c640 0000000000000000
[ 321.269484] page dumped because: kasan: bad access detected
[ 321.269665] Memory state around the buggy address:
[ 321.269778] ffff880100fc6680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 321.269949] ffff880100fc6700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 321.270115] >ffff880100fc6780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 321.270279] ^
[ 321.270410] ffff880100fc6800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 321.270576] ffff880100fc6880: fb fb fb fb fb fb fb fb fb fb fc fc fc fc fc fc
[ 321.270740] ==================================================================
[ 321.270903] Disabling lock debugging due to kernel taint
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101511
Fixes: 7dd4f6729f92 ("drm/i915: Async GPU relocation processing")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170620124321.1108-2-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
(cherry picked from commit 25ffaa67459e988e73210543f7e05dfbf3f16163)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Paulo noticed that we were missing few bits clear
before writing values back to the register on
these RMW MMIO operations.
v2: Remove "POST_" from CURSOR_COEFF_MASK. (Paulo).
v3: Remove unnecessary braces. (Jani).
Fixes: cf54ca8bc567 ("drm/i915/cnl: Implement voltage swing sequence.")
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1497897572-22520-1-git-send-email-rodrigo.vivi@intel.com
(cherry picked from commit 1f588aeb60b4412019546ce596f179635abc2ac3)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
There are two kinds of locking sequence.
One is in the thread which is started by vfio ioctl to do
the iommu unmapping. The locking sequence is:
down_read(&group_lock) ----> mutex_lock(&cached_lock)
The other is in the vfio release thread which will unpin all
the cached pages. The lock sequence is:
mutex_lock(&cached_lock) ---> down_read(&group_lock)
And, the cache_lock is used to protect the rb tree of the cache
node and doing vfio unpin doesn't require this lock. Move the
vfio unpin out of the cache_lock protected region.
v2:
- use for style instead of do{}while(1). (Zhenyu)
Fixes: f30437c5e7bf ("drm/i915/gvt: add KVMGT support")
Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: stable@vger.kernel.org # v4.10+
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
|
|
vfio_unpin_pages will hold a read semaphore however it is already hold
in the same thread by vfio ioctl. It will cause below warning:
[ 5102.127454] ============================================
[ 5102.133379] WARNING: possible recursive locking detected
[ 5102.139304] 4.12.0-rc4+ #3 Not tainted
[ 5102.143483] --------------------------------------------
[ 5102.149407] qemu-system-x86/1620 is trying to acquire lock:
[ 5102.155624] (&container->group_lock){++++++}, at: [<ffffffff817768c6>] vfio_unpin_pages+0x96/0xf0
[ 5102.165626]
but task is already holding lock:
[ 5102.172134] (&container->group_lock){++++++}, at: [<ffffffff8177728f>] vfio_fops_unl_ioctl+0x5f/0x280
[ 5102.182522]
other info that might help us debug this:
[ 5102.189806] Possible unsafe locking scenario:
[ 5102.196411] CPU0
[ 5102.199136] ----
[ 5102.201861] lock(&container->group_lock);
[ 5102.206527] lock(&container->group_lock);
[ 5102.211191]
*** DEADLOCK ***
[ 5102.217796] May be due to missing lock nesting notation
[ 5102.225370] 3 locks held by qemu-system-x86/1620:
[ 5102.230618] #0: (&container->group_lock){++++++}, at: [<ffffffff8177728f>] vfio_fops_unl_ioctl+0x5f/0x280
[ 5102.241482] #1: (&(&iommu->notifier)->rwsem){++++..}, at: [<ffffffff810de775>] __blocking_notifier_call_chain+0x35/0x70
[ 5102.253713] #2: (&vgpu->vdev.cache_lock){+.+...}, at: [<ffffffff8157b007>] intel_vgpu_iommu_notifier+0x77/0x120
[ 5102.265163]
stack backtrace:
[ 5102.270022] CPU: 5 PID: 1620 Comm: qemu-system-x86 Not tainted 4.12.0-rc4+ #3
[ 5102.277991] Hardware name: Intel Corporation S1200RP/S1200RP, BIOS S1200RP.86B.03.01.APER.061220151418 06/12/2015
[ 5102.289445] Call Trace:
[ 5102.292175] dump_stack+0x85/0xc7
[ 5102.295871] validate_chain.isra.21+0x9da/0xaf0
[ 5102.300925] __lock_acquire+0x405/0x820
[ 5102.305202] lock_acquire+0xc7/0x220
[ 5102.309191] ? vfio_unpin_pages+0x96/0xf0
[ 5102.313666] down_read+0x2b/0x50
[ 5102.317259] ? vfio_unpin_pages+0x96/0xf0
[ 5102.321732] vfio_unpin_pages+0x96/0xf0
[ 5102.326024] intel_vgpu_iommu_notifier+0xe5/0x120
[ 5102.331283] notifier_call_chain+0x4a/0x70
[ 5102.335851] __blocking_notifier_call_chain+0x4d/0x70
[ 5102.341490] blocking_notifier_call_chain+0x16/0x20
[ 5102.346935] vfio_iommu_type1_ioctl+0x87b/0x920
[ 5102.351994] vfio_fops_unl_ioctl+0x81/0x280
[ 5102.356660] ? __fget+0xf0/0x210
[ 5102.360261] do_vfs_ioctl+0x93/0x6a0
[ 5102.364247] ? __fget+0x111/0x210
[ 5102.367942] SyS_ioctl+0x41/0x70
[ 5102.371542] entry_SYSCALL_64_fastpath+0x1f/0xbe
put the vfio_unpin_pages in a workqueue can fix this.
v2:
- use for style instead of do{}while(1). (Zhenyu)
v3:
- rename gvt_cache_mark to gvt_cache_mark_remove. (Zhenyu)
Fixes: 659643f7d814 ("drm/i915/gvt/kvmgt: add vfio/mdev support to KVMGT")
Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: stable@vger.kernel.org # v4.10+
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
|
|
Add pinctrl support for the PWM[0-6] pins.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
As we walk the obj->vma_list in per_file_stats(), we need to hold
struct_mutex to prevent alteration of that list.
Fixes: 1d2ac403ae3b ("drm: Protect dev->filelist with its own mutex")
Fixes: c84455b4bacc ("drm/i915: Move debug only per-request pid tracking from request to ctx")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101460
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170617115744.4452-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
(cherry picked from commit 0caf81b5c53d9bd332a95dbcb44db8de0b397a7c)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Since we may track unfenced access (GPU access to the vma that
explicitly requires no fence), vma->last_fence may be set without any
attached fence (vma->fence) and so will not be flushed when we call
i915_vma_put_fence(). Since we stopped doing a full retire of the
activity trackers for unbind, we need to explicitly retire each tracker.
Fixes: b0decaf75bd9 ("drm/i915: Track active vma requests")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170620124321.1108-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
(cherry picked from commit 760a898d8069111704e1bd43f00ebf369ae46e57)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next
Jonathan writes:
Second set of IIO new device support, features and cleanups for the 4.13 cycle.
A few reverts here. One was a general failure to notice a device was already
supported by another driver. The second is due to a review comment pointing
out that the original patch was a bad idea and would break existing systems.
Reverts
* bma180
- Revert addition of support for the BMA250E it is already supported by
the bmc150-accel and better supported at that. Oops.
* hi8435
- The fix for cleanup of the reset gpio stuff isn't a good way to go. It
breaks systems where an inverting level convertor is used. The right fix
is to make the original devicetree correct - even if it involves patching
the devicetree in kernel.
New Device Support
* stm32-adc
- STM32H7 support and bindings.
Features
* core
- add a hardware triggered operating mode for systems in which the actual
trigger is never seen by the kernel. This is typically only used when
a device 'can' use other triggers, but if a particular magic one is
enabled the interrupt is effectively handled in hardware and we never see
it.
* st-lsm6dsx
- support active low interrupts.
* stm32-adc
- Make the core adc clock optional as not all hardware supported requires it.
- Make the bus clock optional in the per instance driver as it may be shared
by all instances of the ADC and is handled by the core.
- Rework to have a data structure representing the device type specific
elements.
* stm32-trigger (and counter)
- Use the INDIO_HARDWARE_TRIGGERED_MODE where appropriate.
- Add an attribute to configure device modes for quadrature counting etc.
Clean ups and minor fixes
* IIO core.
- use __sysfs_match_string() helper rather than open coding the same.
* ad7791
- use sysfs_match_string() helper rather than open coding the same.
* aspeed-adc
- handle return value of clk_prepare_enable
* cpcap
- Fix default register values and ensure the battery thermistor is enabled
correctly.
- Fix the reported die temperature where we can - docs are lacking.
- Remove the hung interrupt quirk as no longer happens due to fix in the
mfd driver.
* hi8435
- Remove &s from hi8435_info definition as unneeded and inconsistent.
* hid-sensor-trgger
- Add kconfig depends on IIO_BUFFER (fixes patch in previous series)
* ina2xx
- Make the use of iio_info_mask* elements consistent for all channels.
This doesn't have any visible effect, but acts as clear documentation of
which channels various resulting attributes apply to.
* lpc32xx
- handle the return value of clk_prepare_enable.
* meson-saradc
- NULL instead of 0 for pointer.
* mma9551
- use NULL for GPIO connection ID to aid implementation fo ACPI support.
Here the connection ID doesn't actually tell us anything and it is much
easier to deal with the driver if it's not there.
* mpu6050
- Fix lock issues through use of a local mux.
- Replace sprintf with scnprintf as appropriate.
- Check whoami against all known values. This allows for a small number of
boards where we are really fishing for the part not being present at all.
It is unfortunately common to have undescribed changes to use newer chips.
We paper over this but just emitting a warning for those cases as long as
we know about.
* mxs-lradc
- Fix some non static warnings.
* rcar-adc
- Part of making the naming for this part consistent across the kernel.
* st_accel
- drop some spi_device_id entries for variants with no SPI support
* st_magn
- drop some spi_device_id entries for variants with no SPI support.
* sx9500
- Use devm_gpiod_get instead of indexed value with an index of 0 on all
occasions.
* twl4030
- Drop unused twl4030_get_madc_conversion as callers removed now throughout
kernel.
- Unexport twl4030_madc_conversion() as no used only within this driver.
- Drop twl4030_madc_user_params as not used now.
- Drop twl4030_madc_request.func_cb as not used now.
- Fold the twl4030-madc.h header into the driver as no longer used anywhere
else in the kernel.
* xilinx
- Handle the return value of clk_prepare_enable
|
|
Parameters like maximum read/write request size and the maximum
number of active transactions are currently configured in DT/ACPI.
This patch allows a user to override these to fine tune performance
for their application.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
|
|
There is a typo in a comment that propagated into code:
upa-portis instead of upa-portid
This problem was detected by code inspection.
Fixes: eea9833453bd ("sparc64: broken %tick frequency on spitfire cpus"
Signed-off-by: Pavel Tatashin <pasha.tatashin@oracle.com>
Reported-by: Steven Sistare <steven.sistare@oracle.com>
Reviewed-by: Steven Sistare <steven.sistare@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
These apis only need to be defined if CONFIG_COMPAT is
enabled.
Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
As we change the user space type for the timerfd and posix timer
functions to newer data types, we need some form of conversion
helpers to avoid duplicating that logic.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
