The orphan cleanup workqueue doesn't always catch orphans, for example,
if they never schedule after they are orphaned. IOW, the event leak is
still very real. It also wouldn't work for kernel counters.
Doing it synchonously is a little hairy due to lock inversion issues,
but is made to work.
Patch based on work by Alexander Shishkin.
Suggested-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: vince@deater.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
There are two concepts of owner wrt an event and they are conflated:
- event::owner / event::owner_list,
used by prctl(.option = PR_TASK_PERF_EVENTS_{EN,DIS}ABLE).
- the 'owner' of the event object, typically the file descriptor.
Currently these two concepts are conflated, which gives trouble with
scm_rights passing of file descriptors. Passing the event and then
closing the creating task would render the event 'orphan' and would
have it cleared out. Unlikely what is expectd.
This patch untangles these two concepts by using PERF_EVENT_STATE_EXIT
to denote the second type.
Reported-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
In preparation to adding more options, convert the boolean argument
into a flags word.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
sync_child_event() has outgrown its purpose, it does far too much.
Bring it back to its named purpose.
Rename __perf_event_exit_task() to perf_event_exit_event() to better
reflect what it does and move the event->state assignment under the
ctx->lock, like state changes ought to be.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Use smp_store_release() to clear event->owner and
lockless_dereference() to observe it. Further use READ_ONCE() for all
lockless reads.
This changes perf_remove_from_owner() to leave event->owner cleared.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
We should never attempt to enable a STATE_EXIT event.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
There is but a single caller, remove the function - we already have
_free_event(), the extra indirection is nonsensical..
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
When calling intel_alt_er() with .idx != EXTRA_REG_RSP_* we will not
initialize alt_idx and then use this uninitialized value to index an
array.
When that is not fatal, it can result in an infinite loop in its
caller __intel_shared_reg_get_constraints(), with IRQs disabled.
Alternative error modes are random memory corruption due to the
cpuc->shared_regs->regs[] array overrun, which manifest in either
get_constraints or put_constraints doing weird stuff.
Only took 6 hours of painful debugging to find this. Neither GCC nor
Smatch warnings flagged this bug.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Kan Liang <kan.liang@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Fixes: ae3f011fc2 ("perf/x86/intel: Fix SLM MSR_OFFCORE_RSP1 valid_mask")
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Previously, speakup would always read the non-scrolled part of the VT,
even when the VT is scrolled back with shift-page. This patch makes
vt.c export screen_pos so that speakup can use it to properly access
the content of the scrolled-back VT.
This was tested with both vgacon and fbcon.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Reviewed-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit f79b0d9c22 ("staging: speakup: Fixed warning <linux/serial.h>
instead of <asm/serial.h>") broke the port information in the speakup
driver: SERIAL_PORT_DFNS only gets defined if asm/serial.h is included,
and no other header includes asm/serial.h.
We here make sure serialio.c does get the arch-specific definition of
SERIAL_PORT_DFNS from asm/serial.h, if any.
Along the way, this makes sure that we do have information for the
requested serial port number (index)
Fixes: f79b0d9c22 ("staging: speakup: Fixed warning <linux/serial.h> instead of <asm/serial.h>")
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Cc: stable <stable@vger.kernel.org> # 3.18
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vendor ID 0x10de0083 is used by a yet-to-be-named GPU chip.
This chip also has the 2-ch audio swapping bug, so patch_nvhdmi is
appropriate here.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The first is a cut and paste issue that changed the amount of stack
to skip when tracing a stack dump from 0 to 6, which basically made
the stack disappear for small stack traces.
The second fix is just removing an unused field in a struct that is no
longer used, and currently just wastes space.
The third is another cut-and-paste fix that had a tracepoint recording
the wrong field (it was recording the previous field a second time).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJWqibPAAoJEKKk/i67LK/8/NkH/3M6WB7RIiMMd4O403imbKcs
yIH0j9vH6Z5hwoAUUr0bEw+gHVgzsiRky5z+fP0f1J3QdVAdgEig6RgQtIbWRynu
i7fohNAiSMBob0wOIHTohQDKkQjvgoO9gO5S8nY6Axgpf4iqOTy3RF2a/gcltULY
qdgy9A0vLk6yMbP6c0P+kEzg4y+Q90DsUh8YzQKW7F1EJPneDmNdug3VM16gefTR
4yrodSBHxr8NV3kAhN8G7FjWmK5cBDFwD66vsti64mKVCW00hjYRCQ+5BrgQ7h0V
EDC7kHisckLb415SQxe8XdF4fKbfE1PuQYZhjTo02hx9XCMeyxDWbjTF2PrZCHw=
=gab6
-----END PGP SIGNATURE-----
Merge tag 'trace-v4.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
Pull minor tracing fixes from Steven Rostedt:
"This includes three minor fixes, mostly due to cut-and-paste issues.
The first is a cut and paste issue that changed the amount of stack to
skip when tracing a stack dump from 0 to 6, which basically made the
stack disappear for small stack traces.
The second fix is just removing an unused field in a struct that is no
longer used, and currently just wastes space.
The third is another cut-and-paste fix that had a tracepoint recording
the wrong field (it was recording the previous field a second time)"
* tag 'trace-v4.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
tracing/dma-buf/fence: Fix timeline str value on fence_annotate_wait_on
ftrace: Remove unused nr_trampolines var
tracing: Fix stacktrace skip depth in trace_buffer_unlock_commit_regs()
Here are some fixes for drm/rockchip, these fixes base on drm-next.
These fixes works on my popmetal(rk3288) board.
About patch: drm/atomic-helper: Export framebuffer_changed()
Daniel Vetter ack for merging it through rockchip git trees, so framebuffer_changed() can be reused by drm/rockchip.
All others looks good, so I'd like you can land them.
* 'drm-rockchip-next-fixes-2016-01-22' of https://github.com/markyzq/kernel-drm-rockchip:
drm/rockchip: respect CONFIG_DRM_FBDEV_EMULATION
drm/rockchip: fix wrong pitch/size using on gem
drm/rockchip: explain why we can't wait_for_vblanks
drm/rockchip: don't wait for vblank if fb hasn't changed
drm/atomic-helper: Export framebuffer_changed()
drm/rockchip/dsi: fix handling mipi_dsi_pixel_format_to_bpp result
drm/rockchip: vop: fix mask when updating interrupts
drm/rockchip: cleanup unnecessary export symbol
drm/rockchip: Don't build rockchip_drm_vop as modules
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>.
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
vc4.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABCgAGBQJWnqxfAAoJELXWKTbR/J7oIUQQAIswWnwRLqsNU+2gX6+rG20i
SA5KsUidfi644MPMzR5t5js57EkV8r70mtMhoZ3cU5VYXOdk6WdnN0OQVIrd5inb
wQILCb2e0kWUZ39+TLeIGEmQ482+bp6yM1jVijxTrvvv/tpyI5cDIezVVzdDjWW4
Ah1vXpfppTFlTWwe9ZNrNjcmqIw4oQ2mQMnEFhTUbZnUPOqPnSC6/ZCOvybgV1E9
xsn6Gk+eLPxjKmNucFMtnjdlE6hGNlL+N0IZmPRzc0imoGgzUFQoQiSKROkMbJE0
NGNvPzTux82B4PR0q9yQHu4PrhNiBG2GT2HibrT5QrliwK489bKXcGG0Kh6hHGCl
RUUkB1fk1daxf8XTE9aBv4s+XnWzeeGOiqsVPG+BNCfc6IoYKPTN0a0jzfy0tk+g
sZMjB3r1xY1lS2IHyJ9fAGH86SmSpQPqjap8t0KRnFqORj03ch67GJLOYlVHVqu2
avngB/ByGVcFMElC8ccp2d3rbxKjDwDdBsFFn685hOSYE+ZkGQRpF2FRA6JplcHf
xKzfbyhjzwURhJMVjz2F5ZNl+qGC1SAaI9BMFaw+PmW2PPtffHHITO1PwRpbQA7K
UM5Z3GTB6JFOqTbMutltjUVKUsH48HLQMoQMBvAE8xg5o/GPaUXRn1FKQH1lBeuT
zucC/MZBqHffFSlbqpuj
=Qvir
-----END PGP SIGNATURE-----
Merge tag 'drm-vc4-fixes-2015-01-19' of http://github.com/anholt/linux into drm-fixes
This pull request just includes the !CONFIG_PM_SLEEP build fix for
vc4.
* tag 'drm-vc4-fixes-2015-01-19' of http://github.com/anholt/linux:
drm/vc4: Remove broken attempt at GPU reset using genpd.
A bunch of etnaviv fixes for 4.5-rc. Most of them are fixing
things in code paths that will only be hit if something goes
wrong, which have been unearthed by more extensive testing.
The only thing that doesn't really qualify as fixes is an UAPI
extension that userspace wants to rely on being present, so
I want to fast-track this into 4.5 before etnaviv ends up in a
released kernel.
* 'drm-etnaviv-fixes' of git://git.pengutronix.de/git/lst/linux:
drm/etnaviv: call correct function when trying to vmap a DMABUF
drm/etnaviv: rename etnaviv_gem_vaddr to etnaviv_gem_vmap
drm/etnaviv: fix get pages error path in etnaviv_gem_vaddr
drm/etnaviv: fix memory leak in IOMMU init path
drm/etnaviv: add further minor features and varyings count
drm/etnaviv: add helper for comparing model/revision IDs
drm/etnaviv: add helper to extract bitfields
drm/etnaviv: use defined constants for the chip model
drm/etnaviv: update common and state_hi xml.h files
drm/etnaviv: ignore VG GPUs with FE2.0
drm/etnaviv: fix failure path if model is zero
drm/etnaviv: hold object lock while getting pages for coredump
drm/etnaviv: remove owner assignment from platform_driver
Misc radeon and amdgpu fixes:
- SMU firmware loading fix for Stoney
- DP audio fixes for DCE4.1
- Don't expose fbdev device if no connectors
- fix page table LRU list update handling
* 'drm-fixes-4.5' of git://people.freedesktop.org/~agd5f/linux:
drm/amdgpu: only move pt bos in LRU list on success
drm/radeon: fix DP audio support for APU with DCE4.1 display engine
drm/radeon: Add a common function for DFS handling
drm/radeon: cleaned up VCO output settings for DP audio
drm/amd/powerplay: Update SMU firmware loading for Stoney
drm/amdgpu: don't init fbdev if we don't have any connectors
drm/radeon: only init fbdev if we have connectors
drm/radeon: Ensure radeon bo is unreserved in radeon_gem_va_ioctl
drm/amdgpu: fix next_rptr handling for debugfs
drm/radeon: properly byte swap vce firmware setup
drm/amdgpu: add a message to indicate when powerplay is enabled (v2)
drm/amdgpu: fix amdgpu_bo_pin_restricted VRAM placing v2
drm/amd/amdgpu: Improve amdgpu_dpm* macros to avoid unexpected result (v2)
drm/amdgpu: Allow the driver to load if amdgpu.powerplay=1 on asics without powerplay support
drm/amdgpu: Use drm_calloc_large for VM page_tables array
drm/amdgpu: Add some tweaks to gfx 8 soft reset
drm/amdgpu: fix tonga smu resume
There is a race between perf_event_exit_task_context() and
orphans_remove_work() which results in a use-after-free.
We mark ctx->task with TASK_TOMBSTONE to indicate a context is
'dead', under ctx->lock. After which point event_function_call()
on any event of that context will NOP
A concurrent orphans_remove_work() will only hold ctx->mutex for
the list iteration and not serialize against this. Therefore its
possible that orphans_remove_work()'s perf_remove_from_context()
call will fail, but we'll continue to free the event, with the
result of free'd memory still being on lists and everything.
Once perf_event_exit_task_context() gets around to acquiring
ctx->mutex it too will iterate the event list, encounter the
already free'd event and proceed to free it _again_. This fails
with the WARN in free_event().
Plug the race by having perf_event_exit_task_context() hold
ctx::mutex over the whole tear-down, thereby 'naturally'
serializing against all other sites, including the orphan work.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: alexander.shishkin@linux.intel.com
Cc: dsahern@gmail.com
Cc: namhyung@kernel.org
Link: http://lkml.kernel.org/r/20160125130954.GY6357@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
We should set event->owner before we install the event,
otherwise there is a hole where the target task can fork() and
we'll not inherit the event because it thinks the event is
orphaned.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
This fixes a race condition in the error case: since the pt bos have not
necessarily been reserved in case of an error, we could move a pt bo that
is currently in the middle of being evicted/moved by another process,
which then resulted in a BUG_ON in ttm_bo_add_to_lru.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Here are two fixes of crashes in the visor driver that could be
triggered using bad (malicious) descriptors, a fix for two memory leaks
in the new mxu11x0 driver, and an interface-blacklist fix for the option
driver.
Included are also some new device ids.
Signed-off-by: Johan Hovold <johan@kernel.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJWqi2hAAoJEEEN5E/e4bSV5VQQALpo+SexxQJo4tzl33jaSU03
QMWAqld5UHwmKxzMXOCMg+XBFSfkU3W+EtxrSJl/HCOSWeCveDTvPFEmjgXkfZGq
aJvW8bmg/a7lTwk+Fv9For1zlAv0OEpAFv1i9L+U3LI39lUn9eG2OgsOisnnvlww
ay0lQ21CH5ta7RVbsTnxpLVWsuvEuhR75pIXKwpvGoGui5KU2HnNDTsjit5Ih9kn
dYJZJVozry6xknQ651wHR5jm/40fFJ8J/xmDlJlMxu3Y6CyN8BCGKlM0yc/Qujgz
/7Gm52b3qt5EhEvbt+vopg4iy3JhG9S/GNtMGxoUETlqaGz1v2cwUsMTI48yHKP2
ihVVKeRaVrYyoipg9/pKno8bnWouiFdSRm/rmKVl1XltM5Z7il7QTrRscrJflV2L
MFKVILrRn78o8tLqkbJbpB1HpPpCXGdsjgv9kMNwb0A/qdiYCWCXWTxPNC1XOA9X
t2yOLsD4tGkc3llNvIuDCX9U5gyokff7hY1z01IVbIkCKLxrI3paxGVx1M59QqfE
G2QeyC6rJXvev/3EOAQf/r38TqIzaohkTikAJRaMXoGDlWQEGH3JkmnTnY/lSxZS
LZCgz7m2JIe/6lUIlM3a0f2SudyCkd0rMnSfO6jzbt/iP56ggPnHS4uAzjaSdMqJ
/uQs6Kbamq1d8cqiARwJ
=SxKT
-----END PGP SIGNATURE-----
Merge tag 'usb-serial-4.5-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus
Johan writes:
USB-serial fixes for v4.5-rc2
Here are two fixes of crashes in the visor driver that could be
triggered using bad (malicious) descriptors, a fix for two memory leaks
in the new mxu11x0 driver, and an interface-blacklist fix for the option
driver.
Included are also some new device ids.
Signed-off-by: Johan Hovold <johan@kernel.org>
This was wrongly updated by commit 7aa9a23c69 ("powerpc, thp: remove
infrastructure for handling splitting PMDs") during the last merge
window. Fix it up.
This could lead to incorrect behaviour in THP and/or mprotect(), at a
minimum.
Fixes: 7aa9a23c69 ("powerpc, thp: remove infrastructure for handling splitting PMDs")
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Commit 7a7868326d ("powerpc/perf: Add an explict flag indicating
presence of SLOT field") introduced the PPMU_HAS_SSLOT flag to remove
the assumption that MMCRA[SLOT] was present when PPMU_ALT_SIPR was not
set.
That commit's changelog also mentions that Power8 does not support
MMCRA[SLOT]. However when the Power8 PMU support was merged, it
errnoeously included the PPMU_HAS_SSLOT flag.
So remove PPMU_HAS_SSLOT from the Power8 flags.
mpe: On systems where MMCRA[SLOT] exists, the field occupies bits 37:39
(IBM numbering). On Power8 bit 37 is reserved, and 38:39 overlap with
the high bits of the Threshold Event Counter Mantissa. I am not aware of
any published events which use the threshold counting mechanism, which
would cause the mantissa bits to be set. So in practice this bug is
unlikely to trigger.
Fixes: e05b9b9e5c ("powerpc/perf: Power8 PMU support")
Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
ALSA dummy driver can switch the timer backend between system timer
and hrtimer via its hrtimer module option. This can be also switched
dynamically via sysfs, but it may lead to a memory corruption when
switching is done while a PCM stream is running; the stream instance
for the newly switched timer method tries to access the memory that
was allocated by another timer method although the sizes differ.
As the simplest fix, this patch just disables the switch via sysfs by
dropping the writable bit.
BugLink: http://lkml.kernel.org/r/CACT4Y+ZGEeEBntHW5WHn2GoeE0G_kRrCmUh6=dWyy-wfzvuJLg@mail.gmail.com
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
KEY_FLAG_KEEP should only be applied to a key if the keyring it is being
linked into has KEY_FLAG_KEEP set.
To this end, partially revert the following patch:
commit 1d6d167c2e
Author: Mimi Zohar <zohar@linux.vnet.ibm.com>
Date: Thu Jan 7 07:46:36 2016 -0500
KEYS: refcount bug fix
to undo the change that made it unconditional (Mimi got it right the first
time).
Without undoing this change, it becomes impossible to delete, revoke or
invalidate keys added to keyrings through __key_instantiate_and_link()
where the keyring has itself been linked to. To test this, run the
following command sequence:
keyctl newring foo @s
keyctl add user a a %:foo
keyctl unlink %user:a %:foo
keyctl clear %:foo
With the commit mentioned above the third and fourth commands fail with
EPERM when they should succeed.
Reported-by: Stephen Gallager <sgallagh@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
cc: Mimi Zohar <zohar@linux.vnet.ibm.com>
cc: keyrings@vger.kernel.org
cc: stable@vger.kernel.org
Signed-off-by: James Morris <james.l.morris@oracle.com>
gcc warns quite a bit about values returned from allocate_resources()
in cpufreq-dt.c:
cpufreq-dt.c: In function 'cpufreq_init':
cpufreq-dt.c:327:6: error: 'cpu_dev' may be used uninitialized in this function [-Werror=maybe-uninitialized]
cpufreq-dt.c:197:17: note: 'cpu_dev' was declared here
cpufreq-dt.c:376:2: error: 'cpu_clk' may be used uninitialized in this function [-Werror=maybe-uninitialized]
cpufreq-dt.c:199:14: note: 'cpu_clk' was declared here
cpufreq-dt.c: In function 'dt_cpufreq_probe':
cpufreq-dt.c:461:2: error: 'cpu_clk' may be used uninitialized in this function [-Werror=maybe-uninitialized]
cpufreq-dt.c:447:14: note: 'cpu_clk' was declared here
The problem is that it's slightly hard for gcc to follow return
codes across PTR_ERR() calls.
This patch uses explicit assignments to the "ret" variable to make
it easier for gcc to verify that the code is actually correct,
without the need to add a bogus initialization.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
There are two definitions of pxa_cpufreq_change_voltage, with slightly
different prototypes after one of them had its argument marked 'const'.
Now the other one (for !CONFIG_REGULATOR) produces a harmless warning:
drivers/cpufreq/pxa2xx-cpufreq.c: In function 'pxa_set_target':
drivers/cpufreq/pxa2xx-cpufreq.c:291:36: warning: passing argument 1 of 'pxa_cpufreq_change_voltage' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
ret = pxa_cpufreq_change_voltage(&pxa_freq_settings[idx]);
^
drivers/cpufreq/pxa2xx-cpufreq.c:205:12: note: expected 'struct pxa_freqs *' but argument is of type 'const struct pxa_freqs *'
static int pxa_cpufreq_change_voltage(struct pxa_freqs *pxa_freq)
^
This changes the prototype in the same way as the other, which
avoids the warning.
Fixes: 03c2299063 (cpufreq: pxa: make pxa_freqs arrays const)
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Cc: 4.2+ <stable@vger.kernel.org> # 4.2+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The APM emulation code does multiple things, and some of them depend on
PM_SLEEP, while the battery management does not. However, selecting
the symbol like SHARPSL_PM does causes a Kconfig warning:
warning: (SHARPSL_PM && PMAC_APM_EMU) selects APM_EMULATION which has unmet direct dependencies (PM && SYS_SUPPORTS_APM_EMULATION)
From all I can tell, this is completely harmless, and we can simply allow
APM_EMULATION to be enabled here, even if PM is not.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Currently next_policy() explicitly checks if a policy is the last
policy in the cpufreq_policy_list. Use the standard list_is_last
primitive instead.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This was found with the -RT patch enabled, but the fix should apply to
non-RT also.
Used multi_v7_defconfig+PREEMPT_RT_FULL=y and this caused a compilation
warning without this fix:
../drivers/cpuidle/coupled.c:122:21: warning: 'cpuidle_coupled_lock'
defined but not used [-Wunused-variable]
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
We must preserve the same order of how we acquire and release the lock for
genpd, as otherwise we may encounter deadlocks.
The power on phase of a genpd starts by acquiring its lock. Then it walks
the hierarchy of its parent domains to be able to power on these first, as
per design of genpd.
From a locking perspective this means the locks of the parents becomes
acquired after the lock of the subdomain.
Let's fix pm_genpd_add|remove_subdomain() to maintain the same order of
acquiring/releasing the genpd lock as being applied in the power on/off
sequence.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This fixes existing tests broken by barrier rework,
and adds some new tests.
Plus, there's a fix for an old bug in virtio-pci.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJWp1yPAAoJECgfDbjSjVRpoEoH/0wHh1vFd1qcuWl78DHHX0fQ
bPY0F2u8Z50xJmn5IRpKeaWTTo1Fet5tWbu6YAymx/6A5BCRao6BxOGAV3cmfDIg
Y9ipb7WGyCYiqZvxydWnK4/ss9/qKuwrRAukBewS7Ggu41WzM2Ui/Ksmq3dqpgsp
ZyJaXOCgESNpQ01ScKrANQlQ01T6+jAZu2fY7sO67YXQXjI91oQqI2Ox52GOPXQK
fFEAyPb9kYsEcBRwN6hl/w/yb34j+735tA/f0VA7DrEpXmyez4hG3bGTIbG4KcW3
QpjuBScL0Ik3wLjZgixOPQza44FhQBi8QNIjW0mSoracRyQ9ZZPhYYtBkKX33xk=
=aJRN
-----END PGP SIGNATURE-----
Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost
Pull virtio tests and fixes from Michael Tsirkin:
"This fixes existing tests broken by barrier rework, and adds some new
tests.
Plus, there's a fix for an old bug in virtio-pci"
* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
tools/virtio: add ringtest utilities
sh: fix smp_store_mb for !SMP
tools/virtio: use virt_xxx barriers
virtio_pci: fix use after free on release
This reverts commit 5bdb102b3f.
Brian Norris <computersforpeace@gmail.com> is reporting:
Ralf,
Please revert this and send it to Linus (or else, I can send it myself).
This is causing build failures, because I didn't take the rest of
Simon's series yet.
drivers/mtd/bcm63xxpart.c: In function 'bcm63xx_parse_cfe_partitions':
drivers/mtd/bcm63xxpart.c:93:2: error: implicit declaration of function
'bcm63xx_nvram_get_psi_size' [-Werror=implicit-function-declaration]
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
References: https://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=20160126191607.GA111152%40google.com
- Ensure we don't access PMU registers of the PMU is not implemented
(fixes booting under QEMU)
- Fix BUG_ON triggered during module loading with DEBUG_SET_MODULE_RONX
- Ensure the kasan zero page is read-only
- Hide __efistub_ symbol aliases from kallsyms, since they otherwise
confuse the backtrace code
- Ensure !PTE_WRITE kernel ptes are marked as read-only
- defconfig updates based on requests and patches on the list
- Other minor fixes (typos, build system)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABCgAGBQJWp7gyAAoJELescNyEwWM0At0H/2o0GeFS2mEQILShWv7SHaPG
Fvon25UTHPwfS5zhejtBYpuISJZTFql4KBKtoT6dHxf4U+gb+zicSZJHlkoxJfRV
8JBD5DmS2OcO9+JtgAey5O1w0yZ9prVr45QQrLmDGZBDKV9AivT31I/BNnnq3LWJ
dg9pbHrvLanR54qpYjWoW0S0Sop93XCHc8y2Q66hDFrG3zkXkQfy6VCsJq/LdnAp
wlCY/5QbbKufm+LP0jpmefq6brCGh0v7bCpOO3nwSPtD1iMrT6odAKjiBmPeE59r
XvOd5g760tZnVLSeLR0Iqq9PLdsdBvd5gHQlMfyBAIt7xhfEEH7b8Tthh1bSRPU=
=ldNV
-----END PGP SIGNATURE-----
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull arm64 fixes from Will Deacon:
"The main thing here is to get us booting under qemu again after it
turned out that not all of the PMU registers are emulated there,
causing us to die early in boot.
- Ensure we don't access PMU registers of the PMU is not implemented
(fixes booting under QEMU)
- Fix BUG_ON triggered during module loading with DEBUG_SET_MODULE_RONX
- Ensure the kasan zero page is read-only
- Hide __efistub_ symbol aliases from kallsyms, since they otherwise
confuse the backtrace code
- Ensure !PTE_WRITE kernel ptes are marked as read-only
- defconfig updates based on requests and patches on the list
- Other minor fixes (typos, build system)"
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64: mm: avoid calling apply_to_page_range on empty range
arm64: defconfig: updates for 4.5
arm64: errata: Add -mpc-relative-literal-loads to build flags
Eliminate the .eh_frame sections from the aarch64 vmlinux and kernel modules
arm64: Fix an enum typo in mm/dump.c
arm64: Honour !PTE_WRITE in set_pte_at() for kernel mappings
arm64: kernel: fix architected PMU registers unconditional access
arm64: kasan: ensure that the KASAN zero page is mapped read-only
arm64: hide __efistub_ aliases from kallsyms
The email address <ao2@amarulasolutions.com> is not active anymore, use
Antonio's personal email address <ao2@ao2.it> in case someone wants to
get in touch for the code wrote for Amarula Solutions.
Signed-off-by: Antonio Ospite <ao2@ao2.it>
Cc: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Using iommu_present() to determine whether an IOMMU group is real or
fake has some problems. First, apparently Power systems don't
register an IOMMU on the device bus, so the groups and containers get
marked as noiommu and then won't bind to their actual IOMMU driver.
Second, I expect we'll run into the same issue as we try to support
vGPUs through vfio, since they're likely to emulate this behavior of
creating an IOMMU group on a virtual device and then providing a vfio
IOMMU backend tailored to the sort of isolation they provide, which
won't necessarily be fully compatible with the IOMMU API.
The solution here is to use the existing iommudata interface to IOMMU
groups, which allows us to easily identify the fake groups we've
created for noiommu purposes. The iommudata we set is purely
arbitrary since we're only comparing the address, so we use the
address of the noiommu switch itself.
Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Tested-by: Anatoly Burakov <anatoly.burakov@intel.com>
Tested-by: Santosh Shukla <sshukla@mvista.com>
Fixes: 03a76b60f8 ("vfio: Include No-IOMMU mode")
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Properly setup the DFS divider for DP audio for DCE4.1.
Signed-off-by: Slava Grigorev <slava.grigorev@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Move encoding of DFS (digital frequency synthesizer) divider into a
separate function and improve calculation precision.
Signed-off-by: Slava Grigorev <slava.grigorev@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Peter Zijlstra