Now that we disable audio while setting up the audio
hw, we should be able to set this up without hangs.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Disable audio around audio hw setup. This may avoid
hangs on certain asics.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Properly clear the enable bit when audio disable is requested.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Need to free the uvd ring. Also reshuffle gart tear down to
happen after uvd tear down.
Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
Cc: stable@vger.kernel.org
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Causes display problems. We had already disabled
sharing for non-DP displays.
Based on a patch from:
Niels Ole Salscheider <niels_ole@salscheider-online.de>
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=58121
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Otherwise we might get a crash here.
Signed-off-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Print the supported functions mask in addition to
the version. This is useful in debugging PX
problems since we can see what functions are available.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
- Add the new sched_setattr/sched_getattr syscalls to the asm-generic
syscall list, which is used by arc, arm64, c6x, hexagon, metag,
openrisc, score, tile, and unicore32.
- An IRQ affinity bug fix for metag to prevent interrupts being vectored
to offline CPUs when their affinity is changed via /proc/irq/ (thanks
tglx).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
iQIcBAABAgAGBQJTDwkFAAoJEKHZs+irPybfR/wP/RP4hhdad9i+Poc86PAj0vGT
6KyNgUifceh9WfQbHom84GvBnhLB66J2Uc4uUX6F+xdUmPUvhhn4Nac39c4exMnf
klWoqcKkm8jb1kGLVuUdlgSssqLudEca/C5ArbOpZfvVwQxFf+WNpyWUNsNlvS/I
M1chio/jyWewVq2K4CmB/ZdoQ8lC7EVKH1FwCuMOsV9h7M32eqvpQgopSiKnKFw1
0o9a775PUvEK9PvEMa16ALShjch72ATFM9cVgFULr9M3BjHCn2H/jaNBzAhBLGSa
+sAcgFBQumLrK1HqyThW7Fm5rXQwMuru3nHYevBFXwLKrVSMjqN+tfCEY4oLGwSz
ywGc0rqNR7AuBzL/dnsjdBNhg30rvMIvWb/F6o/SM2IJNvnQjNJbKA97qdCqOevH
hpyycx/zAbEtX/8hsPHRkCNg9+Ms0wcH9NJ8u5ul24WVAd1rYCcgmHWNdIFpkE9G
fA6qckAye9/3xREi7gA50sl02Dxq4xyYaAfv72lOLEy+MIK/e8xMJL+PuI2eVt+g
J0AsjmuVNuNPK64eohmBBgXsS+7czMTuaHvHOCP6897bipUHAzx//UC347WOar1p
LvbLUpK9T5YGUxfoZ/ZlD8hi9myxKqIFNJnfJRwIhMpkYebFkqOsYRYXuZ6zPtDT
haQisQWsM7eLTMe9qRr+
=fVZo
-----END PGP SIGNATURE-----
Merge tag 'metag-fixes-v3.14' of git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/metag
Pull Metag arch and asm-generic fixes from James Hogan:
- Add the new sched_setattr/sched_getattr syscalls to the asm-generic
syscall list, which is used by arc, arm64, c6x, hexagon, metag,
openrisc, score, tile, and unicore32.
- An IRQ affinity bug fix for metag to prevent interrupts being
vectored to offline CPUs when their affinity is changed via
/proc/irq/ (thanks tglx).
* tag 'metag-fixes-v3.14' of git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/metag:
irq-metag*: stop set_affinity vectoring to offline cpus
asm-generic: add sched_setattr/sched_getattr syscalls
Just a single trivial patch to plug a memory leak in an error path.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJTDgK7AAoJEN0jrNd/PrOh6c4P/iBytP1gTlfTjleUO5/2n0vt
ILn6JWPoYx9hP+Zt+rjGqezIHAc60exGyANJOf8T+/BU9moHVHK9uCEzEu0vP8SR
qQyVxhXC55xL/6aHrQWtD47q13PNG989MGC4W/jWkPHbvtxg0YzWAu/Nq12ueZA8
vmkQKLVBG1Z9YQ9u1c4H4cP5XkLCZWTZAnImpcX35Nop74bTtOg+izoWm+3Yrt+K
vHlonTE7DsYdrjDoD+c0b1FjE7F376ywJAh9zEJox0OR+wLOdKCTqA6/qSwuv8dR
l5DLUbbmeTD+gOLEjDYcAw5FDmYDC5KygM7PtS7M+wmaHISHATlTlosmbozukbu/
Xit/IeRYRF+6t1JejO2cMGGZuDJ9uT1rKVl5KqA6mVAlrsYuFK+uzCcXNv6KwNxK
VrUG76KlBmy7ALn3dCBw6+dqFwmxBRUkRjaPByF9nvCAqBNud/uWVvfDGFF+dgo4
j1SKOrRq9N89uwYQpofLsLeVCWqm8QTbUuNLkz6z23xy2hItDYupLn0DRj2ND3ud
qF3QnEGx515ZlShAgkzkGCu6kRXMuUHAIMd7juZVjp5HDJJXK23zktSxflley5yX
Za8nRtIlM716TJxXQuJIjW14BKDmdoBvy/SRuGfa+lywfrgMKwndWHIt9VD5QLYo
xF6gRl4CuZqRuxF8RRbw
=zhst
-----END PGP SIGNATURE-----
Merge tag 'pwm/for-3.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm
Pull pwm fix from Thierry Reding:
"Just a single trivial patch to plug a memory leak in an error path"
* tag 'pwm/for-3.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm:
pwm: lp3943: Fix potential memory leak during request
Pull filesystem fixes from Jan Kara:
"Notification, writeback, udf, quota fixes
The notification patches are (with one exception) a fallout of my
fsnotify rework which went into -rc1 (I've extented LTP to cover these
cornercases to avoid similar breakage in future).
The UDF patch is a nasty data corruption Al has recently reported,
the revert of the writeback patch is due to possibility of violating
sync(2) guarantees, and a quota bug can lead to corruption of quota
files in ocfs2"
* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs:
fsnotify: Allocate overflow events with proper type
fanotify: Handle overflow in case of permission events
fsnotify: Fix detection whether overflow event is queued
Revert "writeback: do not sync data dirtied after sync start"
quota: Fix race between dqput() and dquot_scan_active()
udf: Fix data corruption on file type conversion
inotify: Fix reporting of cookies for inotify events
touch freed memory.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJTDdwqAAoJECmIfjd9wqK0+LUP/35Ds9kdee6XawmaVCFegmgJ
FeW+2yBwwZyHqY77xkjZy2nrl7A9+LSzGnQocQdsHBy2PKtqlrt+ksx2Vz83nk3g
Qtqzzz3uW7iiWSz6vI3PuD1Ye4Z6ebvq5IFeSnInBMTBZUGY+bdX+wWZe/xtuXAh
a67nynajQRXWotg58WRJD0MUXYNbPY3S174NHr3BQV7DMzqtZyOiZmVDd1uIFIbu
5JNyXxCprydey0lFvDef7oVueCk/VD9mQha2ogYizta4NR+gjuTjQWdyTxXvri+A
48gQHEXAWgRR7YBeiOWeUvHquNL4G6im+HoXNwJ93IK19xY5UeGU/MuyPJzhqPNc
ysxdDOi760Vggdc86Yx//+8W5EnSA3q0vnIKRGA+oWeZxR9Y+83Eg87bRFVa9Zdi
TpvdegXzj/ZCwx3AKVAb2NBfrcQP8RucVHw8CsNY7a1WfpKL/k70JWqbGeGkp/iB
LZyQQjOmweUv6h41wOrsvJHNeKKuUi280tP2Eck1KPebfI8kZCpjV3rqaqxdTIYB
5l0+eI2JFD4KIsJr0Xv+QjDwRO+wKXXGUKcsj0FlEzzIK5b7iV7jKRYfYw0VRg/X
ZCtO16nBZ+mmGt6kyEoToOt+YhOoqGL/HglbXUxvjRQL19LwpRbINvN/54f5idGy
J1IXvzLyhkxO8s48QWmD
=J2Up
-----END PGP SIGNATURE-----
Merge tag 'upstream-3.14-rc5' of git://git.infradead.org/linux-ubifs
Pull ubifs fix from Artem Bityutskiy:
"Just a single fix for the UBI module unload path which makes sure we
do not touch freed memory"
* tag 'upstream-3.14-rc5' of git://git.infradead.org/linux-ubifs:
UBI: fix some use after free bugs
The problem occurs when the guest performs a pusha with the stack
address pointing to an mmio address (or an invalid guest physical
address) to start with, but then extending into an ordinary guest
physical address. When doing repeated emulated pushes
emulator_read_write sets mmio_needed to 1 on the first one. On a
later push when the stack points to regular memory,
mmio_nr_fragments is set to 0, but mmio_is_needed is not set to 0.
As a result, KVM exits to userspace, and then returns to
complete_emulated_mmio. In complete_emulated_mmio
vcpu->mmio_cur_fragment is incremented. The termination condition of
vcpu->mmio_cur_fragment == vcpu->mmio_nr_fragments is never achieved.
The code bounces back and fourth to userspace incrementing
mmio_cur_fragment past it's buffer. If the guest does nothing else it
eventually leads to a a crash on a memcpy from invalid memory address.
However if a guest code can cause the vm to be destroyed in another
vcpu with excellent timing, then kvm_clear_async_pf_completion_queue
can be used by the guest to control the data that's pointed to by the
call to cancel_work_item, which can be used to gain execution.
Fixes: f78146b0f9
Signed-off-by: Andrew Honig <ahonig@google.com>
Cc: stable@vger.kernel.org (3.5+)
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Commit 1fcf7ce0c6 (arm: kvm: implement CPU PM notifier) added
support for CPU power-management, using a cpu_notifier to re-init
KVM on a CPU that entered CPU idle.
The code assumed that a CPU entering idle would actually be powered
off, loosing its state entierely, and would then need to be
reinitialized. It turns out that this is not always the case, and
some HW performs CPU PM without actually killing the core. In this
case, we try to reinitialize KVM while it is still live. It ends up
badly, as reported by Andre Przywara (using a Calxeda Midway):
[ 3.663897] Kernel panic - not syncing: unexpected prefetch abort in Hyp mode at: 0x685760
[ 3.663897] unexpected data abort in Hyp mode at: 0xc067d150
[ 3.663897] unexpected HVC/SVC trap in Hyp mode at: 0xc0901dd0
The trick here is to detect if we've been through a full re-init or
not by looking at HVBAR (VBAR_EL2 on arm64). This involves
implementing the backend for __hyp_get_vectors in the main KVM HYP
code (rather small), and checking the return value against the
default one when the CPU notifier is called on CPU_PM_EXIT.
Reported-by: Andre Przywara <osp@andrep.de>
Tested-by: Andre Przywara <osp@andrep.de>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Rob Herring <rob.herring@linaro.org>
Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
It was always intended that a user could provide a thin metadata device
that is larger than the max supported by the on-disk format. The extra
space would just go unused.
Unfortunately that never worked. If the user attempted to use a larger
metadata device on creation they would get an error like the following:
device-mapper: space map common: space map too large
device-mapper: transaction manager: couldn't create metadata space map
device-mapper: thin metadata: tm_create_with_sm failed
device-mapper: table: 252:17: thin-pool: Error creating metadata object
device-mapper: ioctl: error adding target to table
Fix this by allowing the initial metadata space map creation to cap its
size at the max number of blocks supported (DM_SM_METADATA_MAX_BLOCKS).
get_metadata_dev_size() must also impose DM_SM_METADATA_MAX_BLOCKS (via
THIN_METADATA_MAX_SECTORS), otherwise extending metadata would cap at
THIN_METADATA_MAX_SECTORS_WARNING (which is larger than supported).
Also, the calculation for THIN_METADATA_MAX_SECTORS didn't account for
the sizeof the disk_bitmap_header. So the supported maximum metadata
size is a bit smaller (reduced from 33423360 to 33292800 sectors).
Lastly, remove the "excess space will not be used" warning message from
get_metadata_dev_size(); it resulted in printing the warning multiple
times. Factor out warn_if_metadata_device_too_big(), call it from
pool_ctr() and maybe_resize_metadata_dev().
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Acked-by: Joe Thornber <ejt@redhat.com>
A few more driver specific bug fixes, all driver specific things that
only affect users of those devices.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJTDyNMAAoJELSic+t+oim9ar0P/2J7YHzqD/gs9SR4ufqr2JK9
yudP5Stt81np6IZwJHJTF3n33RMXTanAdaFr5usJn0Mn8THuMzL6vCOr9zhoEOxu
j3HDvR6rLnVQ9N0Cw9L7uM+goQzbw3N/rAfyUd6UckT1raKCErtLRZvvb7BV9FLX
gu3K3b4w7LtTYqoFPPGpxjTENwNkX5rNWD5egDVnaiL9maAoCUal9HtznDSLu0pa
uo8ggJRXEQYXAQ1rpEvSKwwYrZ2fQ3IxTMi3ucm9KxGvO3xyK/aXt32yp0qH5Poz
v3FWDbXU8DsVYFXlRNrAIiAuMERBCsZQHismp3mt/yn+IOvcJHNVeRSJbIROddRr
TCU7vo/OoBzsN5BJ4McoHtmfJXKaN+xY5yJJ7xczBcYPcfQlIXiXZbSJC8WNFVet
MlNcvqpVzo9BIXwrGDbPofUBiruyOcbXg79QW1xWfR122BNoF2Ut+dKfXsoXfW5Y
oETCw5oMO4dOifLvWp+0q0GXOG0EK1fqiHoHxhU/fksr/WQeJS7bplixXpPZoiqV
PC6RKnFEeMHMdFmPyo7kQ94KVn4uQ/SomL+MQUIi+7+e2iC0vqql2A5kmE9iO+dS
V7KuVgwcQ3QkIHEVeHKwKH3ETsKB7yktqlnqysPgwAf8fNKeokNk7eALsxkeSkt3
b00TyEOk9oRYPlhmpcTd
=GL3V
-----END PGP SIGNATURE-----
Merge tag 'asoc-v3.14-rc4-2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Updates for v3.14
A few more driver specific bug fixes, all driver specific things that
only affect users of those devices.
Drew Richardson reported that he could make the kernel go *boom* when hotplugging
while having perf events active.
It turned out that when you have a group event, the code in
__perf_event_exit_context() fails to remove the group siblings from
the context.
We then proceed with destroying and freeing the event, and when you
re-plug the CPU and try and add another event to that CPU, things go
*boom* because you've still got dead entries there.
Reported-by: Drew Richardson <drew.richardson@arm.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/n/tip-k6v5wundvusvcseqj1si0oz0@git.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Vince "Super Tester" Weaver reported a new round of syscall fuzzing (Trinity) failures,
with perf WARN_ON()s triggering. He also provided traces of the failures.
This is I think the relevant bit:
> pec_1076_warn-2804 [000] d... 147.926153: x86_pmu_disable: x86_pmu_disable
> pec_1076_warn-2804 [000] d... 147.926153: x86_pmu_state: Events: {
> pec_1076_warn-2804 [000] d... 147.926156: x86_pmu_state: 0: state: .R config: ffffffffffffffff ( (null))
> pec_1076_warn-2804 [000] d... 147.926158: x86_pmu_state: 33: state: AR config: 0 (ffff88011ac99800)
> pec_1076_warn-2804 [000] d... 147.926159: x86_pmu_state: }
> pec_1076_warn-2804 [000] d... 147.926160: x86_pmu_state: n_events: 1, n_added: 0, n_txn: 1
> pec_1076_warn-2804 [000] d... 147.926161: x86_pmu_state: Assignment: {
> pec_1076_warn-2804 [000] d... 147.926162: x86_pmu_state: 0->33 tag: 1 config: 0 (ffff88011ac99800)
> pec_1076_warn-2804 [000] d... 147.926163: x86_pmu_state: }
> pec_1076_warn-2804 [000] d... 147.926166: collect_events: Adding event: 1 (ffff880119ec8800)
So we add the insn:p event (fd[23]).
At this point we should have:
n_events = 2, n_added = 1, n_txn = 1
> pec_1076_warn-2804 [000] d... 147.926170: collect_events: Adding event: 0 (ffff8800c9e01800)
> pec_1076_warn-2804 [000] d... 147.926172: collect_events: Adding event: 4 (ffff8800cbab2c00)
We try and add the {BP,cycles,br_insn} group (fd[3], fd[4], fd[15]).
These events are 0:cycles and 4:br_insn, the BP event isn't x86_pmu so
that's not visible.
group_sched_in()
pmu->start_txn() /* nop - BP pmu */
event_sched_in()
event->pmu->add()
So here we should end up with:
0: n_events = 3, n_added = 2, n_txn = 2
4: n_events = 4, n_added = 3, n_txn = 3
But seeing the below state on x86_pmu_enable(), the must have failed,
because the 0 and 4 events aren't there anymore.
Looking at group_sched_in(), since the BP is the leader, its
event_sched_in() must have succeeded, for otherwise we would not have
seen the sibling adds.
But since neither 0 or 4 are in the below state; their event_sched_in()
must have failed; but I don't see why, the complete state: 0,0,1:p,4
fits perfectly fine on a core2.
However, since we try and schedule 4 it means the 0 event must have
succeeded! Therefore the 4 event must have failed, its failure will
have put group_sched_in() into the fail path, which will call:
event_sched_out()
event->pmu->del()
on 0 and the BP event.
Now x86_pmu_del() will reduce n_events; but it will not reduce n_added;
giving what we see below:
n_event = 2, n_added = 2, n_txn = 2
> pec_1076_warn-2804 [000] d... 147.926177: x86_pmu_enable: x86_pmu_enable
> pec_1076_warn-2804 [000] d... 147.926177: x86_pmu_state: Events: {
> pec_1076_warn-2804 [000] d... 147.926179: x86_pmu_state: 0: state: .R config: ffffffffffffffff ( (null))
> pec_1076_warn-2804 [000] d... 147.926181: x86_pmu_state: 33: state: AR config: 0 (ffff88011ac99800)
> pec_1076_warn-2804 [000] d... 147.926182: x86_pmu_state: }
> pec_1076_warn-2804 [000] d... 147.926184: x86_pmu_state: n_events: 2, n_added: 2, n_txn: 2
> pec_1076_warn-2804 [000] d... 147.926184: x86_pmu_state: Assignment: {
> pec_1076_warn-2804 [000] d... 147.926186: x86_pmu_state: 0->33 tag: 1 config: 0 (ffff88011ac99800)
> pec_1076_warn-2804 [000] d... 147.926188: x86_pmu_state: 1->0 tag: 1 config: 1 (ffff880119ec8800)
> pec_1076_warn-2804 [000] d... 147.926188: x86_pmu_state: }
> pec_1076_warn-2804 [000] d... 147.926190: x86_pmu_enable: S0: hwc->idx: 33, hwc->last_cpu: 0, hwc->last_tag: 1 hwc->state: 0
So the problem is that x86_pmu_del(), when called from a
group_sched_in() that fails (for whatever reason), and without x86_pmu
TXN support (because the leader is !x86_pmu), will corrupt the n_added
state.
Reported-and-Tested-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Dave Jones <davej@redhat.com>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/20140221150312.GF3104@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
A somewhat large set of fixes here due to the identification of some
systematic problems with hard to use APIs in the subsystem. Takashi did
a lot of work to address the enumeration API which uncovered a number of
off by one bugs caused by confusing APIs while Charles addressed issues
in the locking around DAPM.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJTCXkuAAoJELSic+t+oim99LEP/3o0MTeminJkA0ks+edRN32I
zlbPd1iv38Rh20J85zJ8lHhZlkDVPpwYVEDziCClfG3QbWiwh18HEreOhi5xswxi
qSIk+4chXvBpdWaopLq+MEZSEqFLaHDeWPifzNs8tjQ2F8+RPZ5aOtmeBrwFQZVR
fJmuJ8KnOvjcH8WGNKIepZENqNIU7NuwMmzB7mHwyANKuan30u9Vx5r7OZBEkA1h
n6vNa48i2HKrdFwajm7Y/o8s5Qrnseiz6NepaO4hTHQhlFhsU9mjCeYvmzhvc1Jv
NAC3x2yUIrff95IwzMQi/jwJHJN+VXIqvsp1MWNm4rOucZ5kxw+dtFmmXtvsedI1
HO1gWPqvsYENs5L4cGbi1An/T7vSWOjsbs/2QwRRqduRHVJxnnoADswoQG2AGhOy
z1uJsebt72eAsoCxrPmaysa4irNwkDLwpFEjTpEGpgWo3j5d+UfEUScc/1B3ia7g
a/Oq9q/Q71ogdKSrMpYc66eK7y1XGF2XZNl4x3g/ZwswibM4aIwBr6ZekpoPPOYq
KT3zEecKJ+lbPxl2rUQgm9ivAuC1XKJoBRLRgHXGtzZI54SFUkFD/dVL6GFfR6bS
V8RHeGqOmoD/w6WpfXC4w9yhfNhJPbOKOaSFUdCyU5D2bgb7AOcwZOXRavXtJwJP
//gsmzui+ikt4scli8a/
=Ty2j
-----END PGP SIGNATURE-----
Merge tag 'asoc-v3.14-rc4' into asoc-linus
ASoC: Fixes for v3.14
A somewhat large set of fixes here due to the identification of some
systematic problems with hard to use APIs in the subsystem. Takashi did
a lot of work to address the enumeration API which uncovered a number of
off by one bugs caused by confusing APIs while Charles addressed issues
in the locking around DAPM.
# gpg: Signature made Sun 23 Feb 2014 13:29:34 KST using RSA key ID 7EA229BD
# gpg: Good signature from "Mark Brown <broonie@sirena.org.uk>"
# gpg: aka "Mark Brown <broonie@debian.org>"
# gpg: aka "Mark Brown <broonie@kernel.org>"
# gpg: aka "Mark Brown <broonie@tardis.ed.ac.uk>"
# gpg: aka "Mark Brown <broonie@linaro.org>"
# gpg: aka "Mark Brown <Mark.Brown@linaro.org>"
A few fixes, all driver speccific ones. The DaVinci ones aren't as
clear as they should be from the subject lines on the commits but they
fix issues which will prevent correct operation in some use cases and
only affect that particular driver so are reasonably safe.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJTBDGxAAoJELSic+t+oim95ZoP/0YCVAn+Eia9ohs6o+8bEQWb
UXj6PxGlwk0z7kPsTLbffCqPlktTlrJPIpL4JPLkWPxUrS8Q/Lc1jSBS/wIfeQXs
u+kjn/RR91p8yLRDaVpgp2adoh18d9YU9hYuCcoDu+gLOCzTdLOXV3IriN67Sp3p
WZIORNKPaRH4uHQdtcY+ajdwduWi5fd4cF56FOS2xnq0dxJ07rFpLmdm6HaKxOB0
J9/F1h+asgdBIYmkg/+Kex1MO0OvcfCUSsYNbybXqesjfdicEHIco4IvegqBYq3F
wwu5K/bJQUx4Ylah3JvNCRDlzMLSTD709hcOZsEoZmrB6cWwakrJAkBXN2N6AHUt
CjzKZ+JLKovjttZ/h86MtvulQwH+T6ouVJ0CUcgNoD+pGlytl30DGB9Cn2j33jKr
ix/LvFF12wES1G8poAHvskuGWONyfefFq7Ri+t+W5blitSUVVYO+5EwZC7BR0GNt
bhoFxeTC2nO7tYkTTzoNEFrU/X+zy4m8dQfkaSDYnaDTtSURlOwa24qmCbI+FSTo
Ti7T/NtyWzDtFbDhxxhVE8HMR1BO9X2+16zAEN4SuWotYXzab7xbh3wjOQtWa5HL
toEBBY3ZQ5VFkCxe35dAXMPVp1ToQh7dTVohGE4wg7yPiorZ44ehNsSTMNaItjh5
/d2rx9Su3+X2R2xY+UqK
=Kgdb
-----END PGP SIGNATURE-----
Merge tag 'asoc-v3.14-rc3' into asoc-linus
ASoC: Fixes for v3.14
A few fixes, all driver speccific ones. The DaVinci ones aren't as
clear as they should be from the subject lines on the commits but they
fix issues which will prevent correct operation in some use cases and
only affect that particular driver so are reasonably safe.
# gpg: Signature made Wed 19 Feb 2014 13:23:13 KST using RSA key ID 7EA229BD
# gpg: Good signature from "Mark Brown <broonie@sirena.org.uk>"
# gpg: aka "Mark Brown <broonie@debian.org>"
# gpg: aka "Mark Brown <broonie@kernel.org>"
# gpg: aka "Mark Brown <broonie@tardis.ed.ac.uk>"
# gpg: aka "Mark Brown <broonie@linaro.org>"
# gpg: aka "Mark Brown <Mark.Brown@linaro.org>"
There is a typo in the Limiter2 Release Rate control, a wrong enum for
Limiter1 is assigned. It must point to Limiter2.
Spotted by a compile warning:
In file included from sound/soc/codecs/sta32x.c:34:0:
sound/soc/codecs/sta32x.c:223:29: warning: ‘sta32x_limiter2_release_rate_enum’ defined but not used [-Wunused-variable]
static SOC_ENUM_SINGLE_DECL(sta32x_limiter2_release_rate_enum,
^
include/sound/soc.h:275:18: note: in definition of macro ‘SOC_ENUM_DOUBLE_DECL’
struct soc_enum name = SOC_ENUM_DOUBLE(xreg, xshift_l, xshift_r, \
^
sound/soc/codecs/sta32x.c:223:8: note: in expansion of macro ‘SOC_ENUM_SINGLE_DECL’
static SOC_ENUM_SINGLE_DECL(sta32x_limiter2_release_rate_enum,
^
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
Cc: <stable@vger.kernel.org>
A somewhat large set of fixes here due to the identification of some
systematic problems with hard to use APIs in the subsystem. Takashi did
a lot of work to address the enumeration API which uncovered a number of
off by one bugs caused by confusing APIs while Charles addressed issues
in the locking around DAPM.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJTCXkuAAoJELSic+t+oim99LEP/3o0MTeminJkA0ks+edRN32I
zlbPd1iv38Rh20J85zJ8lHhZlkDVPpwYVEDziCClfG3QbWiwh18HEreOhi5xswxi
qSIk+4chXvBpdWaopLq+MEZSEqFLaHDeWPifzNs8tjQ2F8+RPZ5aOtmeBrwFQZVR
fJmuJ8KnOvjcH8WGNKIepZENqNIU7NuwMmzB7mHwyANKuan30u9Vx5r7OZBEkA1h
n6vNa48i2HKrdFwajm7Y/o8s5Qrnseiz6NepaO4hTHQhlFhsU9mjCeYvmzhvc1Jv
NAC3x2yUIrff95IwzMQi/jwJHJN+VXIqvsp1MWNm4rOucZ5kxw+dtFmmXtvsedI1
HO1gWPqvsYENs5L4cGbi1An/T7vSWOjsbs/2QwRRqduRHVJxnnoADswoQG2AGhOy
z1uJsebt72eAsoCxrPmaysa4irNwkDLwpFEjTpEGpgWo3j5d+UfEUScc/1B3ia7g
a/Oq9q/Q71ogdKSrMpYc66eK7y1XGF2XZNl4x3g/ZwswibM4aIwBr6ZekpoPPOYq
KT3zEecKJ+lbPxl2rUQgm9ivAuC1XKJoBRLRgHXGtzZI54SFUkFD/dVL6GFfR6bS
V8RHeGqOmoD/w6WpfXC4w9yhfNhJPbOKOaSFUdCyU5D2bgb7AOcwZOXRavXtJwJP
//gsmzui+ikt4scli8a/
=Ty2j
-----END PGP SIGNATURE-----
Merge tag 'asoc-v3.14-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v3.14
A somewhat large set of fixes here due to the identification of some
systematic problems with hard to use APIs in the subsystem. Takashi did
a lot of work to address the enumeration API which uncovered a number of
off by one bugs caused by confusing APIs while Charles addressed issues
in the locking around DAPM.
Fix Dave's git tree.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Add an entry for radeon.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
ehci_irq() and ehci_hrtimer_func() can deadlock on ehci->lock when
threadirqs option is used. To prevent the deadlock use
spin_lock_irqsave() in ehci_irq().
This change can be reverted when hrtimer callbacks become threaded.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hello,
the following patch adds an entry for the PID of a Cressi Leonardo
diving computer interface to kernel 3.13.0.
It is detected as FT232RL.
Works with subsurface.
Signed-off-by: Joerg Dorchain <joerg@dorchain.net>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
acpi_processor_set_throttling() uses set_cpus_allowed_ptr() to make
sure that the (struct acpi_processor)->acpi_processor_set_throttling()
callback will run on the right CPU. However, the function may be
called from a worker thread already bound to a different CPU in which
case that won't work.
Make acpi_processor_set_throttling() use work_on_cpu() as appropriate
instead of abusing set_cpus_allowed_ptr().
Reported-and-tested-by: Jiri Olsa <jolsa@redhat.com>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Cc: All applicable <stable@vger.kernel.org>
[rjw: Changelog]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Read-only large sptes can be created due to read-only faults as
follows:
- QEMU pagetable entry that maps guest memory is read-only
due to COW.
- Guest read faults such memory, COW is not broken, because
it is a read-only fault.
- Enable dirty logging, large spte not nuked because it is read-only.
- Write-fault on such memory causes guest to loop endlessly
(which must go down to level 1 because dirty logging is enabled).
Fix by dropping large spte when necessary.
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Fix a memory leak in the lp3943_pwm_request_map() error handling path.
Make sure already allocated pwm map memory is freed correctly.
Detected by Coverity: CID 1162829.
Signed-off-by: Christian Engelmayer <cengelma@gmx.at>
Acked-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
An invalid ioctl will never be valid, irrespective of whether multipath
has active paths or not. So for invalid ioctls we do not have to wait
for multipath to activate any paths, but can rather return an error
code immediately. This fix resolves numerous instances of:
udevd[]: worker [] unexpectedly returned with status 0x0100
that have been seen during testing.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org
The driver reads from the DC offset control registers during callibration
but since the registers are marked as volatile and there is a register
cache the values will not be read from the hardware after the first reading
rendering the callibration ineffective.
It appears that the driver was originally written for the ASoC level
register I/O code but converted to regmap prior to merge and this issue
was missed during the conversion as the framework level volatile register
functionality was not being used.
Signed-off-by: Mark Brown <broonie@linaro.org>
Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Cc: stable@vger.kernel.org
Include kASLR offset in VMCOREINFO ELF notes to assist in debugging.
[ hpa: pushing this for v3.14 to avoid having a kernel version with
kASLR where we can't debug output. ]
Signed-off-by: Eugene Surovegin <surovegin@google.com>
Link: http://lkml.kernel.org/r/20140123173120.GA25474@www.outflux.net
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
During restore, pm_notifier chain are called with
PM_RESTORE_PREPARE. The firmware_class driver handler
fw_pm_notify does not have a handler for this. As a result,
it keeps a reader on the kmod.c umhelper_sem. During
freeze_processes, the call to __usermodehelper_disable tries to
take a write lock on this semaphore and hangs waiting.
Signed-off-by: Sebastian Capella <sebastian.capella@linaro.org>
Acked-by: Ming Lei <ming.lei@canonical.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Commit fcb6a15c2e (intel_pstate: Take core C0 time into account for
core busy calculation) introduced a regression on some processor SKUs
supported by intel_pstate. This was due to the truncation caused by
using integer math to calculate core busy and C0 percentages.
On a i7-4770K processor operating at 800Mhz going to 100% utilization
the percent busy of the CPU using integer math is 22%, but it actually
is 22.85%. This value scaled to the current frequency returned 97
which the PID interpreted as no error and did not adjust the P state.
Tested on i7-4770K, i7-2600, i5-3230M.
Fixes: fcb6a15c2e (intel_pstate: Take core C0 time into account for core busy calculation)
References: https://lkml.org/lkml/2014/2/19/626
References: https://bugzilla.kernel.org/show_bug.cgi?id=70941
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Merge misc fixes from Andrew Morton.
* emailed patches from Andrew Morton akpm@linux-foundation.org>:
MAINTAINERS: change mailing list address for Altera UART drivers
Makefile: fix build with make 3.80 again
MAINTAINERS: update L: misuses
Makefile: fix extra parenthesis typo when CC_STACKPROTECTOR_REGULAR is enabled
ipc,mqueue: remove limits for the amount of system-wide queues
memcg: change oom_info_lock to mutex
mm, thp: fix infinite loop on memcg OOM
drivers/fmc/fmc-write-eeprom.c: fix decimal permissions
drivers/iommu/omap-iommu-debug.c: fix decimal permissions
mm, hwpoison: release page on PageHWPoison() in __do_fault()
The nios2-dev list has been moved to the RocketBoards infrastructure, so
adjust the address accordingly.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
According to Documentation/Changes, make 3.80 is still being supported
for building the kernel, hence make files must not make (unconditional)
use of features introduced only in newer versions. Commit 8779657d29
("stackprotector: Introduce CONFIG_CC_STACKPROTECTOR_STRONG") however
introduced an "else ifdef" construct which make 3.80 doesn't understand.
Also correct a warning message still referencing the old config option
name.
Apart from that I question the use of "ifdef" here (but it was used that
way already prior to said commit): ifeq (,y) would seem more to the
point.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Michal Marek <mmarek@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
L: lines are for the email addresses of traditional mailing lists.
W: lines are for URLs.
Convert two L: misuses to W: links.
Signed-off-by: Joe Perches <joe@perches.com>
Reported-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
An extra parenthesis typo introduced in 19952a9203 ("stackprotector:
Unify the HAVE_CC_STACKPROTECTOR logic between architectures") is
causing the following error when CONFIG_CC_STACKPROTECTOR_REGULAR is
enabled:
Makefile:608: Cannot use CONFIG_CC_STACKPROTECTOR: -fstack-protector not supported by compiler
Makefile:608: *** missing separator. Stop.
Signed-off-by: Fathi Boudra <fathi.boudra@linaro.org>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit 93e6f119c0 ("ipc/mqueue: cleanup definition names and
locations") added global hardcoded limits to the amount of message
queues that can be created. While these limits are per-namespace,
reality is that it ends up breaking userspace applications.
Historically users have, at least in theory, been able to create up to
INT_MAX queues, and limiting it to just 1024 is way too low and dramatic
for some workloads and use cases. For instance, Madars reports:
"This update imposes bad limits on our multi-process application. As
our app uses approaches that each process opens its own set of queues
(usually something about 3-5 queues per process). In some scenarios
we might run up to 3000 processes or more (which of-course for linux
is not a problem). Thus we might need up to 9000 queues or more. All
processes run under one user."
Other affected users can be found in launchpad bug #1155695:
https://bugs.launchpad.net/ubuntu/+source/manpages/+bug/1155695
Instead of increasing this limit, revert it entirely and fallback to the
original way of dealing queue limits -- where once a user's resource
limit is reached, and all memory is used, new queues cannot be created.
Signed-off-by: Davidlohr Bueso <davidlohr@hp.com>
Reported-by: Madars Vitolins <m@silodev.com>
Acked-by: Doug Ledford <dledford@redhat.com>
Cc: Manfred Spraul <manfred@colorfullife.com>
Cc: <stable@vger.kernel.org> [3.5+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Kirill has reported the following:
Task in /test killed as a result of limit of /test
memory: usage 10240kB, limit 10240kB, failcnt 51
memory+swap: usage 10240kB, limit 10240kB, failcnt 0
kmem: usage 0kB, limit 18014398509481983kB, failcnt 0
Memory cgroup stats for /test:
BUG: sleeping function called from invalid context at kernel/cpu.c:68
in_atomic(): 1, irqs_disabled(): 0, pid: 66, name: memcg_test
2 locks held by memcg_test/66:
#0: (memcg_oom_lock#2){+.+...}, at: [<ffffffff81131014>] pagefault_out_of_memory+0x14/0x90
#1: (oom_info_lock){+.+...}, at: [<ffffffff81197b2a>] mem_cgroup_print_oom_info+0x2a/0x390
CPU: 2 PID: 66 Comm: memcg_test Not tainted 3.14.0-rc1-dirty #745
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Bochs 01/01/2011
Call Trace:
__might_sleep+0x16a/0x210
get_online_cpus+0x1c/0x60
mem_cgroup_read_stat+0x27/0xb0
mem_cgroup_print_oom_info+0x260/0x390
dump_header+0x88/0x251
? trace_hardirqs_on+0xd/0x10
oom_kill_process+0x258/0x3d0
mem_cgroup_oom_synchronize+0x656/0x6c0
? mem_cgroup_charge_common+0xd0/0xd0
pagefault_out_of_memory+0x14/0x90
mm_fault_error+0x91/0x189
__do_page_fault+0x48e/0x580
do_page_fault+0xe/0x10
page_fault+0x22/0x30
which complains that mem_cgroup_read_stat cannot be called from an atomic
context but mem_cgroup_print_oom_info takes a spinlock. Change
oom_info_lock to a mutex.
This was introduced by 947b3dd1a8 ("memcg, oom: lock
mem_cgroup_print_oom_info").
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Reported-by: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Masayoshi Mizuma reported a bug with the hang of an application under
the memcg limit. It happens on write-protection fault to huge zero page
If we successfully allocate a huge page to replace zero page but hit the
memcg limit we need to split the zero page with split_huge_page_pmd()
and fallback to small pages.
The other part of the problem is that VM_FAULT_OOM has special meaning
in do_huge_pmd_wp_page() context. __handle_mm_fault() expects the page
to be split if it sees VM_FAULT_OOM and it will will retry page fault
handling. This causes an infinite loop if the page was not split.
do_huge_pmd_wp_zero_page_fallback() can return VM_FAULT_OOM if it failed
to allocate one small page, so fallback to small pages will not help.
The solution for this part is to replace VM_FAULT_OOM with
VM_FAULT_FALLBACK is fallback required.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reported-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
Reviewed-by: Michal Hocko <mhocko@suse.cz>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: David Rientjes <rientjes@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This 444 should have been octal.
Signed-off-by: Joe Perches <joe@perches.com>
Cc: Alessandro Rubini <rubini@gnudd.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
These should have been octal.
Signed-off-by: Joe Perches <joe@perches.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
