Takashi Iwai [Tue, 12 Jan 2016 13:03:33 +0000 (14:03 +0100)]
ALSA: usb-audio: Avoid calling usb_autopm_put_interface() at disconnect
[ Upstream commit
5c06d68bc2a174a6b82dce9f100f55173b9a5189 ]
ALSA PCM may still have a leftover instance after disconnection and
it delays its release. The problem is that the PCM close code path of
USB-audio driver has a call of snd_usb_autosuspend(). This involves
with the call of usb_autopm_put_interface() and it may lead to a
kernel Oops due to the NULL object like:
BUG: unable to handle kernel NULL pointer dereference at
0000000000000190
IP: [<
ffffffff815ae7ef>] usb_autopm_put_interface+0xf/0x30 PGD 0
Call Trace:
[<
ffffffff8173bd94>] snd_usb_autosuspend+0x14/0x20
[<
ffffffff817461bc>] snd_usb_pcm_close.isra.14+0x5c/0x90
[<
ffffffff8174621f>] snd_usb_playback_close+0xf/0x20
[<
ffffffff816ef58a>] snd_pcm_release_substream.part.36+0x3a/0x90
[<
ffffffff816ef6b3>] snd_pcm_release+0xa3/0xb0
[<
ffffffff816debb0>] snd_disconnect_release+0xd0/0xe0
[<
ffffffff8114d417>] __fput+0x97/0x1d0
[<
ffffffff8114d589>] ____fput+0x9/0x10
[<
ffffffff8109e452>] task_work_run+0x72/0x90
[<
ffffffff81088510>] do_exit+0x280/0xa80
[<
ffffffff8108996a>] do_group_exit+0x3a/0xa0
[<
ffffffff8109261f>] get_signal+0x1df/0x540
[<
ffffffff81040903>] do_signal+0x23/0x620
[<
ffffffff8114c128>] ? do_readv_writev+0x128/0x200
[<
ffffffff810012e1>] prepare_exit_to_usermode+0x91/0xd0
[<
ffffffff810013ba>] syscall_return_slowpath+0x9a/0x120
[<
ffffffff817587cd>] ? __sys_recvmsg+0x5d/0x70
[<
ffffffff810d2765>] ? ktime_get_ts64+0x45/0xe0
[<
ffffffff8115dea0>] ? SyS_poll+0x60/0xf0
[<
ffffffff818d2327>] int_ret_from_sys_call+0x25/0x8f
We have already a check of disconnection in snd_usb_autoresume(), but
the check is missing its counterpart. The fix is just to put the same
check in snd_usb_autosuspend(), too.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109431
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Takashi Iwai [Tue, 25 Aug 2015 14:09:00 +0000 (16:09 +0200)]
ALSA: usb-audio: Avoid nested autoresume calls
[ Upstream commit
47ab154593827b1a8f0713a2b9dd445753d551d8 ]
After the recent fix of runtime PM for USB-audio driver, we got a
lockdep warning like:
=============================================
[ INFO: possible recursive locking detected ]
4.2.0-rc8+ #61 Not tainted
---------------------------------------------
pulseaudio/980 is trying to acquire lock:
(&chip->shutdown_rwsem){.+.+.+}, at: [<
ffffffffa0355dac>] snd_usb_autoresume+0x1d/0x52 [snd_usb_audio]
but task is already holding lock:
(&chip->shutdown_rwsem){.+.+.+}, at: [<
ffffffffa0355dac>] snd_usb_autoresume+0x1d/0x52 [snd_usb_audio]
This comes from snd_usb_autoresume() invoking down_read() and it's
used in a nested way. Although it's basically safe, per se (as these
are read locks), it's better to reduce such spurious warnings.
The read lock is needed to guarantee the execution of "shutdown"
(cleanup at disconnection) task after all concurrent tasks are
finished. This can be implemented in another better way.
Also, the current check of chip->in_pm isn't good enough for
protecting the racy execution of multiple auto-resumes.
This patch rewrites the logic of snd_usb_autoresume() & co; namely,
- The recursive call of autopm is avoided by the new refcount,
chip->active. The chip->in_pm flag is removed accordingly.
- Instead of rwsem, another refcount, chip->usage_count, is introduced
for tracking the period to delay the shutdown procedure. At
the last clear of this refcount, wake_up() to the shutdown waiter is
called.
- The shutdown flag is replaced with shutdown atomic count; this is
for reducing the lock.
- Two new helpers are introduced to simplify the management of these
refcounts; snd_usb_lock_shutdown() increases the usage_count, checks
the shutdown state, and does autoresume. snd_usb_unlock_shutdown()
does the opposite. Most of mixer and other codes just need this,
and simply returns an error if it receives an error from lock.
Fixes:
9003ebb13f61 ('ALSA: usb-audio: Fix runtime PM unbalance')
Reported-and-tested-by: Alexnader Kuleshov <kuleshovmail@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Julian Scheel [Fri, 14 Aug 2015 14:14:45 +0000 (16:14 +0200)]
ALSA: usb-audio: Fix parameter block size for UAC2 control requests
[ Upstream commit
bc18e31c3042f14fa5f2ff5c21136e2fdf4140f8 ]
USB Audio Class version 2.0 supports three different parameter block sizes for
CUR requests, which are 1 byte (5.2.3.1 Layout 1 Parameter Block), 2 bytes
(5.2.3.2 Layout 2 Parameter Block) and 4 bytes (5.2.3.3 Layout 3 Parameter
Block). Use the correct size according to the specific control as it was
already done for UACv1. The allocated block size for control requests is
increased to support the 4 byte worst case.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Johan Rastén [Thu, 11 Jun 2015 08:04:51 +0000 (10:04 +0200)]
ALSA: usb-audio: Set correct type for some UAC2 mixer controls.
[ Upstream commit
27c41dad3a012c5acead1d903d1743297457b69c ]
Changed ctl type for Input Gain Control and Input Gain Pad Control to
USB_MIXER_S16 as per section 5.2.5.7.11-12 in the USB Audio Class 2.0
definition.
Signed-off-by: Johan Rastén <johan@oljud.se>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
David Henningsson [Mon, 11 Jan 2016 08:33:14 +0000 (09:33 +0100)]
ALSA: hda - Fixup inverted internal mic for Lenovo E50-80
[ Upstream commit
56f27013482c0803d978b667fe85de04ce9357cd ]
Inform userspace that one channel of the internal mic has reversed
polarity, so it does not attempt to add both channels together and
end up with silence.
Cc: stable@vger.kernel.org
Reported-by: Andrzej Mendel <andrzej.mendel@gmail.com>
Alsa-info: http://www.alsa-project.org/db/?f=
3088f82a0cf977855f92af9db8ad406c04f71efa
BugLink: https://bugs.launchpad.net/bugs/1529624
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Sasha Levin [Sun, 3 Apr 2016 22:26:26 +0000 (18:26 -0400)]
Linux 4.1.21
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Alexander Shishkin [Thu, 24 Mar 2016 11:14:53 +0000 (11:14 +0000)]
perf/core: Fix perf_sched_count derailment
[ Upstream commit
927a5570855836e5d5859a80ce7e91e963545e8f ]
The error path in perf_event_open() is such that asking for a sampling
event on a PMU that doesn't generate interrupts will end up in dropping
the perf_sched_count even though it hasn't been incremented for this
event yet.
Given a sufficient amount of these calls, we'll end up disabling
scheduler's jump label even though we'd still have active events in the
system, thereby facilitating the arrival of the infernal regions upon us.
I'm fixing this by moving account_event() inside perf_event_alloc().
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: <stable@vger.kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@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: vince@deater.net
Link: http://lkml.kernel.org/r/1456917854-29427-1-git-send-email-alexander.shishkin@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: He Kuang <hekuang@huawei.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Peter Zijlstra [Thu, 24 Mar 2016 11:14:52 +0000 (11:14 +0000)]
perf: Cure event->pending_disable race
[ Upstream commit
28a967c3a2f99fa3b5f762f25cb2a319d933571b ]
Because event_sched_out() checks event->pending_disable _before_
actually disabling the event, it can happen that the event fires after
it checks but before it gets disabled.
This would leave event->pending_disable set and the queued irq_work
will try and process it.
However, if the event trigger was during schedule(), the event might
have been de-scheduled by the time the irq_work runs, and
perf_event_disable_local() will fail.
Fix this by checking event->pending_disable _after_ we call
event->pmu->del(). This depends on the latter being a compiler
barrier, such that the compiler does not lift the load and re-creates
the problem.
Tested-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
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: Thomas Gleixner <tglx@linutronix.de>
Cc: dvyukov@google.com
Cc: eranian@google.com
Cc: oleg@redhat.com
Cc: panand@redhat.com
Cc: sasha.levin@oracle.com
Cc: vince@deater.net
Link: http://lkml.kernel.org/r/20160224174948.040469884@infradead.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: He Kuang <hekuang@huawei.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Peter Zijlstra [Thu, 24 Mar 2016 11:14:51 +0000 (11:14 +0000)]
perf: Do not double free
[ Upstream commit
130056275ade730e7a79c110212c8815202773ee ]
In case of: err_file: fput(event_file), we'll end up calling
perf_release() which in turn will free the event.
Do not then free the event _again_.
Tested-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
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: Thomas Gleixner <tglx@linutronix.de>
Cc: dvyukov@google.com
Cc: eranian@google.com
Cc: oleg@redhat.com
Cc: panand@redhat.com
Cc: sasha.levin@oracle.com
Cc: vince@deater.net
Link: http://lkml.kernel.org/r/20160224174947.697350349@infradead.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: He Kuang <hekuang@huawei.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Yang Shi [Thu, 24 Mar 2016 11:14:50 +0000 (11:14 +0000)]
arm64: replace read_lock to rcu lock in call_step_hook
[ Upstream commit
cf0a25436f05753aca5151891aea4fd130556e2a ]
BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:917
in_atomic(): 1, irqs_disabled(): 128, pid: 383, name: sh
Preemption disabled at:[<
ffff800000124c18>] kgdb_cpu_enter+0x158/0x6b8
CPU: 3 PID: 383 Comm: sh Tainted: G W 4.1.13-rt13 #2
Hardware name: Freescale Layerscape 2085a RDB Board (DT)
Call trace:
[<
ffff8000000885e8>] dump_backtrace+0x0/0x128
[<
ffff800000088734>] show_stack+0x24/0x30
[<
ffff80000079a7c4>] dump_stack+0x80/0xa0
[<
ffff8000000bd324>] ___might_sleep+0x18c/0x1a0
[<
ffff8000007a20ac>] __rt_spin_lock+0x2c/0x40
[<
ffff8000007a2268>] rt_read_lock+0x40/0x58
[<
ffff800000085328>] single_step_handler+0x38/0xd8
[<
ffff800000082368>] do_debug_exception+0x58/0xb8
Exception stack(0xffff80834a1e7c80 to 0xffff80834a1e7da0)
7c80:
ffffff9c ffffffff 92c23ba0 0000ffff 4a1e7e40 ffff8083 001bfcc4 ffff8000
7ca0:
f2000400 00000000 00000000 00000000 4a1e7d80 ffff8083 0049501c ffff8000
7cc0:
00005402 00000000 00aaa210 ffff8000 4a1e7ea0 ffff8083 000833f4 ffff8000
7ce0:
ffffff9c ffffffff 92c23ba0 0000ffff 4a1e7ea0 ffff8083 001bfcc0 ffff8000
7d00:
4a0fc400 ffff8083 00005402 00000000 4a1e7d40 ffff8083 00490324 ffff8000
7d20:
ffffff9c 00000000 92c23ba0 0000ffff 000a0000 00000000 00000000 00000000
7d40:
00000008 00000000 00080000 00000000 92c23b8b 0000ffff 92c23b8e 0000ffff
7d60:
00000038 00000000 00001cb2 00000000 00000005 00000000 92d7b498 0000ffff
7d80:
01010101 01010101 92be9000 0000ffff 00000000 00000000 00000030 00000000
[<
ffff8000000833f4>] el1_dbg+0x18/0x6c
This issue is similar with 62c6c61("arm64: replace read_lock to rcu lock in
call_break_hook"), but comes to single_step_handler.
This also solves kgdbts boot test silent hang issue on 4.4 -rt kernel.
Signed-off-by: Yang Shi <yang.shi@linaro.org>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: He Kuang <hekuang@huawei.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Yang Shi [Thu, 24 Mar 2016 11:14:49 +0000 (11:14 +0000)]
arm64: replace read_lock to rcu lock in call_break_hook
[ Upstream commit
62c6c61adbc623cdacf74b8f29c278e539060c48 ]
BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:917
in_atomic(): 0, irqs_disabled(): 128, pid: 342, name: perf
1 lock held by perf/342:
#0: (break_hook_lock){+.+...}, at: [<
ffffffc0000851ac>] call_break_hook+0x34/0xd0
irq event stamp: 62224
hardirqs last enabled at (62223): [<
ffffffc00010b7bc>] __call_rcu.constprop.59+0x104/0x270
hardirqs last disabled at (62224): [<
ffffffc0000fbe20>] vprintk_emit+0x68/0x640
softirqs last enabled at (0): [<
ffffffc000097928>] copy_process.part.8+0x428/0x17f8
softirqs last disabled at (0): [< (null)>] (null)
CPU: 0 PID: 342 Comm: perf Not tainted 4.1.6-rt5 #4
Hardware name: linux,dummy-virt (DT)
Call trace:
[<
ffffffc000089968>] dump_backtrace+0x0/0x128
[<
ffffffc000089ab0>] show_stack+0x20/0x30
[<
ffffffc0007030d0>] dump_stack+0x7c/0xa0
[<
ffffffc0000c878c>] ___might_sleep+0x174/0x260
[<
ffffffc000708ac8>] __rt_spin_lock+0x28/0x40
[<
ffffffc000708db0>] rt_read_lock+0x60/0x80
[<
ffffffc0000851a8>] call_break_hook+0x30/0xd0
[<
ffffffc000085a70>] brk_handler+0x30/0x98
[<
ffffffc000082248>] do_debug_exception+0x50/0xb8
Exception stack(0xffffffc00514fe30 to 0xffffffc00514ff50)
fe20:
00000000 00000000 c1594680 0000007f
fe40:
ffffffff ffffffff 92063940 0000007f 0550dcd8 ffffffc0 00000000 00000000
fe60:
0514fe70 ffffffc0 000be1f8 ffffffc0 0514feb0 ffffffc0 0008948c ffffffc0
fe80:
00000004 00000000 0514fed0 ffffffc0 ffffffff ffffffff 9282a948 0000007f
fea0:
00000000 00000000 9282b708 0000007f c1592820 0000007f 00083914 ffffffc0
fec0:
00000000 00000000 00000010 00000000 00000064 00000000 00000001 00000000
fee0:
005101e0 00000000 c1594680 0000007f c1594740 0000007f ffffffd8 ffffff80
ff00:
00000000 00000000 00000000 00000000 c1594770 0000007f c1594770 0000007f
ff20:
00665e10 00000000 7f7f7f7f 7f7f7f7f 01010101 01010101 00000000 00000000
ff40:
928e4cc0 0000007f 91ff11e8 0000007f
call_break_hook is called in atomic context (hard irq disabled), so replace
the sleepable lock to rcu lock, replace relevant list operations to rcu
version and call synchronize_rcu() in unregister_break_hook().
And, replace write lock to spinlock in {un}register_break_hook.
Signed-off-by: Yang Shi <yang.shi@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: He Kuang <hekuang@huawei.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Jan Kara [Mon, 7 Dec 2015 19:34:49 +0000 (14:34 -0500)]
ext4: fix races of writeback with punch hole and zero range
When doing delayed allocation, update of on-disk inode size is postponed
until IO submission time. However hole punch or zero range fallocate
calls can end up discarding the tail page cache page and thus on-disk
inode size would never be properly updated.
Make sure the on-disk inode size is updated before truncating page
cache.
Signed-off-by: Jan Kara <jack@suse.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Mingming Cao <mingming.cao@oracle.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Jan Kara [Mon, 7 Dec 2015 19:31:11 +0000 (14:31 -0500)]
ext4: fix races between buffered IO and collapse / insert range
Current code implementing FALLOC_FL_COLLAPSE_RANGE and
FALLOC_FL_INSERT_RANGE is prone to races with buffered writes and page
faults. If buffered write or write via mmap manages to squeeze between
filemap_write_and_wait_range() and truncate_pagecache() in the fallocate
implementations, the written data is simply discarded by
truncate_pagecache() although it should have been shifted.
Fix the problem by moving filemap_write_and_wait_range() call inside
i_mutex and i_mmap_sem. That way we are protected against races with
both buffered writes and page faults.
Signed-off-by: Jan Kara <jack@suse.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Mingming Cao <mingming.cao@oracle.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Jan Kara [Mon, 7 Dec 2015 19:29:17 +0000 (14:29 -0500)]
ext4: move unlocked dio protection from ext4_alloc_file_blocks()
Currently ext4_alloc_file_blocks() was handling protection against
unlocked DIO. However we now need to sometimes call it under i_mmap_sem
and sometimes not and DIO protection ranks above it (although strictly
speaking this cannot currently create any deadlocks). Also
ext4_zero_range() was actually getting & releasing unlocked DIO
protection twice in some cases. Luckily it didn't introduce any real bug
but it was a land mine waiting to be stepped on. So move DIO protection
out from ext4_alloc_file_blocks() into the two callsites.
Signed-off-by: Jan Kara <jack@suse.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Mingming Cao <mingming.cao@oracle.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Jan Kara [Mon, 7 Dec 2015 19:28:03 +0000 (14:28 -0500)]
ext4: fix races between page faults and hole punching
Currently, page faults and hole punching are completely unsynchronized.
This can result in page fault faulting in a page into a range that we
are punching after truncate_pagecache_range() has been called and thus
we can end up with a page mapped to disk blocks that will be shortly
freed. Filesystem corruption will shortly follow. Note that the same
race is avoided for truncate by checking page fault offset against
i_size but there isn't similar mechanism available for punching holes.
Fix the problem by creating new rw semaphore i_mmap_sem in inode and
grab it for writing over truncate, hole punching, and other functions
removing blocks from extent tree and for read over page faults. We
cannot easily use i_data_sem for this since that ranks below transaction
start and we need something ranking above it so that it can be held over
the whole truncate / hole punching operation. Also remove various
workarounds we had in the code to reduce race window when page fault
could have created pages with stale mapping information.
Signed-off-by: Jan Kara <jack@suse.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Mingming Cao <mingming.cao@oracle.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Hauke Mehrtens [Sun, 6 Mar 2016 21:28:56 +0000 (22:28 +0100)]
MIPS: Fix build error when SMP is used without GIC
[ Upstream commit
588bad2ef32cae7abad24d5ca2f4611a7a7fb2a2 ]
commit
7a50e4688dabb8005df39b2b992d76629b8af8aa upstream.
The MIPS_GIC_IPI should only be selected when MIPS_GIC is also
selected, otherwise it results in a compile error. smp-gic.c uses some
functions from include/linux/irqchip/mips-gic.h like
plat_ipi_call_int_xlate() which are only added to the header file when
MIPS_GIC is set. The Lantiq SoC does not use the GIC, but supports SMP.
The calls top the functions from smp-gic.c are already protected by
some #ifdefs
The first part of this was introduced in commit
72e20142b2bf ("MIPS:
Move GIC IPI functions out of smp-cmp.c")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/12774/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Markos Chandras [Thu, 9 Jul 2015 09:40:38 +0000 (10:40 +0100)]
MIPS: Kconfig: Disable MIPS MT and SMP implementations for R6
[ Upstream commit
5676319c91c8d668635ac0b9b6d9145c4fa418ac ]
R6 does not support the MIPS MT ASE and the CMP/SMP options so
restrict them in order to prevent users from selecting incompatible
SMP configuration for R6 cores. We also disable the CPS/SMP option
because its support hasn't been added to the CPS code yet.
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/10637/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Markos Chandras [Wed, 1 Jul 2015 08:31:14 +0000 (09:31 +0100)]
Revert "MIPS: Kconfig: Disable SMP/CPS for 64-bit"
[ Upstream commit
1c885357da2d3cf62132e611c0beaf4cdf607dd9 ]
This reverts commit
6ca716f2e5571d25a3899c6c5c91ff72ea6d6f5e.
SMP/CPS is now supported on 64bit cores.
Cc: <stable@vger.kernel.org> # 4.1
Reviewed-by: Paul Burton <paul.burton@imgtec.com>
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: stable@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/10592/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
James Hogan [Tue, 8 Mar 2016 16:47:53 +0000 (16:47 +0000)]
ld-version: Fix awk regex compile failure
[ Upstream commit
4b7b1ef2c2f83d702272555e8adb839a50ba0f8e ]
The ld-version.sh script fails on some versions of awk with the
following error, resulting in build failures for MIPS:
awk: scripts/ld-version.sh: line 4: regular expression compile failed (missing '(')
This is due to the regular expression ".*)", meant to strip off the
beginning of the ld version string up to the close bracket, however
brackets have a meaning in regular expressions, so lets escape it so
that awk doesn't expect a corresponding open bracket.
Fixes:
ccbef1674a15 ("Kbuild, lto: add ld-version and ld-ifversion ...")
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Tested-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
Cc: Michal Marek <mmarek@suse.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: linux-mips@linux-mips.org
Cc: linux-kbuild@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org # 4.4.x-
Patchwork: https://patchwork.linux-mips.org/patch/12838/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Ludovic Desroches [Thu, 10 Mar 2016 09:17:55 +0000 (10:17 +0100)]
dmaengine: at_xdmac: fix residue computation
[ Upstream commit
25c5e9626ca4d40928dc9c44f009ce2ed0a739e7 ]
When computing the residue we need two pieces of information: the current
descriptor and the remaining data of the current descriptor. To get
that information, we need to read consecutively two registers but we
can't do it in an atomic way. For that reason, we have to check manually
that current descriptor has not changed.
Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Suggested-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Reported-by: David Engraf <david.engraf@sysgo.com>
Tested-by: David Engraf <david.engraf@sysgo.com>
Fixes:
e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel
eXtended DMA Controller driver")
Cc: stable@vger.kernel.org #4.1 and later
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Paolo Bonzini [Tue, 8 Mar 2016 11:13:39 +0000 (12:13 +0100)]
KVM: MMU: fix ept=0/pte.u=1/pte.w=0/CR0.WP=0/CR4.SMEP=1/EFER.NX=0 combo
[ Upstream commit
844a5fe219cf472060315971e15cbf97674a3324 ]
Yes, all of these are needed. :) This is admittedly a bit odd, but
kvm-unit-tests access.flat tests this if you run it with "-cpu host"
and of course ept=0.
KVM runs the guest with CR0.WP=1, so it must handle supervisor writes
specially when pte.u=1/pte.w=0/CR0.WP=0. Such writes cause a fault
when U=1 and W=0 in the SPTE, but they must succeed because CR0.WP=0.
When KVM gets the fault, it sets U=0 and W=1 in the shadow PTE and
restarts execution. This will still cause a user write to fault, while
supervisor writes will succeed. User reads will fault spuriously now,
and KVM will then flip U and W again in the SPTE (U=1, W=0). User reads
will be enabled and supervisor writes disabled, going back to the
originary situation where supervisor writes fault spuriously.
When SMEP is in effect, however, U=0 will enable kernel execution of
this page. To avoid this, KVM also sets NX=1 in the shadow PTE together
with U=0. If the guest has not enabled NX, the result is a continuous
stream of page faults due to the NX bit being reserved.
The fix is to force EFER.NX=1 even if the CPU is taking care of the EFER
switch. (All machines with SMEP have the CPU_LOAD_IA32_EFER vm-entry
control, so they do not use user-return notifiers for EFER---if they did,
EFER.NX would be forced to the same value as the host).
There is another bug in the reserved bit check, which I've split to a
separate patch for easier application to stable kernels.
Cc: stable@vger.kernel.org
Cc: Andy Lutomirski <luto@amacapital.net>
Reviewed-by: Xiao Guangrong <guangrong.xiao@linux.intel.com>
Fixes:
f6577a5fa15d82217ca73c74cd2dcbc0f6c781dd
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Martin Schwidefsky [Mon, 15 Feb 2016 13:46:49 +0000 (14:46 +0100)]
s390/mm: four page table levels vs. fork
[ Upstream commit
3446c13b268af86391d06611327006b059b8bab1 ]
The fork of a process with four page table levels is broken since
git commit
6252d702c5311ce9 "[S390] dynamic page tables."
All new mm contexts are created with three page table levels and
an asce limit of 4TB. If the parent has four levels dup_mmap will
add vmas to the new context which are outside of the asce limit.
The subsequent call to copy_page_range will walk the three level
page table structure of the new process with non-zero pgd and pud
indexes. This leads to memory clobbers as the pgd_index *and* the
pud_index is added to the mm->pgd pointer without a pgd_deref
in between.
The init_new_context() function is selecting the number of page
table levels for a new context. The function is used by mm_init()
which in turn is called by dup_mm() and mm_alloc(). These two are
used by fork() and exec(). The init_new_context() function can
distinguish the two cases by looking at mm->context.asce_limit,
for fork() the mm struct has been copied and the number of page
table levels may not change. For exec() the mm_alloc() function
set the new mm structure to zero, in this case a three-level page
table is created as the temporary stack space is located at
STACK_TOP_MAX = 4TB.
This fixes CVE-2016-2143.
Reported-by: Marcin Kościelnicki <koriakin@0x04.net>
Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: stable@vger.kernel.org
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Steven Rostedt (Red Hat) [Wed, 9 Mar 2016 16:58:41 +0000 (11:58 -0500)]
tracing: Fix check for cpu online when event is disabled
[ Upstream commit
dc17147de328a74bbdee67c1bf37d2f1992de756 ]
Commit
f37755490fe9b ("tracepoints: Do not trace when cpu is offline") added
a check to make sure that tracepoints only get called when the cpu is
online, as it uses rcu_read_lock_sched() for protection.
Commit
3a630178fd5f3 ("tracing: generate RCU warnings even when tracepoints
are disabled") added lockdep checks (including rcu checks) for events that
are not enabled to catch possible RCU issues that would only be triggered if
a trace event was enabled. Commit
f37755490fe9b only stopped the warnings
when the trace event was enabled but did not prevent warnings if the trace
event was called when disabled.
To fix this, the cpu online check is moved to where the condition is added
to the trace event. This will place the cpu online check in all places that
it may be used now and in the future.
Cc: stable@vger.kernel.org # v3.18+
Fixes:
f37755490fe9b ("tracepoints: Do not trace when cpu is offline")
Fixes:
3a630178fd5f3 ("tracing: generate RCU warnings even when tracepoints are disabled")
Reported-by: Sudeep Holla <sudeep.holla@arm.com>
Tested-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Alex Deucher [Tue, 8 Mar 2016 16:31:00 +0000 (11:31 -0500)]
Revert "drm/radeon/pm: adjust display configuration after powerstate"
[ Upstream commit
d74e766e1916d0e09b86e4b5b9d0f819628fd546 ]
This reverts commit
39d4275058baf53e89203407bf3841ff2c74fa32.
This caused a regression on some older hardware.
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=113891
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Alex Deucher [Fri, 4 Mar 2016 00:26:24 +0000 (19:26 -0500)]
drm/radeon/dp: add back special handling for NUTMEG
[ Upstream commit
c8213a638f65bf487c10593c216525952cca3690 ]
When I fixed the dp rate selection in:
092c96a8ab9d1bd60ada2ed385cc364ce084180e
drm/radeon: fix dp link rate selection (v2)
I accidently dropped the special handling for NUTMEG
DP bridge chips. They require a fixed link rate.
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Ken Wang <Qingqing.Wang@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Tested-by: Ken Moffat <zarniwhoop@ntlworld.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Alex Deucher [Thu, 17 Dec 2015 15:23:34 +0000 (10:23 -0500)]
drm/radeon: fix dp link rate selection (v2)
[ Upstream commit
092c96a8ab9d1bd60ada2ed385cc364ce084180e ]
Need to properly handle the max link rate in the dpcd.
This prevents some cases where 5.4 Ghz is selected when
it shouldn't be.
v2: simplify logic, add array bounds check
Reviewed-by: Tom St Denis <tom.stdenis@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Alex Deucher [Thu, 14 May 2015 16:47:45 +0000 (12:47 -0400)]
drm/radeon: make dpcd parameters const
[ Upstream commit
0c3a88407ef2be8bb7c302c298d6ff58ebde4a43 ]
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Radim Krčmář [Fri, 4 Mar 2016 14:08:42 +0000 (15:08 +0100)]
KVM: VMX: disable PEBS before a guest entry
[ Upstream commit
7099e2e1f4d9051f31bbfa5803adf954bb5d76ef ]
Linux guests on Haswell (and also SandyBridge and Broadwell, at least)
would crash if you decided to run a host command that uses PEBS, like
perf record -e 'cpu/mem-stores/pp' -a
This happens because KVM is using VMX MSR switching to disable PEBS, but
SDM [2015-12] 18.4.4.4 Re-configuring PEBS Facilities explains why it
isn't safe:
When software needs to reconfigure PEBS facilities, it should allow a
quiescent period between stopping the prior event counting and setting
up a new PEBS event. The quiescent period is to allow any latent
residual PEBS records to complete its capture at their previously
specified buffer address (provided by IA32_DS_AREA).
There might not be a quiescent period after the MSR switch, so a CPU
ends up using host's MSR_IA32_DS_AREA to access an area in guest's
memory. (Or MSR switching is just buggy on some models.)
The guest can learn something about the host this way:
If the guest doesn't map address pointed by MSR_IA32_DS_AREA, it results
in #PF where we leak host's MSR_IA32_DS_AREA through CR2.
After that, a malicious guest can map and configure memory where
MSR_IA32_DS_AREA is pointing and can therefore get an output from
host's tracing.
This is not a critical leak as the host must initiate with PEBS tracing
and I have not been able to get a record from more than one instruction
before vmentry in vmx_vcpu_run() (that place has most registers already
overwritten with guest's).
We could disable PEBS just few instructions before vmentry, but
disabling it earlier shouldn't affect host tracing too much.
We also don't need to switch MSR_IA32_PEBS_ENABLE on VMENTRY, but that
optimization isn't worth its code, IMO.
(If you are implementing PEBS for guests, be sure to handle the case
where both host and guest enable PEBS, because this patch doesn't.)
Fixes:
26a4f3c08de4 ("perf/x86: disable PEBS on a guest entry.")
Cc: <stable@vger.kernel.org>
Reported-by: Jiří Olša <jolsa@redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Al Viro [Tue, 8 Mar 2016 04:07:10 +0000 (23:07 -0500)]
jffs2: reduce the breakage on recovery from halfway failed rename()
[ Upstream commit
f93812846f31381d35c04c6c577d724254355e7f ]
d_instantiate(new_dentry, old_inode) is absolutely wrong thing to
do - it will oops if new_dentry used to be positive, for starters.
What we need is d_invalidate() the target and be done with that.
Cc: stable@vger.kernel.org # v3.18+
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Al Viro [Tue, 8 Mar 2016 03:17:07 +0000 (22:17 -0500)]
ncpfs: fix a braino in OOM handling in ncp_fill_cache()
[ Upstream commit
803c00123a8012b3a283c0530910653973ef6d8f ]
Failing to allocate an inode for child means that cache for *parent* is
incompletely populated. So it's parent directory inode ('dir') that
needs NCPI_DIR_CACHE flag removed, *not* the child inode ('inode', which
is what we'd failed to allocate in the first place).
Fucked-up-in: commit
5e993e25 ("ncpfs: get rid of d_validate() nonsense")
Fucked-up-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: stable@vger.kernel.org # v3.19
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Paul Mackerras [Sat, 5 Mar 2016 08:34:39 +0000 (19:34 +1100)]
KVM: PPC: Book3S HV: Sanitize special-purpose register values on guest exit
[ Upstream commit
ccec44563b18a0ce90e2d4f332784b3cb25c8e9c ]
Thomas Huth discovered that a guest could cause a hard hang of a
host CPU by setting the Instruction Authority Mask Register (IAMR)
to a suitable value. It turns out that this is because when the
code was added to context-switch the new special-purpose registers
(SPRs) that were added in POWER8, we forgot to add code to ensure
that they were restored to a sane value on guest exit.
This adds code to set those registers where a bad value could
compromise the execution of the host kernel to a suitable neutral
value on guest exit.
Cc: stable@vger.kernel.org # v3.14+
Fixes:
b005255e12a3
Reported-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Mugunthan V N [Mon, 7 Mar 2016 08:41:22 +0000 (01:41 -0700)]
ARM: dts: dra7: do not gate cpsw clock due to errata i877
[ Upstream commit
0f514e690740e54815441a87708c3326f8aa8709 ]
Errata id: i877
Description:
------------
The RGMII 1000 Mbps Transmit timing is based on the output clock
(rgmiin_txc) being driven relative to the rising edge of an internal
clock and the output control/data (rgmiin_txctl/txd) being driven relative
to the falling edge of an internal clock source. If the internal clock
source is allowed to be static low (i.e., disabled) for an extended period
of time then when the clock is actually enabled the timing delta between
the rising edge and falling edge can change over the lifetime of the
device. This can result in the device switching characteristics degrading
over time, and eventually failing to meet the Data Manual Delay Time/Skew
specs.
To maintain RGMII 1000 Mbps IO Timings, SW should minimize the
duration that the Ethernet internal clock source is disabled. Note that
the device reset state for the Ethernet clock is "disabled".
Other RGMII modes (10 Mbps, 100Mbps) are not affected
Workaround:
-----------
If the SoC Ethernet interface(s) are used in RGMII mode at 1000 Mbps,
SW should minimize the time the Ethernet internal clock source is disabled
to a maximum of 200 hours in a device life cycle. This is done by enabling
the clock as early as possible in IPL (QNX) or SPL/u-boot (Linux/Android)
by setting the register CM_GMAC_CLKSTCTRL[1:0]CLKTRCTRL = 0x2:SW_WKUP.
So, do not allow to gate the cpsw clocks using ti,no-idle property in
cpsw node assuming 1000 Mbps is being used all the time. If someone does
not need 1000 Mbps and wants to gate clocks to cpsw, this property needs
to be deleted in their respective board files.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Lokesh Vutla [Mon, 7 Mar 2016 08:41:21 +0000 (01:41 -0700)]
ARM: OMAP2+: hwmod: Introduce ti,no-idle dt property
[ Upstream commit
6327a31a3f875c438ca13058bc4c73f1a752cd8a ]
commit
2e18f5a1bc18e8af7031b3b26efde25307014837 upstream.
Introduce a dt property, ti,no-idle, that prevents an IP to idle at any
point. This is to handle Errata i877, which tells that GMAC clocks
cannot be disabled.
Acked-by: Roger Quadros <rogerq@ti.com>
Tested-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Peter Ujfalusi [Thu, 12 Nov 2015 07:32:58 +0000 (09:32 +0200)]
ARM: OMAP2+: hwmod: Add hwmod flag for HWMOD_OPT_CLKS_NEEDED
[ Upstream commit
c12ba8ce2335389ce5416f88391cd67c7325c963 ]
Some module needs more than one functional clock in order to be accessible,
like the McASPs found in DRA7xx family.
This flag will indicate that the opt_clks need to be handled at the same
time as the main_clk for the given hwmod, ensuring that all needed clocks
are enabled before we try to access the module's address space.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Nicholas Bellinger [Sun, 6 Mar 2016 04:00:12 +0000 (20:00 -0800)]
target: Drop incorrect ABORT_TASK put for completed commands
[ Upstream commit
7f54ab5ff52fb0b91569bc69c4a6bc5cac1b768d ]
This patch fixes a recent ABORT_TASK regression associated
with commit
febe562c, where a left-over target_put_sess_cmd()
would still be called when __target_check_io_state() detected
a command has already been completed, and explicit ABORT must
be avoided.
Note commit
febe562c dropped the local kref_get_unless_zero()
check in core_tmr_abort_task(), but did not drop this extra
corresponding target_put_sess_cmd() in the failure path.
So go ahead and drop this now bogus target_put_sess_cmd(),
and avoid this potential use-after-free.
Reported-by: Dan Lane <dracodan@gmail.com>
Cc: Quinn Tran <quinn.tran@qlogic.com>
Cc: Himanshu Madhani <himanshu.madhani@qlogic.com>
Cc: Sagi Grimberg <sagig@mellanox.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Andy Grover <agrover@redhat.com>
Cc: Mike Christie <mchristi@redhat.com>
Cc: stable@vger.kernel.org # 3.14+
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Konstantin Khlebnikov [Sun, 31 Jan 2016 13:21:29 +0000 (16:21 +0300)]
ovl: copy new uid/gid into overlayfs runtime inode
[ Upstream commit
b81de061fa59f17d2730aabb1b84419ef3913810 ]
Overlayfs must update uid/gid after chown, otherwise functions
like inode_owner_or_capable() will check user against stale uid.
Catched by xfstests generic/087, it chowns file and calls utimes.
Signed-off-by: Konstantin Khlebnikov <koct9i@gmail.com>
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Cc: <stable@vger.kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Konstantin Khlebnikov [Sun, 31 Jan 2016 13:17:53 +0000 (16:17 +0300)]
ovl: ignore lower entries when checking purity of non-directory entries
[ Upstream commit
45d11738969633ec07ca35d75d486bf2d8918df6 ]
After rename file dentry still holds reference to lower dentry from
previous location. This doesn't matter for data access because data comes
from upper dentry. But this stale lower dentry taints dentry at new
location and turns it into non-pure upper. Such file leaves visible
whiteout entry after remove in directory which shouldn't have whiteouts at
all.
Overlayfs already tracks pureness of file location in oe->opaque. This
patch just uses that for detecting actual path type.
Comment from Vivek Goyal's patch:
Here are the details of the problem. Do following.
$ mkdir upper lower work merged upper/dir/
$ touch lower/test
$ sudo mount -t overlay overlay -olowerdir=lower,upperdir=upper,workdir=
work merged
$ mv merged/test merged/dir/
$ rm merged/dir/test
$ ls -l merged/dir/
/usr/bin/ls: cannot access merged/dir/test: No such file or directory
total 0
c????????? ? ? ? ? ? test
Basic problem seems to be that once a file has been unlinked, a whiteout
has been left behind which was not needed and hence it becomes visible.
Whiteout is visible because parent dir is of not type MERGE, hence
od->is_real is set during ovl_dir_open(). And that means ovl_iterate()
passes on iterate handling directly to underlying fs. Underlying fs does
not know/filter whiteouts so it becomes visible to user.
Why did we leave a whiteout to begin with when we should not have.
ovl_do_remove() checks for OVL_TYPE_PURE_UPPER() and does not leave
whiteout if file is pure upper. In this case file is not found to be pure
upper hence whiteout is left.
So why file was not PURE_UPPER in this case? I think because dentry is
still carrying some leftover state which was valid before rename. For
example, od->numlower was set to 1 as it was a lower file. After rename,
this state is not valid anymore as there is no such file in lower.
Signed-off-by: Konstantin Khlebnikov <koct9i@gmail.com>
Reported-by: Viktor Stanchev <me@viktorstanchev.com>
Suggested-by: Vivek Goyal <vgoyal@redhat.com>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=109611
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Cc: <stable@vger.kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Rui Wang [Fri, 8 Jan 2016 15:09:59 +0000 (23:09 +0800)]
ovl: fix getcwd() failure after unsuccessful rmdir
[ Upstream commit
ce9113bbcbf45a57c082d6603b9a9f342be3ef74 ]
ovl_remove_upper() should do d_drop() only after it successfully
removes the dir, otherwise a subsequent getcwd() system call will
fail, breaking userspace programs.
This is to fix: https://bugzilla.kernel.org/show_bug.cgi?id=110491
Signed-off-by: Rui Wang <rui.y.wang@intel.com>
Reviewed-by: Konstantin Khlebnikov <koct9i@gmail.com>
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Cc: <stable@vger.kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Jouni Malinen [Mon, 29 Feb 2016 22:29:00 +0000 (00:29 +0200)]
mac80211: Fix Public Action frame RX in AP mode
[ Upstream commit
1ec7bae8bec9b72e347e01330c745ab5cdd66f0e ]
Public Action frames use special rules for how the BSSID field (Address
3) is set. A wildcard BSSID is used in cases where the transmitter and
recipient are not members of the same BSS. As such, we need to accept
Public Action frames with wildcard BSSID.
Commit
db8e17324553 ("mac80211: ignore frames between TDLS peers when
operating as AP") added a rule that drops Action frames to TDLS-peers
based on an Action frame having different DA (Address 1) and BSSID
(Address 3) values. This is not correct since it misses the possibility
of BSSID being a wildcard BSSID in which case the Address 1 would not
necessarily match.
Fix this by allowing mac80211 to accept wildcard BSSID in an Action
frame when in AP mode.
Fixes:
db8e17324553 ("mac80211: ignore frames between TDLS peers when operating as AP")
Cc: stable@vger.kernel.org
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Johannes Berg [Fri, 26 Feb 2016 21:13:40 +0000 (22:13 +0100)]
mac80211: check PN correctly for GCMP-encrypted fragmented MPDUs
[ Upstream commit
9acc54beb474c81148e2946603d141cf8716b19f ]
Just like for CCMP we need to check that for GCMP the fragments
have PNs that increment by one; the spec was updated to fix this
security issue and now has the following text:
The receiver shall discard MSDUs and MMPDUs whose constituent
MPDU PN values are not incrementing in steps of 1.
Adapt the code for CCMP to work for GCMP as well, luckily the
relevant fields already alias each other so no code duplication
is needed (just check the aliasing with BUILD_BUG_ON.)
Cc: stable@vger.kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Takashi Iwai [Mon, 29 Feb 2016 17:01:18 +0000 (18:01 +0100)]
ASoC: wm_adsp: Fix enum ctl accesses in a wrong type
[ Upstream commit
15c665700bf6f4543f003ac0fbb1e9ec692e93f2 ]
The firmware ctls like "DSP1 Firmware" in wm_adsp codec driver are
enum, while the current driver accesses wrongly via
value.integer.value[]. They have to be via value.enumerated.item[]
instead.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Takashi Iwai [Mon, 29 Feb 2016 17:01:15 +0000 (18:01 +0100)]
ASoC: wm8994: Fix enum ctl accesses in a wrong type
[ Upstream commit
8019c0b37cd5a87107808300a496388b777225bf ]
The DRC Mode like "AIF1DRC1 Mode" and EQ Mode like "AIF1.1 EQ Mode" in
wm8994 codec driver are enum ctls, while the current driver accesses
wrongly via value.integer.value[]. They have to be via
value.enumerated.item[] instead.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Takashi Iwai [Mon, 29 Feb 2016 17:01:12 +0000 (18:01 +0100)]
ASoC: wm8958: Fix enum ctl accesses in a wrong type
[ Upstream commit
d0784829ae3b0beeb69b476f017d5c8a2eb95198 ]
"MBC Mode", "VSS Mode", "VSS HPF Mode" and "Enhanced EQ Mode" ctls in
wm8958 codec driver are enum, while the current driver accesses
wrongly via value.integer.value[]. They have to be via
value.enumerated.item[] instead.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Takashi Iwai [Mon, 29 Feb 2016 16:20:48 +0000 (17:20 +0100)]
ASoC: dapm: Fix ctl value accesses in a wrong type
[ Upstream commit
741338f99f16dc24d2d01ac777b0798ae9d10a90 ]
snd_soc_dapm_dai_link_get() and _put() access the associated ctl
values as value.integer.value[]. However, this is an enum ctl, and it
has to be accessed via value.enumerated.item[]. The former is long
while the latter is unsigned int, so they don't align.
Fixes:
c66150824b8a ('ASoC: dapm: add code to configure dai link parameters')
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Maximilain Schneider [Tue, 23 Feb 2016 01:17:28 +0000 (01:17 +0000)]
can: gs_usb: fixed disconnect bug by removing erroneous use of kfree()
[ Upstream commit
e9a2d81b1761093386a0bb8a4f51642ac785ef63 ]
gs_destroy_candev() erroneously calls kfree() on a struct gs_can *, which is
allocated through alloc_candev() and should instead be freed using
free_candev() alone.
The inappropriate use of kfree() causes the kernel to hang when
gs_destroy_candev() is called.
Only the struct gs_usb * which is allocated through kzalloc() should be freed
using kfree() when the device is disconnected.
Signed-off-by: Maximilian Schneider <max@schneidersoft.net>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Felix Fietkau [Thu, 18 Feb 2016 18:49:18 +0000 (19:49 +0100)]
mac80211: minstrel_ht: set default tx aggregation timeout to 0
[ Upstream commit
7a36b930e6ed4702c866dc74a5ad07318a57c688 ]
The value 5000 was put here with the addition of the timeout field to
ieee80211_start_tx_ba_session. It was originally added in mac80211 to
save resources for drivers like iwlwifi, which only supports a limited
number of concurrent aggregation sessions.
Since iwlwifi does not use minstrel_ht and other drivers don't need
this, 0 is a better default - especially since there have been
recent reports of aggregation setup related issues reproduced with
ath9k. This should improve stability without causing any adverse
effects.
Cc: stable@vger.kernel.org
Acked-by: Avery Pennarun <apenwarr@gmail.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Charles Keepax [Thu, 18 Feb 2016 15:47:13 +0000 (15:47 +0000)]
ASoC: samsung: Use IRQ safe spin lock calls
[ Upstream commit
316fa9e09ad76e095b9d7e9350c628b918370a22 ]
Lockdep warns of a potential lock inversion, i2s->lock is held numerous
times whilst we are under the substream lock (snd_pcm_stream_lock). If
we use the IRQ unsafe spin lock calls, you can also end up locking
snd_pcm_stream_lock whilst under i2s->lock (if an IRQ happens whilst we
are holding i2s->lock). This could result in deadlock.
[ 18.147001] CPU0 CPU1
[ 18.151509] ---- ----
[ 18.156022] lock(&(&pri_dai->spinlock)->rlock);
[ 18.160701] local_irq_disable();
[ 18.166622] lock(&(&substream->self_group.lock)->rlock);
[ 18.174595] lock(&(&pri_dai->spinlock)->rlock);
[ 18.181806] <Interrupt>
[ 18.184408] lock(&(&substream->self_group.lock)->rlock);
[ 18.190045]
[ 18.190045] *** DEADLOCK ***
This patch changes to using the irq safe spinlock calls, to avoid this
issue.
Fixes:
ce8bcdbb61d9 ("ASoC: samsung: i2s: Protect more registers with a spinlock")
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Liad Kaufman [Sun, 14 Feb 2016 13:32:58 +0000 (15:32 +0200)]
iwlwifi: mvm: inc pending frames counter also when txing non-sta
[ Upstream commit
fb896c44f88a75843a072cd6961b1615732f7811 ]
Until this patch, when TXing non-sta the pending_frames counter
wasn't increased, but it WAS decreased in
iwl_mvm_rx_tx_cmd_single(), what makes it negative in certain
conditions. This in turn caused much trouble when we need to
remove the station since we won't be waiting forever until
pending_frames gets 0. In certain cases, we were exhausting
the station table even in BSS mode, because we had a lot of
stale stations.
Increase the counter also in iwl_mvm_tx_skb_non_sta() after a
successful TX to avoid this outcome.
CC: <stable@vger.kernel.org> [3.18+]
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Sven Eckelmann [Tue, 2 Feb 2016 07:12:26 +0000 (08:12 +0100)]
mac80211: minstrel: Change expected throughput unit back to Kbps
[ Upstream commit
212c5a5e6ba61678be6b5fee576e38bccb50b613 ]
The change from cur_tp to the function
minstrel_get_tp_avg/minstrel_ht_get_tp_avg changed the unit used for the
current throughput. For example in minstrel_ht the correct
conversion between them would be:
mrs->cur_tp / 10 == minstrel_ht_get_tp_avg(..).
This factor 10 must also be included in the calculation of
minstrel_get_expected_throughput and minstrel_ht_get_expected_throughput to
return values with the unit [Kbps] instead of [10Kbps]. Otherwise routing
algorithms like B.A.T.M.A.N. V will make incorrect decision based on these
values. Its kernel based implementation expects expected_throughput always
to have the unit [Kbps] and not sometimes [10Kbps] and sometimes [Kbps].
The same requirement has iw or olsrdv2's nl80211 based statistics module
which retrieve the same data via NL80211_STA_INFO_TX_BITRATE.
Cc: stable@vger.kernel.org
Fixes:
6a27b2c40b48 ("mac80211: restructure per-rate throughput calculation into function")
Signed-off-by: Sven Eckelmann <sven@open-mesh.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Chris Bainbridge [Wed, 27 Jan 2016 15:46:18 +0000 (15:46 +0000)]
mac80211: fix use of uninitialised values in RX aggregation
[ Upstream commit
f39ea2690bd61efec97622c48323f40ed6e16317 ]
Use kzalloc instead of kmalloc for struct tid_ampdu_rx to
initialize the "removed" field (all others are initialized
manually). That fixes:
UBSAN: Undefined behaviour in net/mac80211/rx.c:932:29
load of value 2 is not a valid value for type '_Bool'
CPU: 3 PID: 1134 Comm: kworker/u16:7 Not tainted 4.5.0-rc1+ #265
Workqueue: phy0 rt2x00usb_work_rxdone
0000000000000004 ffff880254a7ba50 ffffffff8181d866 0000000000000007
ffff880254a7ba78 ffff880254a7ba68 ffffffff8188422d ffffffff8379b500
ffff880254a7bab8 ffffffff81884747 0000000000000202 0000000348620032
Call Trace:
[<
ffffffff8181d866>] dump_stack+0x45/0x5f
[<
ffffffff8188422d>] ubsan_epilogue+0xd/0x40
[<
ffffffff81884747>] __ubsan_handle_load_invalid_value+0x67/0x70
[<
ffffffff82227b4d>] ieee80211_sta_reorder_release.isra.16+0x5ed/0x730
[<
ffffffff8222ca14>] ieee80211_prepare_and_rx_handle+0xd04/0x1c00
[<
ffffffff8222db03>] __ieee80211_rx_handle_packet+0x1f3/0x750
[<
ffffffff8222e4a7>] ieee80211_rx_napi+0x447/0x990
While at it, convert to use sizeof(*tid_agg_rx) instead.
Fixes:
788211d81bfdf ("mac80211: fix RX A-MPDU session reorder timer deletion")
Cc: stable@vger.kernel.org
Signed-off-by: Chris Bainbridge <chris.bainbridge@gmail.com>
[reword commit message, use sizeof(*tid_agg_rx)]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Johannes Berg [Wed, 27 Jan 2016 12:29:34 +0000 (13:29 +0100)]
cfg80211/wext: fix message ordering
[ Upstream commit
cb150b9d23be6ee7f3a0fff29784f1c5b5ac514d ]
Since cfg80211 frequently takes actions from its netdev notifier
call, wireless extensions messages could still be ordered badly
since the wext netdev notifier, since wext is built into the
kernel, runs before the cfg80211 netdev notifier. For example,
the following can happen:
5: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN group default
link/ether 02:00:00:00:01:00 brd ff:ff:ff:ff:ff:ff
5: wlan1: <BROADCAST,MULTICAST,UP>
link/ether
when setting the interface down causes the wext message.
To also fix this, export the wireless_nlevent_flush() function
and also call it from the cfg80211 notifier.
Cc: stable@vger.kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Johannes Berg [Wed, 27 Jan 2016 11:37:52 +0000 (12:37 +0100)]
wext: fix message delay/ordering
[ Upstream commit
8bf862739a7786ae72409220914df960a0aa80d8 ]
Beniamino reported that he was getting an RTM_NEWLINK message for a
given interface, after the RTM_DELLINK for it. It turns out that the
message is a wireless extensions message, which was sent because the
interface had been connected and disconnection while it was deleted
caused a wext message.
For its netlink messages, wext uses RTM_NEWLINK, but the message is
without all the regular rtnetlink attributes, so "ip monitor link"
prints just rudimentary information:
5: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN group default
link/ether 02:00:00:00:01:00 brd ff:ff:ff:ff:ff:ff
Deleted 5: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default
link/ether 02:00:00:00:01:00 brd ff:ff:ff:ff:ff:ff
5: wlan1: <BROADCAST,MULTICAST,UP>
link/ether
(from my hwsim reproduction)
This can cause userspace to get confused since it doesn't expect an
RTM_NEWLINK message after RTM_DELLINK.
The reason for this is that wext schedules a worker to send out the
messages, and the scheduling delay can cause the messages to get out
to userspace in different order.
To fix this, have wext register a netdevice notifier and flush out
any pending messages when netdevice state changes. This fixes any
ordering whenever the original message wasn't sent by a notifier
itself.
Cc: stable@vger.kernel.org
Reported-by: Beniamino Galvani <bgalvani@redhat.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Sasha Levin [Thu, 17 Mar 2016 18:11:03 +0000 (14:11 -0400)]
Linux 4.1.20
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Hannes Frederic Sowa [Thu, 8 Oct 2015 16:19:53 +0000 (18:19 +0200)]
ipv6: drop frames with attached skb->sk in forwarding
[ Upstream commit
9ef2e965e55481a52d6d91ce61977a27836268d3 ]
This is a clone of commit
2ab957492d13b ("ip_forward: Drop frames with
attached skb->sk") for ipv6.
This commit has exactly the same reasons as the above mentioned commit,
namely to prevent panics during netfilter reload or a misconfigured stack.
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Marcelo Tosatti [Fri, 11 Mar 2016 08:53:11 +0000 (16:53 +0800)]
KVM: x86: move steal time initialization to vcpu entry time
[ Upstream commit
7cae2bedcbd4680b155999655e49c27b9cf020fa ]
As reported at https://bugs.launchpad.net/qemu/+bug/1494350,
it is possible to have vcpu->arch.st.last_steal initialized
from a thread other than vcpu thread, say the iothread, via
KVM_SET_MSRS.
Which can cause an overflow later (when subtracting from vcpu threads
sched_info.run_delay).
To avoid that, move steal time accumulation to vcpu entry time,
before copying steal time data to guest.
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Reviewed-by: David Matlack <dmatlack@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Richard Weinberger [Sun, 21 Feb 2016 09:53:03 +0000 (10:53 +0100)]
ubi: Fix out of bounds write in volume update code
[ Upstream commit
e4f6daac20332448529b11f09388f1d55ef2084c ]
ubi_start_leb_change() allocates too few bytes.
ubi_more_leb_change_data() will write up to req->upd_bytes +
ubi->min_io_size bytes.
Cc: stable@vger.kernel.org
Signed-off-by: Richard Weinberger <richard@nod.at>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Maciej W. Rozycki [Fri, 4 Mar 2016 01:42:49 +0000 (01:42 +0000)]
MIPS: traps: Fix SIGFPE information leak from `do_ov' and `do_trap_or_bp'
[ Upstream commit
e723e3f7f9591b79e8c56b3d7c5a204a9c571b55 ]
Avoid sending a partially initialised `siginfo_t' structure along SIGFPE
signals issued from `do_ov' and `do_trap_or_bp', leading to information
leaking from the kernel stack.
Signed-off-by: Maciej W. Rozycki <macro@imgtec.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Simon South [Thu, 3 Mar 2016 04:10:44 +0000 (23:10 -0500)]
ALSA: hda - Fix mic issues on Acer Aspire E1-472
[ Upstream commit
02322ac9dee9aff8d8862e8d6660ebe102f492ea ]
This patch applies the microphone-related fix created for the Acer
Aspire E1-572 to the E1-472 as well, as it uses the same Realtek ALC282
CODEC and demonstrates the same issues.
This patch allows an external, headset microphone to be used and limits
the gain on the (quite noisy) internal microphone.
Signed-off-by: Simon South <simon@simonsouth.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Todd E Brandt [Thu, 3 Mar 2016 00:05:29 +0000 (16:05 -0800)]
PM / sleep / x86: Fix crash on graph trace through x86 suspend
[ Upstream commit
92f9e179a702a6adbc11e2fedc76ecd6ffc9e3f7 ]
Pause/unpause graph tracing around do_suspend_lowlevel as it has
inconsistent call/return info after it jumps to the wakeup vector.
The graph trace buffer will otherwise become misaligned and
may eventually crash and hang on suspend.
To reproduce the issue and test the fix:
Run a function_graph trace over suspend/resume and set the graph
function to suspend_devices_and_enter. This consistently hangs the
system without this fix.
Signed-off-by: Todd Brandt <todd.e.brandt@linux.intel.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Alex Deucher [Wed, 24 Feb 2016 22:38:38 +0000 (17:38 -0500)]
drm/radeon/pm: update current crtc info after setting the powerstate
[ Upstream commit
5e031d9fe8b0741f11d49667dfc3ebf5454121fd ]
On CI, we need to see if the number of crtcs changes to determine
whether or not we need to upload the mclk table again. In practice
we don't currently upload the mclk table again after the initial load.
The only reason you would would be to add new states, e.g., for
arbitrary mclk setting which is not currently supported.
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Bjørn Mork [Tue, 1 Mar 2016 13:36:32 +0000 (14:36 +0100)]
USB: qcserial: add Sierra Wireless EM74xx device ID
[ Upstream commit
04fdbc825ffc02fb098964b92de802fff44e73fd ]
The MC74xx and EM74xx modules use different IDs by default, according
to the Lenovo EM7455 driver for Windows.
Cc: <stable@vger.kernel.org>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Timothy Pearson [Fri, 26 Feb 2016 21:29:32 +0000 (15:29 -0600)]
drm/ast: Fix incorrect register check for DRAM width
[ Upstream commit
2d02b8bdba322b527c5f5168ce1ca10c2d982a78 ]
During DRAM initialization on certain ASpeed devices, an incorrect
bit (bit 10) was checked in the "SDRAM Bus Width Status" register
to determine DRAM width.
Query bit 6 instead in accordance with the Aspeed AST2050 datasheet v1.05.
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Helge Deller [Tue, 19 Jan 2016 15:08:49 +0000 (16:08 +0100)]
parisc: Fix ptrace syscall number and return value modification
[ Upstream commit
98e8b6c9ac9d1b1e9d1122dfa6783d5d566bb8f7 ]
Mike Frysinger reported that his ptrace testcase showed strange
behaviour on parisc: It was not possible to avoid a syscall and the
return value of a syscall couldn't be changed.
To modify a syscall number, we were missing to save the new syscall
number to gr20 which is then picked up later in assembly again.
The effect that the return value couldn't be changed is a side-effect of
another bug in the assembly code. When a process is ptraced, userspace
expects each syscall to report entrance and exit of a syscall. If a
syscall number was given which doesn't exist, we jumped to the normal
syscall exit code instead of informing userspace that the (non-existant)
syscall exits. This unexpected behaviour confuses userspace and thus the
bug was misinterpreted as if we can't change the return value.
This patch fixes both problems and was tested on 64bit kernel with
32bit userspace.
Signed-off-by: Helge Deller <deller@gmx.de>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: stable@vger.kernel.org # v4.0+
Tested-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Takashi Iwai [Tue, 1 Mar 2016 17:30:18 +0000 (18:30 +0100)]
ALSA: seq: oss: Don't drain at closing a client
[ Upstream commit
197b958c1e76a575d77038cc98b4bebc2134279f ]
The OSS sequencer client tries to drain the pending events at
releasing. Unfortunately, as spotted by syzkaller fuzzer, this may
lead to an unkillable process state when the event has been queued at
the far future. Since the process being released can't be signaled
any longer, it remains and waits for the echo-back event in that far
future.
Back to history, the draining feature was implemented at the time we
misinterpreted POSIX definition for blocking file operation.
Actually, such a behavior is superfluous at release, and we should
just release the device as is instead of keeping it up forever.
This patch just removes the draining call that may block the release
for too long time unexpectedly.
BugLink: http://lkml.kernel.org/r/CACT4Y+Y4kD-aBGj37rf-xBw9bH3GMU6P+MYg4W1e-s-paVD2pg@mail.gmail.com
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Dennis Kadioglu [Tue, 1 Mar 2016 13:23:29 +0000 (14:23 +0100)]
ALSA: usb-audio: Add a quirk for Plantronics DA45
[ Upstream commit
17e2df4613be57d0fab68df749f6b8114e453152 ]
Plantronics DA45 does not support reading the sample rate which leads
to many lines of "cannot get freq at ep 0x4" and "cannot get freq at
ep 0x84". This patch adds the USB ID of the DA45 to quirks.c and
avoids those error messages.
Signed-off-by: Dennis Kadioglu <denk@post.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Yegor Yefremov [Mon, 29 Feb 2016 15:39:57 +0000 (16:39 +0100)]
USB: serial: option: add support for Quectel UC20
[ Upstream commit
c0992d0f54847d0d1d85c60fcaa054f175ab1ccd ]
Add support for Quectel UC20 and blacklist the QMI interface.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Cc: stable <stable@vger.kernel.org>
[johan: amend commit message ]
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Daniele Palmas [Mon, 29 Feb 2016 14:36:11 +0000 (15:36 +0100)]
USB: serial: option: add support for Telit LE922 PID 0x1045
[ Upstream commit
5deef5551c77e488922cc4bf4bc76df63be650d0 ]
This patch adds support for 0x1045 PID of Telit LE922.
Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Vittorio Alfieri [Sun, 28 Feb 2016 13:40:24 +0000 (14:40 +0100)]
USB: cp210x: Add ID for Parrot NMEA GPS Flight Recorder
[ Upstream commit
3c4c615d70c8cbdc8ba8c79ed702640930652a79 ]
The Parrot NMEA GPS Flight Recorder is a USB composite device
consisting of hub, flash storage, and cp210x usb to serial chip.
It is an accessory to the mass-produced Parrot AR Drone 2.
The device emits standard NMEA messages which make the it compatible
with NMEA compatible software. It was tested using gpsd version 3.11-3
as an NMEA interpreter and using the official Parrot Flight Recorder.
Signed-off-by: Vittorio Alfieri <vittorio88@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Patrik Halfar [Sat, 20 Feb 2016 17:49:56 +0000 (18:49 +0100)]
USB: qcserial: add Dell Wireless 5809e Gobi 4G HSPA+ (rev3)
[ Upstream commit
013dd239d6220a4e0dfdf0d45a82c34f1fd73deb ]
New revision of Dell Wireless 5809e Gobi 4G HSPA+ Mobile Broadband Card
has new idProduct.
Bus 002 Device 006: ID 413c:81b3 Dell Computer Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x413c Dell Computer Corp.
idProduct 0x81b3
bcdDevice 0.06
iManufacturer 1 Sierra Wireless, Incorporated
iProduct 2 Dell Wireless 5809e Gobi™ 4G HSPA+ Mobile Broadband Card
iSerial 3
bNumConfigurations 2
Signed-off-by: Patrik Halfar <patrik_halfar@halfarit.cz>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Al Viro [Mon, 29 Feb 2016 17:12:46 +0000 (12:12 -0500)]
use ->d_seq to get coherency between ->d_inode and ->d_flags
[ Upstream commit
a528aca7f359f4b0b1d72ae406097e491a5ba9ea ]
Games with ordering and barriers are way too brittle. Just
bump ->d_seq before and after updating ->d_inode and ->d_flags
type bits, so that verifying ->d_seq would guarantee they are
coherent.
Cc: stable@vger.kernel.org # v3.13+
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Peter Zijlstra [Thu, 11 Jun 2015 12:46:46 +0000 (14:46 +0200)]
seqcount: Rename write_seqcount_barrier()
[ Upstream commit
a7c6f571ff51cc77d90dd54968f7c5c938c43998 ]
I'll shortly be introducing another seqcount primitive that's useful
to provide ordering semantics and would like to use the
write_seqcount_barrier() name for that.
Seeing how there's only one user of the current primitive, lets rename
it to invalidate, as that appears what its doing.
While there, employ lockdep_assert_held() instead of
assert_spin_locked() to not generate debug code for regular kernels.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: ktkhai@parallels.com
Cc: rostedt@goodmis.org
Cc: juri.lelli@gmail.com
Cc: pang.xunlei@linaro.org
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: wanpeng.li@linux.intel.com
Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: umgwanakikbuti@gmail.com
Link: http://lkml.kernel.org/r/20150611124743.279926217@infradead.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Takashi Iwai [Mon, 29 Feb 2016 13:26:43 +0000 (14:26 +0100)]
ALSA: hdsp: Fix wrong boolean ctl value accesses
[ Upstream commit
eab3c4db193f5fcccf70e884de9a922ca2c63d80 ]
snd-hdsp driver accesses enum item values (int) instead of boolean
values (long) wrongly for some ctl elements. This patch fixes them.
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Takashi Iwai [Mon, 29 Feb 2016 13:32:42 +0000 (14:32 +0100)]
ALSA: hdspm: Fix zero-division
[ Upstream commit
c1099c3294c2344110085a38c50e478a5992b368 ]
HDSPM driver contains a code issuing zero-division potentially in
system sample rate ctl code. This patch fixes it by not processing
a zero or invalid rate value as a divisor, as well as excluding the
invalid value to be passed via the given ctl element.
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Takashi Iwai [Mon, 29 Feb 2016 13:25:16 +0000 (14:25 +0100)]
ALSA: hdspm: Fix wrong boolean ctl value accesses
[ Upstream commit
537e48136295c5860a92138c5ea3959b9542868b ]
snd-hdspm driver accesses enum item values (int) instead of boolean
values (long) wrongly for some ctl elements. This patch fixes them.
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Michael S. Tsirkin [Sun, 28 Feb 2016 15:35:59 +0000 (17:35 +0200)]
MIPS: kvm: Fix ioctl error handling.
[ Upstream commit
887349f69f37e71e2a8bfbd743831625a0b2ff51 ]
Calling return copy_to_user(...) or return copy_from_user in an ioctl
will not do the right thing if there's a pagefault:
copy_to_user/copy_from_user return the number of bytes not copied in
this case.
Fix up kvm on mips to do
return copy_to_user(...)) ? -EFAULT : 0;
and
return copy_from_user(...)) ? -EFAULT : 0;
everywhere.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Cc: stable@vger.kernel.org
Cc: kvm@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/12709/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Michael S. Tsirkin [Sun, 28 Feb 2016 15:32:07 +0000 (17:32 +0200)]
arm/arm64: KVM: Fix ioctl error handling
[ Upstream commit
4cad67fca3fc952d6f2ed9e799621f07666a560f ]
Calling return copy_to_user(...) in an ioctl will not
do the right thing if there's a pagefault:
copy_to_user returns the number of bytes not copied
in this case.
Fix up kvm to do
return copy_to_user(...)) ? -EFAULT : 0;
everywhere.
Cc: stable@vger.kernel.org
Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Yadan Fan [Mon, 29 Feb 2016 06:44:57 +0000 (14:44 +0800)]
Fix cifs_uniqueid_to_ino_t() function for s390x
[ Upstream commit
1ee9f4bd1a97026a7b2d7ae9f1f74b45680d0003 ]
This issue is caused by commit
02323db17e3a7 ("cifs: fix
cifs_uniqueid_to_ino_t not to ever return 0"), when BITS_PER_LONG
is 64 on s390x, the corresponding cifs_uniqueid_to_ino_t()
function will cast 64-bit fileid to 32-bit by using (ino_t)fileid,
because ino_t (typdefed __kernel_ino_t) is int type.
It's defined in arch/s390/include/uapi/asm/posix_types.h
#ifndef __s390x__
typedef unsigned long __kernel_ino_t;
...
#else /* __s390x__ */
typedef unsigned int __kernel_ino_t;
So the #ifdef condition is wrong for s390x, we can just still use
one cifs_uniqueid_to_ino_t() function with comparing sizeof(ino_t)
and sizeof(u64) to choose the correct execution accordingly.
Signed-off-by: Yadan Fan <ydfan@suse.com>
CC: stable <stable@vger.kernel.org>
Signed-off-by: Steve French <smfrench@gmail.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Pavel Shilovsky [Sat, 27 Feb 2016 08:58:18 +0000 (11:58 +0300)]
CIFS: Fix SMB2+ interim response processing for read requests
[ Upstream commit
6cc3b24235929b54acd5ecc987ef11a425bd209e ]
For interim responses we only need to parse a header and update
a number credits. Now it is done for all SMB2+ command except
SMB2_READ which is wrong. Fix this by adding such processing.
Signed-off-by: Pavel Shilovsky <pshilovsky@samba.org>
Tested-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
CC: Stable <stable@vger.kernel.org>
Signed-off-by: Steve French <smfrench@gmail.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Justin Maggard [Tue, 9 Feb 2016 23:52:08 +0000 (15:52 -0800)]
cifs: fix out-of-bounds access in lease parsing
[ Upstream commit
deb7deff2f00bdbbcb3d560dad2a89ef37df837d ]
When opening a file, SMB2_open() attempts to parse the lease state from the
SMB2 CREATE Response. However, the parsing code was not careful to ensure
that the create contexts are not empty or invalid, which can lead to out-
of-bounds memory access. This can be seen easily by trying
to read a file from a OSX 10.11 SMB3 server. Here is sample crash output:
BUG: unable to handle kernel paging request at
ffff8800a1a77cc6
IP: [<
ffffffff8828a734>] SMB2_open+0x804/0x960
PGD 8f77067 PUD 0
Oops: 0000 [#1] SMP
Modules linked in:
CPU: 3 PID: 2876 Comm: cp Not tainted 4.5.0-rc3.x86_64.1+ #14
Hardware name: NETGEAR ReadyNAS 314 /ReadyNAS 314 , BIOS 4.6.5 10/11/2012
task:
ffff880073cdc080 ti:
ffff88005b31c000 task.ti:
ffff88005b31c000
RIP: 0010:[<
ffffffff8828a734>] [<
ffffffff8828a734>] SMB2_open+0x804/0x960
RSP: 0018:
ffff88005b31fa08 EFLAGS:
00010282
RAX:
0000000000000015 RBX:
0000000000000000 RCX:
0000000000000006
RDX:
0000000000000000 RSI:
0000000000000246 RDI:
ffff88007eb8c8b0
RBP:
ffff88005b31fad8 R08:
666666203d206363 R09:
6131613030383866
R10:
3030383866666666 R11:
00000000000002b0 R12:
ffff8800660fd800
R13:
ffff8800a1a77cc2 R14:
00000000424d53fe R15:
ffff88005f5a28c0
FS:
00007f7c8a2897c0(0000) GS:
ffff88007eb80000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b
CR2:
ffff8800a1a77cc6 CR3:
000000005b281000 CR4:
00000000000006e0
Stack:
ffff88005b31fa70 ffffffff88278789 00000000000001d3 ffff88005f5a2a80
ffffffff00000003 ffff88005d029d00 ffff88006fde05a0 0000000000000000
ffff88005b31fc78 ffff88006fde0780 ffff88005b31fb2f 0000000100000fe0
Call Trace:
[<
ffffffff88278789>] ? cifsConvertToUTF16+0x159/0x2d0
[<
ffffffff8828cf68>] smb2_open_file+0x98/0x210
[<
ffffffff8811e80c>] ? __kmalloc+0x1c/0xe0
[<
ffffffff882685f4>] cifs_open+0x2a4/0x720
[<
ffffffff88122cef>] do_dentry_open+0x1ff/0x310
[<
ffffffff88268350>] ? cifsFileInfo_get+0x30/0x30
[<
ffffffff88123d92>] vfs_open+0x52/0x60
[<
ffffffff88131dd0>] path_openat+0x170/0xf70
[<
ffffffff88097d48>] ? remove_wait_queue+0x48/0x50
[<
ffffffff88133a29>] do_filp_open+0x79/0xd0
[<
ffffffff8813f2ca>] ? __alloc_fd+0x3a/0x170
[<
ffffffff881240c4>] do_sys_open+0x114/0x1e0
[<
ffffffff881241a9>] SyS_open+0x19/0x20
[<
ffffffff8896e257>] entry_SYSCALL_64_fastpath+0x12/0x6a
Code: 4d 8d 6c 07 04 31 c0 4c 89 ee e8 47 6f e5 ff 31 c9 41 89 ce 44 89 f1 48 c7 c7 28 b1 bd 88 31 c0 49 01 cd 4c 89 ee e8 2b 6f e5 ff <45> 0f b7 75 04 48 c7 c7 31 b1 bd 88 31 c0 4d 01 ee 4c 89 f6 e8
RIP [<
ffffffff8828a734>] SMB2_open+0x804/0x960
RSP <
ffff88005b31fa08>
CR2:
ffff8800a1a77cc6
---[ end trace
d9f69ba64feee469 ]---
Signed-off-by: Justin Maggard <jmaggard@netgear.com>
Signed-off-by: Steve French <smfrench@gmail.com>
CC: Stable <stable@vger.kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Takashi Iwai [Sun, 28 Feb 2016 10:41:47 +0000 (11:41 +0100)]
ALSA: timer: Fix ioctls for X32 ABI
[ Upstream commit
b24e7ad1fdc22177eb3e51584e1cfcb45d818488 ]
X32 ABI takes the 64bit timespec, thus the timer user status ioctl becomes
incompatible with IA32. This results in NOTTY error when the ioctl is
issued.
Meanwhile, this struct in X32 is essentially identical with the one in
X86-64, so we can just bypassing to the existing code for this
specific compat ioctl.
Cc: <stable@vger.kernel.org> # v3.4+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Takashi Iwai [Sun, 28 Feb 2016 10:36:14 +0000 (11:36 +0100)]
ALSA: timer: Fix broken compat timer user status ioctl
[ Upstream commit
3a72494ac2a3bd229db941d51e7efe2f6ccd947b ]
The timer user status compat ioctl returned the bogus struct used for
64bit architectures instead of the 32bit one. This patch addresses
it to return the proper struct.
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Takashi Iwai [Sun, 28 Feb 2016 10:28:08 +0000 (11:28 +0100)]
ALSA: rawmidi: Fix ioctls X32 ABI
[ Upstream commit
2251fbbc1539f05b0b206b37a602d5776be37252 ]
Like the previous fixes for ctl and PCM, we need a fix for
incompatible X32 ABI regarding the rawmidi: namely, struct
snd_rawmidi_status has the timespec, and the size and the alignment on
X32 differ from IA32.
This patch fixes the incompatible ioctl for X32.
Cc: <stable@vger.kernel.org> # v3.4+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Takashi Iwai [Sun, 28 Feb 2016 10:23:09 +0000 (11:23 +0100)]
ALSA: pcm: Fix ioctls for X32 ABI
[ Upstream commit
513ace79b657e2022a592e77f24074e088681ecc ]
X32 ABI uses the 64bit timespec in addition to 64bit alignment of
64bit values. This leads to incompatibilities in some PCM ioctls
involved with snd_pcm_channel_info, snd_pcm_status and
snd_pcm_sync_ptr structs. Fix the PCM compat ABI for these ioctls
like the previous commit for ctl API.
Reported-by: Steven Newbury <steve@snewbury.org.uk>
Cc: <stable@vger.kernel.org> # v3.4+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Takashi Iwai [Sat, 27 Feb 2016 16:52:42 +0000 (17:52 +0100)]
ALSA: ctl: Fix ioctls for X32 ABI
[ Upstream commit
6236d8bb2afcfe71b88ecea554e0dc638090a45f ]
The X32 ABI takes the same alignment like x86-64, and this may result
in the incompatible struct size from ia32. Unfortunately, we hit this
in some control ABI: struct snd_ctl_elem_value differs between them
due to the position of 64bit variable array. This ends up with the
unknown ioctl (ENOTTY) error.
The fix is to add the compat entries for the new aligned struct.
Reported-and-tested-by: Steven Newbury <steve@snewbury.org.uk>
Cc: <stable@vger.kernel.org> # v3.4+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Michael S. Tsirkin [Sun, 28 Feb 2016 14:31:39 +0000 (16:31 +0200)]
vfio: fix ioctl error handling
[ Upstream commit
8160c4e455820d5008a1116d2dca35f0363bb062 ]
Calling return copy_to_user(...) in an ioctl will not
do the right thing if there's a pagefault:
copy_to_user returns the number of bytes not copied
in this case.
Fix up vfio to do
return copy_to_user(...)) ?
-EFAULT : 0;
everywhere.
Cc: stable@vger.kernel.org
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Al Viro [Sun, 28 Feb 2016 00:23:16 +0000 (19:23 -0500)]
namei: ->d_inode of a pinned dentry is stable only for positives
[ Upstream commit
d4565649b6d6923369112758212b851adc407f0c ]
both do_last() and walk_component() risk picking a NULL inode out
of dentry about to become positive, *then* checking its flags and
seeing that it's not negative anymore and using (already stale by
then) value they'd fetched earlier. Usually ends up oopsing soon
after that...
Cc: stable@vger.kernel.org # v3.13+
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Al Viro [Sun, 28 Feb 2016 00:17:33 +0000 (19:17 -0500)]
do_last(): don't let a bogus return value from ->open() et.al. to confuse us
[ Upstream commit
c80567c82ae4814a41287618e315a60ecf513be6 ]
... into returning a positive to path_openat(), which would interpret that
as "symlink had been encountered" and proceed to corrupt memory, etc.
It can only happen due to a bug in some ->open() instance or in some LSM
hook, etc., so we report any such event *and* make sure it doesn't trick
us into further unpleasantness.
Cc: stable@vger.kernel.org # v3.6+, at least
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Mikulas Patocka [Thu, 25 Feb 2016 17:17:38 +0000 (18:17 +0100)]
hpfs: don't truncate the file when delete fails
[ Upstream commit
b6853f78e763d42c7a158d8de3549c9827c604ab ]
The delete opration can allocate additional space on the HPFS filesystem
due to btree split. The HPFS driver checks in advance if there is
available space, so that it won't corrupt the btree if we run out of space
during splitting.
If there is not enough available space, the HPFS driver attempted to
truncate the file, but this results in a deadlock since the commit
7dd29d8d865efdb00c0542a5d2c87af8c52ea6c7 ("HPFS: Introduce a global mutex
and lock it on every callback from VFS").
This patch removes the code that tries to truncate the file and -ENOSPC is
returned instead. If the user hits -ENOSPC on delete, he should try to
delete other files (that are stored in a leaf btree node), so that the
delete operation will make some space for deleting the file stored in
non-leaf btree node.
Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
Cc: stable@vger.kernel.org # 2.6.39+
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Mel Gorman [Fri, 26 Feb 2016 23:19:31 +0000 (15:19 -0800)]
mm: numa: quickly fail allocations for NUMA balancing on full nodes
[ Upstream commit
8479eba7781fa9ffb28268840de6facfc12c35a7 ]
Commit
4167e9b2cf10 ("mm: remove GFP_THISNODE") removed the GFP_THISNODE
flag combination due to confusing semantics. It noted that
alloc_misplaced_dst_page() was one such user after changes made by
commit
e97ca8e5b864 ("mm: fix GFP_THISNODE callers and clarify").
Unfortunately when GFP_THISNODE was removed, users of
alloc_misplaced_dst_page() started waking kswapd and entering direct
reclaim because the wrong GFP flags are cleared. The consequence is
that workloads that used to fit into memory now get reclaimed which is
addressed by this patch.
The problem can be demonstrated with "mutilate" that exercises memcached
which is software dedicated to memory object caching. The configuration
uses 80% of memory and is run 3 times for varying numbers of clients.
The results on a 4-socket NUMA box are
mutilate
4.4.0 4.4.0
vanilla numaswap-v1
Hmean 1 8394.71 ( 0.00%) 8395.32 ( 0.01%)
Hmean 4 30024.62 ( 0.00%) 34513.54 ( 14.95%)
Hmean 7 32821.08 ( 0.00%) 70542.96 (114.93%)
Hmean 12 55229.67 ( 0.00%) 93866.34 ( 69.96%)
Hmean 21 39438.96 ( 0.00%) 85749.21 (117.42%)
Hmean 30 37796.10 ( 0.00%) 50231.49 ( 32.90%)
Hmean 47 18070.91 ( 0.00%) 38530.13 (113.22%)
The metric is queries/second with the more the better. The results are
way outside of the noise and the reason for the improvement is obvious
from some of the vmstats
4.4.0 4.4.0
vanillanumaswap-v1r1
Minor Faults
1929399272 2146148218
Major Faults
19746529 3567
Swap Ins
57307366 9913
Swap Outs
50623229 17094
Allocation stalls 35909 443
DMA allocs 0 0
DMA32 allocs
72976349 170567396
Normal allocs
5306640898 5310651252
Movable allocs 0 0
Direct pages scanned
404130893 799577
Kswapd pages scanned
160230174 0
Kswapd pages reclaimed
55928786 0
Direct pages reclaimed 1843936 41921
Page writes file 2391 0
Page writes anon
50623229 17094
The vanilla kernel is swapping like crazy with large amounts of direct
reclaim and kswapd activity. The figures are aggregate but it's known
that the bad activity is throughout the entire test.
Note that simple streaming anon/file memory consumers also see this
problem but it's not as obvious. In those cases, kswapd is awake when
it should not be.
As there are at least two reclaim-related bugs out there, it's worth
spelling out the user-visible impact. This patch only addresses bugs
related to excessive reclaim on NUMA hardware when the working set is
larger than a NUMA node. There is a bug related to high kswapd CPU
usage but the reports are against laptops and other UMA hardware and is
not addressed by this patch.
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: David Rientjes <rientjes@google.com>
Cc: <stable@vger.kernel.org> [4.1+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Andrea Arcangeli [Fri, 26 Feb 2016 23:19:28 +0000 (15:19 -0800)]
mm: thp: fix SMP race condition between THP page fault and MADV_DONTNEED
[ Upstream commit
ad33bb04b2a6cee6c1f99fabb15cddbf93ff0433 ]
pmd_trans_unstable()/pmd_none_or_trans_huge_or_clear_bad() were
introduced to locklessy (but atomically) detect when a pmd is a regular
(stable) pmd or when the pmd is unstable and can infinitely transition
from pmd_none() and pmd_trans_huge() from under us, while only holding
the mmap_sem for reading (for writing not).
While holding the mmap_sem only for reading, MADV_DONTNEED can run from
under us and so before we can assume the pmd to be a regular stable pmd
we need to compare it against pmd_none() and pmd_trans_huge() in an
atomic way, with pmd_trans_unstable(). The old pmd_trans_huge() left a
tiny window for a race.
Useful applications are unlikely to notice the difference as doing
MADV_DONTNEED concurrently with a page fault would lead to undefined
behavior.
[akpm@linux-foundation.org: tidy up comment grammar/layout]
Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
Reported-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Colin Ian King [Fri, 26 Feb 2016 18:55:31 +0000 (18:55 +0000)]
x86/mpx: Fix off-by-one comparison with nr_registers
[ Upstream commit
9bf148cb0812595bfdf5100bd2c07e9bec9c6ef5 ]
In the unlikely event that regno == nr_registers then we get an array
overrun on regoff because the invalid register check is currently
off-by-one. Fix this with a check that regno is >= nr_registers instead.
Detected with static analysis using CoverityScan.
Fixes:
fcc7ffd67991 "x86, mpx: Decode MPX instruction to get bound violation information"
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1456512931-3388-1-git-send-email-colin.king@canonical.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Paolo Bonzini [Fri, 26 Feb 2016 11:28:40 +0000 (12:28 +0100)]
KVM: x86: fix root cause for missed hardware breakpoints
[ Upstream commit
70e4da7a8ff62f2775337b705f45c804bb450454 ]
Commit
172b2386ed16 ("KVM: x86: fix missed hardware breakpoints",
2016-02-10) worked around a case where the debug registers are not loaded
correctly on preemption and on the first entry to KVM_RUN.
However, Xiao Guangrong pointed out that the root cause must be that
KVM_DEBUGREG_BP_ENABLED is not being set correctly. This can indeed
happen due to the lazy debug exit mechanism, which does not call
kvm_update_dr7. Fix it by replacing the existing loop (more or less
equivalent to kvm_update_dr0123) with calls to all the kvm_update_dr*
functions.
Cc: stable@vger.kernel.org # 4.1+
Fixes:
172b2386ed16a9143d9a456aae5ec87275c61489
Reviewed-by: Xiao Guangrong <guangrong.xiao@linux.intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Harvey Hunt [Wed, 24 Feb 2016 15:16:43 +0000 (15:16 +0000)]
libata: Align ata_device's id on a cacheline
[ Upstream commit
4ee34ea3a12396f35b26d90a094c75db95080baa ]
The id buffer in ata_device is a DMA target, but it isn't explicitly
cacheline aligned. Due to this, adjacent fields can be overwritten with
stale data from memory on non coherent architectures. As a result, the
kernel is sometimes unable to communicate with an ATA device.
Fix this by ensuring that the id buffer is cacheline aligned.
This issue is similar to that fixed by Commit
84bda12af31f
("libata: align ap->sector_buf").
Signed-off-by: Harvey Hunt <harvey.hunt@imgtec.com>
Cc: linux-kernel@vger.kernel.org
Cc: <stable@vger.kernel.org> # 2.6.18
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Jay Cornwall [Wed, 10 Feb 2016 21:48:01 +0000 (15:48 -0600)]
iommu/amd: Apply workaround for ATS write permission check
[ Upstream commit
358875fd52ab8f00f66328cbf1a1d2486f265829 ]
The AMD Family 15h Models 30h-3Fh (Kaveri) BIOS and Kernel Developer's
Guide omitted part of the BIOS IOMMU L2 register setup specification.
Without this setup the IOMMU L2 does not fully respect write permissions
when handling an ATS translation request.
The IOMMU L2 will set PTE dirty bit when handling an ATS translation with
write permission request, even when PTE RW bit is clear. This may occur by
direct translation (which would cause a PPR) or by prefetch request from
the ATC.
This is observed in practice when the IOMMU L2 modifies a PTE which maps a
pagecache page. The ext4 filesystem driver BUGs when asked to writeback
these (non-modified) pages.
Enable ATS write permission check in the Kaveri IOMMU L2 if BIOS has not.
Signed-off-by: Jay Cornwall <jay@jcornwall.me>
Cc: <stable@vger.kernel.org> # v3.19+
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Suravee Suthikulpanit [Tue, 23 Feb 2016 12:03:30 +0000 (13:03 +0100)]
iommu/amd: Fix boot warning when device 00:00.0 is not iommu covered
[ Upstream commit
38e45d02ea9f194b89d6bf41e52ccafc8e2c2b47 ]
The setup code for the performance counters in the AMD IOMMU driver
tests whether the counters can be written. It tests to setup a counter
for device 00:00.0, which fails on systems where this particular device
is not covered by the IOMMU.
Fix this by not relying on device 00:00.0 but only on the IOMMU being
present.
Cc: stable@vger.kernel.org
Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Takashi Iwai [Thu, 25 Feb 2016 13:31:59 +0000 (14:31 +0100)]
ALSA: hda - Fix headset support and noise on HP EliteBook 755 G2
[ Upstream commit
f883982dc1b117f04579f0896821cd9f2e397f94 ]
HP EliteBook 755 G2 with ALC3228 (ALC280) codec [103c:221c] requires
the known fixup (ALC269_FIXUP_HEADSET_MIC) for making the headset mic
working. Also, it suffers from the loopback noise problem, so we
should disable aamix path as well.
Reported-by: Derick Eddington <derick.eddington@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
David Henningsson [Thu, 25 Feb 2016 08:37:05 +0000 (09:37 +0100)]
ALSA: hda - Fixup speaker pass-through control for nid 0x14 on ALC225
[ Upstream commit
2ae955774f29bbd7d16149cb0ae8d0319bf2ecc4 ]
On one of the machines we enable, we found that the actual speaker volume
did not always correspond to the volume set in alsamixer. This patch
fixes that problem.
This patch was orginally written by Kailang @ Realtek, I've rebased it
to fit sound git master.
Cc: stable@vger.kernel.org
BugLink: https://bugs.launchpad.net/bugs/1549660
Co-Authored-By: Kailang <kailang@realtek.com>
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Kailang Yang [Wed, 3 Feb 2016 07:20:39 +0000 (15:20 +0800)]
ALSA: hda/realtek - Support Dell headset mode for ALC225
[ Upstream commit
cfc5a845e62853edd36e564c23c64588f4adcae6 ]
Dell create new platform with ALC298 codec.
This patch will enable headset mode for ALC225/ALC3253 platform.
Signed-off-by: Kailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org> # v4.4+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
David Woodhouse [Mon, 1 Feb 2016 14:04:46 +0000 (14:04 +0000)]
Fix directory hardlinks from deleted directories
[ Upstream commit
be629c62a603e5935f8177fd8a19e014100a259e ]
When a directory is deleted, we don't take too much care about killing off
all the dirents that belong to it — on the basis that on remount, the scan
will conclude that the directory is dead anyway.
This doesn't work though, when the deleted directory contained a child
directory which was moved *out*. In the early stages of the fs build
we can then end up with an apparent hard link, with the child directory
appearing both in its true location, and as a child of the original
directory which are this stage of the mount process we don't *yet* know
is defunct.
To resolve this, take out the early special-casing of the "directories
shall not have hard links" rule in jffs2_build_inode_pass1(), and let the
normal nlink processing happen for directories as well as other inodes.
Then later in the build process we can set ic->pino_nlink to the parent
inode#, as is required for directories during normal operaton, instead
of the nlink. And complain only *then* about hard links which are still
in evidence even after killing off all the unreachable paths.
Reported-by: Liu Song <liu.song11@zte.com.cn>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
David Woodhouse [Mon, 1 Feb 2016 12:37:20 +0000 (12:37 +0000)]
jffs2: Fix page lock / f->sem deadlock
[ Upstream commit
49e91e7079febe59a20ca885a87dd1c54240d0f1 ]
With this fix, all code paths should now be obtaining the page lock before
f->sem.
Reported-by: Szabó Tamás <sztomi89@gmail.com>
Tested-by: Thomas Betker <thomas.betker@rohde-schwarz.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>