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>
Thomas Betker [Tue, 10 Nov 2015 21:18:15 +0000 (22:18 +0100)]
Revert "jffs2: Fix lock acquisition order bug in jffs2_write_begin"
[ Upstream commit
157078f64b8a9cd7011b6b900b2f2498df850748 ]
This reverts commit
5ffd3412ae55
("jffs2: Fix lock acquisition order bug in jffs2_write_begin").
The commit modified jffs2_write_begin() to remove a deadlock with
jffs2_garbage_collect_live(), but this introduced new deadlocks found
by multiple users. page_lock() actually has to be called before
mutex_lock(&c->alloc_sem) or mutex_lock(&f->sem) because
jffs2_write_end() and jffs2_readpage() are called with the page locked,
and they acquire c->alloc_sem and f->sem, resp.
In other words, the lock order in jffs2_write_begin() was correct, and
it is the jffs2_garbage_collect_live() path that has to be changed.
Revert the commit to get rid of the new deadlocks, and to clear the way
for a better fix of the original deadlock.
Reported-by: Deng Chao <deng.chao1@zte.com.cn>
Reported-by: Ming Liu <liu.ming50@gmail.com>
Reported-by: wangzaiwei <wangzaiwei@top-vision.cn>
Signed-off-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>
Mike Krinkin [Wed, 24 Feb 2016 18:02:31 +0000 (21:02 +0300)]
KVM: x86: MMU: fix ubsan index-out-of-range warning
[ Upstream commit
17e4bce0ae63c7e03f3c7fa8d80890e7af3d4971 ]
Ubsan reports the following warning due to a typo in
update_accessed_dirty_bits template, the patch fixes
the typo:
[ 168.791851] ================================================================================
[ 168.791862] UBSAN: Undefined behaviour in arch/x86/kvm/paging_tmpl.h:252:15
[ 168.791866] index 4 is out of range for type 'u64 [4]'
[ 168.791871] CPU: 0 PID: 2950 Comm: qemu-system-x86 Tainted: G O L 4.5.0-rc5-next-
20160222 #7
[ 168.791873] Hardware name: LENOVO 23205NG/23205NG, BIOS G2ET95WW (2.55 ) 07/09/2013
[ 168.791876]
0000000000000000 ffff8801cfcaf208 ffffffff81c9f780 0000000041b58ab3
[ 168.791882]
ffffffff82eb2cc1 ffffffff81c9f6b4 ffff8801cfcaf230 ffff8801cfcaf1e0
[ 168.791886]
0000000000000004 0000000000000001 0000000000000000 ffffffffa1981600
[ 168.791891] Call Trace:
[ 168.791899] [<
ffffffff81c9f780>] dump_stack+0xcc/0x12c
[ 168.791904] [<
ffffffff81c9f6b4>] ? _atomic_dec_and_lock+0xc4/0xc4
[ 168.791910] [<
ffffffff81da9e81>] ubsan_epilogue+0xd/0x8a
[ 168.791914] [<
ffffffff81daafa2>] __ubsan_handle_out_of_bounds+0x15c/0x1a3
[ 168.791918] [<
ffffffff81daae46>] ? __ubsan_handle_shift_out_of_bounds+0x2bd/0x2bd
[ 168.791922] [<
ffffffff811287ef>] ? get_user_pages_fast+0x2bf/0x360
[ 168.791954] [<
ffffffffa1794050>] ? kvm_largepages_enabled+0x30/0x30 [kvm]
[ 168.791958] [<
ffffffff81128530>] ? __get_user_pages_fast+0x360/0x360
[ 168.791987] [<
ffffffffa181b818>] paging64_walk_addr_generic+0x1b28/0x2600 [kvm]
[ 168.792014] [<
ffffffffa1819cf0>] ? init_kvm_mmu+0x1100/0x1100 [kvm]
[ 168.792019] [<
ffffffff8129e350>] ? debug_check_no_locks_freed+0x350/0x350
[ 168.792044] [<
ffffffffa1819cf0>] ? init_kvm_mmu+0x1100/0x1100 [kvm]
[ 168.792076] [<
ffffffffa181c36d>] paging64_gva_to_gpa+0x7d/0x110 [kvm]
[ 168.792121] [<
ffffffffa181c2f0>] ? paging64_walk_addr_generic+0x2600/0x2600 [kvm]
[ 168.792130] [<
ffffffff812e848b>] ? debug_lockdep_rcu_enabled+0x7b/0x90
[ 168.792178] [<
ffffffffa17d9a4a>] emulator_read_write_onepage+0x27a/0x1150 [kvm]
[ 168.792208] [<
ffffffffa1794d44>] ? __kvm_read_guest_page+0x54/0x70 [kvm]
[ 168.792234] [<
ffffffffa17d97d0>] ? kvm_task_switch+0x160/0x160 [kvm]
[ 168.792238] [<
ffffffff812e848b>] ? debug_lockdep_rcu_enabled+0x7b/0x90
[ 168.792263] [<
ffffffffa17daa07>] emulator_read_write+0xe7/0x6d0 [kvm]
[ 168.792290] [<
ffffffffa183b620>] ? em_cr_write+0x230/0x230 [kvm]
[ 168.792314] [<
ffffffffa17db005>] emulator_write_emulated+0x15/0x20 [kvm]
[ 168.792340] [<
ffffffffa18465f8>] segmented_write+0xf8/0x130 [kvm]
[ 168.792367] [<
ffffffffa1846500>] ? em_lgdt+0x20/0x20 [kvm]
[ 168.792374] [<
ffffffffa14db512>] ? vmx_read_guest_seg_ar+0x42/0x1e0 [kvm_intel]
[ 168.792400] [<
ffffffffa1846d82>] writeback+0x3f2/0x700 [kvm]
[ 168.792424] [<
ffffffffa1846990>] ? em_sidt+0xa0/0xa0 [kvm]
[ 168.792449] [<
ffffffffa185554d>] ? x86_decode_insn+0x1b3d/0x4f70 [kvm]
[ 168.792474] [<
ffffffffa1859032>] x86_emulate_insn+0x572/0x3010 [kvm]
[ 168.792499] [<
ffffffffa17e71dd>] x86_emulate_instruction+0x3bd/0x2110 [kvm]
[ 168.792524] [<
ffffffffa17e6e20>] ? reexecute_instruction.part.110+0x2e0/0x2e0 [kvm]
[ 168.792532] [<
ffffffffa14e9a81>] handle_ept_misconfig+0x61/0x460 [kvm_intel]
[ 168.792539] [<
ffffffffa14e9a20>] ? handle_pause+0x450/0x450 [kvm_intel]
[ 168.792546] [<
ffffffffa15130ea>] vmx_handle_exit+0xd6a/0x1ad0 [kvm_intel]
[ 168.792572] [<
ffffffffa17f6a6c>] ? kvm_arch_vcpu_ioctl_run+0xbdc/0x6090 [kvm]
[ 168.792597] [<
ffffffffa17f6bcd>] kvm_arch_vcpu_ioctl_run+0xd3d/0x6090 [kvm]
[ 168.792621] [<
ffffffffa17f6a6c>] ? kvm_arch_vcpu_ioctl_run+0xbdc/0x6090 [kvm]
[ 168.792627] [<
ffffffff8293b530>] ? __ww_mutex_lock_interruptible+0x1630/0x1630
[ 168.792651] [<
ffffffffa17f5e90>] ? kvm_arch_vcpu_runnable+0x4f0/0x4f0 [kvm]
[ 168.792656] [<
ffffffff811eeb30>] ? preempt_notifier_unregister+0x190/0x190
[ 168.792681] [<
ffffffffa17e0447>] ? kvm_arch_vcpu_load+0x127/0x650 [kvm]
[ 168.792704] [<
ffffffffa178e9a3>] kvm_vcpu_ioctl+0x553/0xda0 [kvm]
[ 168.792727] [<
ffffffffa178e450>] ? vcpu_put+0x40/0x40 [kvm]
[ 168.792732] [<
ffffffff8129e350>] ? debug_check_no_locks_freed+0x350/0x350
[ 168.792735] [<
ffffffff82946087>] ? _raw_spin_unlock+0x27/0x40
[ 168.792740] [<
ffffffff8163a943>] ? handle_mm_fault+0x1673/0x2e40
[ 168.792744] [<
ffffffff8129daa8>] ? trace_hardirqs_on_caller+0x478/0x6c0
[ 168.792747] [<
ffffffff8129dcfd>] ? trace_hardirqs_on+0xd/0x10
[ 168.792751] [<
ffffffff812e848b>] ? debug_lockdep_rcu_enabled+0x7b/0x90
[ 168.792756] [<
ffffffff81725a80>] do_vfs_ioctl+0x1b0/0x12b0
[ 168.792759] [<
ffffffff817258d0>] ? ioctl_preallocate+0x210/0x210
[ 168.792763] [<
ffffffff8174aef3>] ? __fget+0x273/0x4a0
[ 168.792766] [<
ffffffff8174acd0>] ? __fget+0x50/0x4a0
[ 168.792770] [<
ffffffff8174b1f6>] ? __fget_light+0x96/0x2b0
[ 168.792773] [<
ffffffff81726bf9>] SyS_ioctl+0x79/0x90
[ 168.792777] [<
ffffffff82946880>] entry_SYSCALL_64_fastpath+0x23/0xc1
[ 168.792780] ================================================================================
Signed-off-by: Mike Krinkin <krinkin.m.u@gmail.com>
Reviewed-by: Xiao Guangrong <guangrong.xiao@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Kai-Heng Feng [Thu, 25 Feb 2016 07:19:38 +0000 (15:19 +0800)]
ALSA: hda - Fixing background noise on Dell Inspiron 3162
[ Upstream commit
7cb32ae09a6490c27bc3c110ee42d808a5670142 ]
commit
3b43b71f05d3ecd01c4116254666d9492301697d upstream.
After login to the desktop on Dell Inspiron 3162,
there's a very loud background noise comes from the builtin speaker.
The noise does not go away even if the speaker is muted.
The noise disappears after using the aamix fixup.
Codec: Realtek ALC3234
Address: 0
AFG Function Id: 0x1 (unsol 1)
Vendor Id: 0x10ec0255
Subsystem Id: 0x10280725
Revision Id: 0x100002
No Modem Function Group found
BugLink: http://bugs.launchpad.net/bugs/1549620
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Kailang [Mon, 28 Dec 2015 03:35:24 +0000 (11:35 +0800)]
ALSA: hda - Add mic mute hotkey quirk for Lenovo ThinkCentre AIO
[ Upstream commit
3694cb2947db50753caf432db067487eafae7b9b ]
The Lenovo ThinkCenter AIO uses Line2 (NID 0x1b) to implement the
micmute hotkey, here we register an input device and use Line2 unsol
event to collect the hotkey pressing or releasing.
In the meanwhile, the micmute led is controlled by GPIO2, so we
use an existing function alc_fixup_gpio_mic_mute_hook() to control
the led.
[Hui: And there are two places to register the input device, to make
the code simple and clean, move the two same code sections into a
function.]
Cc: <stable@vger.kernel.org>
Signed-off-by: Kailang <kailang@realtek.com>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Hui Wang [Tue, 8 Dec 2015 04:27:18 +0000 (12:27 +0800)]
ALSA: hda - Fixing speaker noise on the two latest thinkpad models
[ Upstream commit
23adc192b862b69ad80a40bd5206e337f41264ac ]
We have two latest thinkpad laptop models which are all based on the
Intel skylake platforms, and all of them have the codec alc293 on
them. When the machines boot to the desktop, an greeting dialogue
shows up with the notification sound. But on these two models, there
is noise with the notification sound. We have 3 SKUs for each of
the models, all of them have this problem.
So far, this problem is only specific to these two thinkpad models,
we did not find this problem on the old thinkpad models with the
codec alc293 or alc292.
A workaround for this problem is disabling the aamix.
Cc: stable@vger.kernel.org
BugLink: https://bugs.launchpad.net/bugs/1523517
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Hui Wang [Tue, 24 Nov 2015 03:08:18 +0000 (11:08 +0800)]
ALSA: hda - Fix headphone noise after Dell XPS 13 resume back from S3
[ Upstream commit
8c69729b4439bbda88c3073df7243f755cc418ed ]
We have a machine Dell XPS 13 with the codec alc256, after resume back
from S3, the headphone has noise when play sound.
Through comparing with the coeff vaule before and after S3, we found
restoring a coeff register will help remove noise.
BugLink: https://bugs.launchpad.net/bugs/1519168
Cc: Kailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Kailang Yang [Mon, 26 Oct 2015 07:37:39 +0000 (15:37 +0800)]
ALSA: hda/realtek - Dell XPS one ALC3260 speaker no sound after resume back
[ Upstream commit
6ed1131fe196ad7ffc13acc1a1eadc08a1db0303 ]
This machine had I2S codec for speaker output.
It need to refill the I2S codec initial verb after resume back.
Signed-off-by: Kailang Yang <kailang@realtek.com>
Reported-and-tested-by: George Gugulea <gugulea@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Kailang Yang [Mon, 18 May 2015 07:31:20 +0000 (15:31 +0800)]
ALSA: hda/realtek - Support Dell headset mode for ALC298
[ Upstream commit
977e627684df0f60bdf2a768ec4772f42fe843fc ]
Dell create new platform with ALC298 codec.
This patch will enable headset mode for ALC298/ALC3266 platform.
Signed-off-by: Kailang Yang <kailang@realtek.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Peter Chen [Wed, 24 Feb 2016 03:05:25 +0000 (11:05 +0800)]
usb: chipidea: otg: change workqueue ci_otg as freezable
[ Upstream commit
d144dfea8af7108f613139623e63952ed7e69c0c ]
If we use USB ID pin as wakeup source, and there is a USB block
device on this USB OTG (ID) cable, the system will be deadlock
after system resume.
The root cause for this problem is: the workqueue ci_otg may try
to remove hcd before the driver resume has finished, and hcd will
disconnect the device on it, then, it will call device_release_driver,
and holds the device lock "dev->mutex", but it is never unlocked since
it waits workqueue writeback to run to flush the block information, but
the workqueue writeback is freezable, it is not thawed before driver
resume has finished.
When the driver (device: sd 0:0:0:0:) resume goes to dpm_complete, it
tries to get its device lock "dev->mutex", but it can't get it forever,
then the deadlock occurs. Below call stacks show the situation.
So, in order to fix this problem, we need to change workqueue ci_otg
as freezable, then the work item in this workqueue will be run after
driver's resume, this workqueue will not be blocked forever like above
case since the workqueue writeback has been thawed too.
Tested at: i.mx6qdl-sabresd and i.mx6sx-sdb.
[ 555.178869] kworker/u2:13 D
c07de74c 0 826 2 0x00000000
[ 555.185310] Workqueue: ci_otg ci_otg_work
[ 555.189353] Backtrace:
[ 555.191849] [<
c07de4fc>] (__schedule) from [<
c07dec6c>] (schedule+0x48/0xa0)
[ 555.198912] r10:
ee471ba0 r9:
00000000 r8:
00000000 r7:
00000002 r6:
ee470000 r5:
ee471ba4
[ 555.206867] r4:
ee470000
[ 555.209453] [<
c07dec24>] (schedule) from [<
c07e2fc4>] (schedule_timeout+0x15c/0x1e0)
[ 555.217212] r4:
7fffffff r3:
edc2b000
[ 555.220862] [<
c07e2e68>] (schedule_timeout) from [<
c07df6c8>] (wait_for_common+0x94/0x144)
[ 555.229140] r8:
00000000 r7:
00000002 r6:
ee470000 r5:
ee471ba4 r4:
7fffffff
[ 555.235980] [<
c07df634>] (wait_for_common) from [<
c07df790>] (wait_for_completion+0x18/0x1c)
[ 555.244430] r10:
00000001 r9:
c0b5563c r8:
c0042e48 r7:
ef086000 r6:
eea4372c r5:
ef131b00
[ 555.252383] r4:
00000000
[ 555.254970] [<
c07df778>] (wait_for_completion) from [<
c0043cb8>] (flush_work+0x19c/0x234)
[ 555.263177] [<
c0043b1c>] (flush_work) from [<
c0043fac>] (flush_delayed_work+0x48/0x4c)
[ 555.271106] r8:
ed5b5000 r7:
c0b38a3c r6:
eea439cc r5:
eea4372c r4:
eea4372c
[ 555.277958] [<
c0043f64>] (flush_delayed_work) from [<
c00eae18>] (bdi_unregister+0x84/0xec)
[ 555.286236] r4:
eea43520 r3:
20000153
[ 555.289885] [<
c00ead94>] (bdi_unregister) from [<
c02c2154>] (blk_cleanup_queue+0x180/0x29c)
[ 555.298250] r5:
eea43808 r4:
eea43400
[ 555.301909] [<
c02c1fd4>] (blk_cleanup_queue) from [<
c0417914>] (__scsi_remove_device+0x48/0xb8)
[ 555.310623] r7:
00000000 r6:
20000153 r5:
ededa950 r4:
ededa800
[ 555.316403] [<
c04178cc>] (__scsi_remove_device) from [<
c0415e90>] (scsi_forget_host+0x64/0x68)
[ 555.325028] r5:
ededa800 r4:
ed5b5000
[ 555.328689] [<
c0415e2c>] (scsi_forget_host) from [<
c0409828>] (scsi_remove_host+0x78/0x104)
[ 555.337054] r5:
ed5b5068 r4:
ed5b5000
[ 555.340709] [<
c04097b0>] (scsi_remove_host) from [<
c04cdfcc>] (usb_stor_disconnect+0x50/0xb4)
[ 555.349247] r6:
ed5b56e4 r5:
ed5b5818 r4:
ed5b5690 r3:
00000008
[ 555.355025] [<
c04cdf7c>] (usb_stor_disconnect) from [<
c04b3bc8>] (usb_unbind_interface+0x78/0x25c)
[ 555.363997] r8:
c13919b4 r7:
edd3c000 r6:
edd3c020 r5:
ee551c68 r4:
ee551c00 r3:
c04cdf7c
[ 555.371892] [<
c04b3b50>] (usb_unbind_interface) from [<
c03dc248>] (__device_release_driver+0x8c/0x118)
[ 555.381213] r10:
00000001 r9:
edd90c00 r8:
c13919b4 r7:
ee551c68 r6:
c0b546e0 r5:
c0b5563c
[ 555.389167] r4:
edd3c020
[ 555.391752] [<
c03dc1bc>] (__device_release_driver) from [<
c03dc2fc>] (device_release_driver+0x28/0x34)
[ 555.401071] r5:
edd3c020 r4:
edd3c054
[ 555.404721] [<
c03dc2d4>] (device_release_driver) from [<
c03db304>] (bus_remove_device+0xe0/0x110)
[ 555.413607] r5:
edd3c020 r4:
ef17f04c
[ 555.417253] [<
c03db224>] (bus_remove_device) from [<
c03d8128>] (device_del+0x114/0x21c)
[ 555.425270] r6:
edd3c028 r5:
edd3c020 r4:
ee551c00 r3:
00000000
[ 555.431045] [<
c03d8014>] (device_del) from [<
c04b1560>] (usb_disable_device+0xa4/0x1e8)
[ 555.439061] r8:
edd3c000 r7:
eded8000 r6:
00000000 r5:
00000001 r4:
ee551c00
[ 555.445906] [<
c04b14bc>] (usb_disable_device) from [<
c04a8e54>] (usb_disconnect+0x74/0x224)
[ 555.454271] r9:
edd90c00 r8:
ee551000 r7:
ee551c68 r6:
ee551c9c r5:
ee551c00 r4:
00000001
[ 555.462156] [<
c04a8de0>] (usb_disconnect) from [<
c04a8fb8>] (usb_disconnect+0x1d8/0x224)
[ 555.470259] r10:
00000001 r9:
edd90000 r8:
ee471e2c r7:
ee551468 r6:
ee55149c r5:
ee551400
[ 555.478213] r4:
00000001
[ 555.480797] [<
c04a8de0>] (usb_disconnect) from [<
c04ae5ec>] (usb_remove_hcd+0xa0/0x1ac)
[ 555.488813] r10:
00000001 r9:
ee471eb0 r8:
00000000 r7:
ef3d9500 r6:
eded810c r5:
eded80b0
[ 555.496765] r4:
eded8000
[ 555.499351] [<
c04ae54c>] (usb_remove_hcd) from [<
c04d4158>] (host_stop+0x28/0x64)
[ 555.506847] r6:
eeb50010 r5:
eded8000 r4:
eeb51010
[ 555.511563] [<
c04d4130>] (host_stop) from [<
c04d09b8>] (ci_otg_work+0xc4/0x124)
[ 555.518885] r6:
00000001 r5:
eeb50010 r4:
eeb502a0 r3:
c04d4130
[ 555.524665] [<
c04d08f4>] (ci_otg_work) from [<
c00454f0>] (process_one_work+0x194/0x420)
[ 555.532682] r6:
ef086000 r5:
eeb502a0 r4:
edc44480
[ 555.537393] [<
c004535c>] (process_one_work) from [<
c00457b0>] (worker_thread+0x34/0x514)
[ 555.545496] r10:
edc44480 r9:
ef086000 r8:
c0b1a100 r7:
ef086034 r6:
00000088 r5:
edc44498
[ 555.553450] r4:
ef086000
[ 555.556032] [<
c004577c>] (worker_thread) from [<
c004bab4>] (kthread+0xdc/0xf8)
[ 555.563268] r10:
00000000 r9:
00000000 r8:
00000000 r7:
c004577c r6:
edc44480 r5:
eddc15c0
[ 555.571221] r4:
00000000
[ 555.573804] [<
c004b9d8>] (kthread) from [<
c000fef0>] (ret_from_fork+0x14/0x24)
[ 555.581040] r7:
00000000 r6:
00000000 r5:
c004b9d8 r4:
eddc15c0
[ 553.429383] sh D
c07de74c 0 694 691 0x00000000
[ 553.435801] Backtrace:
[ 553.438295] [<
c07de4fc>] (__schedule) from [<
c07dec6c>] (schedule+0x48/0xa0)
[ 553.445358] r10:
edd3c054 r9:
edd3c078 r8:
edddbd50 r7:
edcbbc00 r6:
c1377c34 r5:
60000153
[ 553.453313] r4:
eddda000
[ 553.455896] [<
c07dec24>] (schedule) from [<
c07deff8>] (schedule_preempt_disabled+0x10/0x14)
[ 553.464261] r4:
edd3c058 r3:
0000000a
[ 553.467910] [<
c07defe8>] (schedule_preempt_disabled) from [<
c07e0bbc>] (mutex_lock_nested+0x1a0/0x3e8)
[ 553.477254] [<
c07e0a1c>] (mutex_lock_nested) from [<
c03e927c>] (dpm_complete+0xc0/0x1b0)
[ 553.485358] r10:
00561408 r9:
edd3c054 r8:
c0b4863c r7:
edddbd90 r6:
c0b485d8 r5:
edd3c020
[ 553.493313] r4:
edd3c0d0
[ 553.495896] [<
c03e91bc>] (dpm_complete) from [<
c03e9388>] (dpm_resume_end+0x1c/0x20)
[ 553.503652] r9:
00000000 r8:
c0b1a9d0 r7:
c1334ec0 r6:
c1334edc r5:
00000003 r4:
00000010
[ 553.511544] [<
c03e936c>] (dpm_resume_end) from [<
c0079894>] (suspend_devices_and_enter+0x158/0x504)
[ 553.520604] r4:
00000000 r3:
c1334efc
[ 553.524250] [<
c007973c>] (suspend_devices_and_enter) from [<
c0079e74>] (pm_suspend+0x234/0x2cc)
[ 553.532961] r10:
00561408 r9:
ed6b7300 r8:
00000004 r7:
c1334eec r6:
00000000 r5:
c1334ee8
[ 553.540914] r4:
00000003
[ 553.543493] [<
c0079c40>] (pm_suspend) from [<
c0078a6c>] (state_store+0x6c/0xc0)
[ 555.703684] 7 locks held by kworker/u2:13/826:
[ 555.708140] #0: ("%s""ci_otg"){++++.+}, at: [<
c0045484>] process_one_work+0x128/0x420
[ 555.716277] #1: ((&ci->work)){+.+.+.}, at: [<
c0045484>] process_one_work+0x128/0x420
[ 555.724317] #2: (usb_bus_list_lock){+.+.+.}, at: [<
c04ae5e4>] usb_remove_hcd+0x98/0x1ac
[ 555.732626] #3: (&dev->mutex){......}, at: [<
c04a8e28>] usb_disconnect+0x48/0x224
[ 555.740403] #4: (&dev->mutex){......}, at: [<
c04a8e28>] usb_disconnect+0x48/0x224
[ 555.748179] #5: (&dev->mutex){......}, at: [<
c03dc2f4>] device_release_driver+0x20/0x34
[ 555.756487] #6: (&shost->scan_mutex){+.+.+.}, at: [<
c04097d0>] scsi_remove_host+0x20/0x104
Cc: <stable@vger.kernel.org> #v3.14+
Cc: Jun Li <jun.li@nxp.com>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Ilya Dryomov [Fri, 19 Feb 2016 10:38:57 +0000 (11:38 +0100)]
libceph: use the right footer size when skipping a message
[ Upstream commit
dbc0d3caff5b7591e0cf8e34ca686ca6f4479ee1 ]
ceph_msg_footer is 21 bytes long, while ceph_msg_footer_old is only 13.
Don't skip too much when CEPH_FEATURE_MSG_AUTH isn't negotiated.
Cc: stable@vger.kernel.org # 3.19+
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Ilya Dryomov [Wed, 17 Feb 2016 19:04:08 +0000 (20:04 +0100)]
libceph: don't bail early from try_read() when skipping a message
[ Upstream commit
e7a88e82fe380459b864e05b372638aeacb0f52d ]
The contract between try_read() and try_write() is that when called
each processes as much data as possible. When instructed by osd_client
to skip a message, try_read() is violating this contract by returning
after receiving and discarding a single message instead of checking for
more. try_write() then gets a chance to write out more requests,
generating more replies/skips for try_read() to handle, forcing the
messenger into a starvation loop.
Cc: stable@vger.kernel.org # 3.10+
Reported-by: Varada Kari <Varada.Kari@sandisk.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Tested-by: Varada Kari <Varada.Kari@sandisk.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Steven Rostedt (Red Hat) [Wed, 24 Feb 2016 14:04:24 +0000 (09:04 -0500)]
tracing: Fix showing function event in available_events
[ Upstream commit
d045437a169f899dfb0f6f7ede24cc042543ced9 ]
The ftrace:function event is only displayed for parsing the function tracer
data. It is not used to enable function tracing, and does not include an
"enable" file in its event directory.
Originally, this event was kept separate from other events because it did
not have a ->reg parameter. But perf added a "reg" parameter for its use
which caused issues, because it made the event available to functions where
it was not compatible for.
Commit
9b63776fa3ca9 "tracing: Do not enable function event with enable"
added a TRACE_EVENT_FL_IGNORE_ENABLE flag that prevented the function event
from being enabled by normal trace events. But this commit missed keeping
the function event from being displayed by the "available_events" directory,
which is used to show what events can be enabled by set_event.
One documented way to enable all events is to:
cat available_events > set_event
But because the function event is displayed in the available_events, this
now causes an INVALID error:
cat: write error: Invalid argument
Reported-by: Chunyu Hu <chuhu@redhat.com>
Fixes:
9b63776fa3ca9 "tracing: Do not enable function event with enable"
Cc: stable@vger.kernel.org # 3.4+
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Christian Borntraeger [Fri, 19 Feb 2016 12:11:46 +0000 (13:11 +0100)]
KVM: async_pf: do not warn on page allocation failures
[ Upstream commit
d7444794a02ff655eda87e3cc54e86b940e7736f ]
In async_pf we try to allocate with NOWAIT to get an element quickly
or fail. This code also handle failures gracefully. Lets silence
potential page allocation failures under load.
qemu-system-s39: page allocation failure: order:0,mode:0x2200000
[...]
Call Trace:
([<
00000000001146b8>] show_trace+0xf8/0x148)
[<
000000000011476a>] show_stack+0x62/0xe8
[<
00000000004a36b8>] dump_stack+0x70/0x98
[<
0000000000272c3a>] warn_alloc_failed+0xd2/0x148
[<
000000000027709e>] __alloc_pages_nodemask+0x94e/0xb38
[<
00000000002cd36a>] new_slab+0x382/0x400
[<
00000000002cf7ac>] ___slab_alloc.constprop.30+0x2dc/0x378
[<
00000000002d03d0>] kmem_cache_alloc+0x160/0x1d0
[<
0000000000133db4>] kvm_setup_async_pf+0x6c/0x198
[<
000000000013dee8>] kvm_arch_vcpu_ioctl_run+0xd48/0xd58
[<
000000000012fcaa>] kvm_vcpu_ioctl+0x372/0x690
[<
00000000002f66f6>] do_vfs_ioctl+0x3be/0x510
[<
00000000002f68ec>] SyS_ioctl+0xa4/0xb8
[<
0000000000781c5e>] system_call+0xd6/0x264
[<
000003ffa24fa06a>] 0x3ffa24fa06a
Cc: stable@vger.kernel.org
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Dominik Dingel <dingel@linux.vnet.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Paolo Bonzini [Wed, 10 Feb 2016 16:50:23 +0000 (17:50 +0100)]
KVM: x86: fix missed hardware breakpoints
[ Upstream commit
172b2386ed16a9143d9a456aae5ec87275c61489 ]
Sometimes when setting a breakpoint a process doesn't stop on it.
This is because the debug registers are not loaded correctly on
VCPU load.
The following simple reproducer from Oleg Nesterov tries using debug
registers in two threads. To see the bug, run a 2-VCPU guest with
"taskset -c 0" and run "./bp 0 1" inside the guest.
#include <unistd.h>
#include <signal.h>
#include <stdlib.h>
#include <stdio.h>
#include <sys/wait.h>
#include <sys/ptrace.h>
#include <sys/user.h>
#include <asm/debugreg.h>
#include <assert.h>
#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
unsigned long encode_dr7(int drnum, int enable, unsigned int type, unsigned int len)
{
unsigned long dr7;
dr7 = ((len | type) & 0xf)
<< (DR_CONTROL_SHIFT + drnum * DR_CONTROL_SIZE);
if (enable)
dr7 |= (DR_GLOBAL_ENABLE << (drnum * DR_ENABLE_SIZE));
return dr7;
}
int write_dr(int pid, int dr, unsigned long val)
{
return ptrace(PTRACE_POKEUSER, pid,
offsetof (struct user, u_debugreg[dr]),
val);
}
void set_bp(pid_t pid, void *addr)
{
unsigned long dr7;
assert(write_dr(pid, 0, (long)addr) == 0);
dr7 = encode_dr7(0, 1, DR_RW_EXECUTE, DR_LEN_1);
assert(write_dr(pid, 7, dr7) == 0);
}
void *get_rip(int pid)
{
return (void*)ptrace(PTRACE_PEEKUSER, pid,
offsetof(struct user, regs.rip), 0);
}
void test(int nr)
{
void *bp_addr = &&label + nr, *bp_hit;
int pid;
printf("test bp %d\n", nr);
assert(nr < 16); // see 16 asm nops below
pid = fork();
if (!pid) {
assert(ptrace(PTRACE_TRACEME, 0,0,0) == 0);
kill(getpid(), SIGSTOP);
for (;;) {
label: asm (
"nop; nop; nop; nop;"
"nop; nop; nop; nop;"
"nop; nop; nop; nop;"
"nop; nop; nop; nop;"
);
}
}
assert(pid == wait(NULL));
set_bp(pid, bp_addr);
for (;;) {
assert(ptrace(PTRACE_CONT, pid, 0, 0) == 0);
assert(pid == wait(NULL));
bp_hit = get_rip(pid);
if (bp_hit != bp_addr)
fprintf(stderr, "ERR!! hit wrong bp %ld != %d\n",
bp_hit - &&label, nr);
}
}
int main(int argc, const char *argv[])
{
while (--argc) {
int nr = atoi(*++argv);
if (!fork())
test(nr);
}
while (wait(NULL) > 0)
;
return 0;
}
Cc: stable@vger.kernel.org
Suggested-by: Nadav Amit <namit@cs.technion.ac.il>
Reported-by: Andrey Wagin <avagin@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Mark Rutland [Tue, 16 Feb 2016 14:47:31 +0000 (14:47 +0000)]
KVM: arm/arm64: vgic: Ensure bitmaps are long enough
[ Upstream commit
236cf17c2502007a9d2dda3c39fb0d9a6bd03cc2 ]
When we allocate bitmaps in vgic_vcpu_init_maps, we divide the number of
bits we need by 8 to figure out how many bytes to allocate. However,
bitmap elements are always accessed as unsigned longs, and if we didn't
happen to allocate a size such that size % sizeof(unsigned long) == 0,
bitmap accesses may go past the end of the allocation.
When using KASAN (which does byte-granular access checks), this results
in a continuous stream of BUGs whenever these bitmaps are accessed:
=============================================================================
BUG kmalloc-128 (Tainted: G B ): kasan: bad access detected
-----------------------------------------------------------------------------
INFO: Allocated in vgic_init.part.25+0x55c/0x990 age=7493 cpu=3 pid=1730
INFO: Slab 0xffffffbde6d5da40 objects=16 used=15 fp=0xffffffc935769700 flags=0x4000000000000080
INFO: Object 0xffffffc935769500 @offset=1280 fp=0x (null)
Bytes b4
ffffffc9357694f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Object
ffffffc935769500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Object
ffffffc935769510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Object
ffffffc935769520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Object
ffffffc935769530: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Object
ffffffc935769540: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Object
ffffffc935769550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Object
ffffffc935769560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Object
ffffffc935769570: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Padding
ffffffc9357695b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Padding
ffffffc9357695c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Padding
ffffffc9357695d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Padding
ffffffc9357695e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Padding
ffffffc9357695f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
CPU: 3 PID: 1740 Comm: kvm-vcpu-0 Tainted: G B 4.4.0+ #17
Hardware name: ARM Juno development board (r1) (DT)
Call trace:
[<
ffffffc00008e770>] dump_backtrace+0x0/0x280
[<
ffffffc00008ea04>] show_stack+0x14/0x20
[<
ffffffc000726360>] dump_stack+0x100/0x188
[<
ffffffc00030d324>] print_trailer+0xfc/0x168
[<
ffffffc000312294>] object_err+0x3c/0x50
[<
ffffffc0003140fc>] kasan_report_error+0x244/0x558
[<
ffffffc000314548>] __asan_report_load8_noabort+0x48/0x50
[<
ffffffc000745688>] __bitmap_or+0xc0/0xc8
[<
ffffffc0000d9e44>] kvm_vgic_flush_hwstate+0x1bc/0x650
[<
ffffffc0000c514c>] kvm_arch_vcpu_ioctl_run+0x2ec/0xa60
[<
ffffffc0000b9a6c>] kvm_vcpu_ioctl+0x474/0xa68
[<
ffffffc00036b7b0>] do_vfs_ioctl+0x5b8/0xcb0
[<
ffffffc00036bf34>] SyS_ioctl+0x8c/0xa0
[<
ffffffc000086cb0>] el0_svc_naked+0x24/0x28
Memory state around the buggy address:
ffffffc935769400: 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffffffc935769480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>
ffffffc935769500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffffffc935769580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffffffc935769600: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
Fix the issue by always allocating a multiple of sizeof(unsigned long),
as we do elsewhere in the vgic code.
Fixes:
c1bfb577a ("arm/arm64: KVM: vgic: switch to dynamic allocation")
Cc: stable@vger.kernel.org
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Stefan Hajnoczi [Thu, 18 Feb 2016 18:55:54 +0000 (18:55 +0000)]
sunrpc/cache: fix off-by-one in qword_get()
[ Upstream commit
b7052cd7bcf3c1478796e93e3dff2b44c9e82943 ]
The qword_get() function NUL-terminates its output buffer. If the input
string is in hex format \xXXXX... and the same length as the output
buffer, there is an off-by-one:
int qword_get(char **bpp, char *dest, int bufsize)
{
...
while (len < bufsize) {
...
*dest++ = (h << 4) | l;
len++;
}
...
*dest = '\0';
return len;
}
This patch ensures the NUL terminator doesn't fall outside the output
buffer.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Alex Deucher [Fri, 19 Feb 2016 23:05:10 +0000 (18:05 -0500)]
drm/radeon/pm: adjust display configuration after powerstate
[ Upstream commit
39d4275058baf53e89203407bf3841ff2c74fa32 ]
set_power_state defaults to no displays, so we need to update
the display configuration after setting up the powerstate on the
first call. In most cases this is not an issue since ends up
getting called multiple times at any given modeset and the proper
order is achieved in the display changed handling at the top of
the function.
Reviewed-by: Christian König <christian.koenig@amd.com>
Acked-by: Jordan Lazare <Jordan.Lazare@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>
Martin Schwidefsky [Fri, 19 Feb 2016 13:44:14 +0000 (14:44 +0100)]
s390/compat: correct restore of high gprs on signal return
[ Upstream commit
342300cc9cd3428bc6bfe5809bfcc1b9a0f06702 ]
git commit
8070361799ae1e3f4ef347bd10f0a508ac10acfb
"s390: add support for vector extension"
broke 31-bit compat processes in regard to signal handling.
The restore_sigregs_ext32() function is used to restore the additional
elements from the user space signal frame. Among the additional elements
are the upper registers halves for 64-bit register support for 31-bit
processes. The copy_from_user that is used to retrieve the high-gprs
array from the user stack uses an incorrect length, 8 bytes instead of
64 bytes. This causes incorrect upper register halves to get loaded.
Cc: stable@vger.kernel.org # 3.8+
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Mike Snitzer [Mon, 22 Feb 2016 00:09:22 +0000 (19:09 -0500)]
dm: fix dm_rq_target_io leak on faults with .request_fn DM w/ blk-mq paths
[ Upstream commit
4328daa2e79ed904a42ce00a9f38b9c36b44b21a ]
Using request-based DM mpath configured with the following stacking
(.request_fn DM mpath ontop of scsi-mq paths):
echo Y > /sys/module/scsi_mod/parameters/use_blk_mq
echo N > /sys/module/dm_mod/parameters/use_blk_mq
'struct dm_rq_target_io' would leak if a request is requeued before a
blk-mq clone is allocated (or fails to allocate). free_rq_tio()
wasn't being called.
kmemleak reported:
unreferenced object 0xffff8800b90b98c0 (size 112):
comm "kworker/7:1H", pid 5692, jiffies
4295056109 (age 78.589s)
hex dump (first 32 bytes):
00 d0 5c 2c 03 88 ff ff 40 00 bf 01 00 c9 ff ff ..\,....@.......
e0 d9 b1 34 00 88 ff ff 00 00 00 00 00 00 00 00 ...4............
backtrace:
[<
ffffffff81672b6e>] kmemleak_alloc+0x4e/0xb0
[<
ffffffff811dbb63>] kmem_cache_alloc+0xc3/0x1e0
[<
ffffffff8117eae5>] mempool_alloc_slab+0x15/0x20
[<
ffffffff8117ec1e>] mempool_alloc+0x6e/0x170
[<
ffffffffa00029ac>] dm_old_prep_fn+0x3c/0x180 [dm_mod]
[<
ffffffff812fbd78>] blk_peek_request+0x168/0x290
[<
ffffffffa0003e62>] dm_request_fn+0xb2/0x1b0 [dm_mod]
[<
ffffffff812f66e3>] __blk_run_queue+0x33/0x40
[<
ffffffff812f9585>] blk_delay_work+0x25/0x40
[<
ffffffff81096fff>] process_one_work+0x14f/0x3d0
[<
ffffffff81097715>] worker_thread+0x125/0x4b0
[<
ffffffff8109ce88>] kthread+0xd8/0xf0
[<
ffffffff8167cb8f>] ret_from_fork+0x3f/0x70
[<
ffffffffffffffff>] 0xffffffffffffffff
crash> struct -o dm_rq_target_io
struct dm_rq_target_io {
...
}
SIZE: 112
Fixes:
e5863d9ad7 ("dm: allocate requests in target when stacking on blk-mq devices")
Cc: stable@vger.kernel.org # 4.0+
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Gerhard Uttenthaler [Tue, 22 Dec 2015 16:29:16 +0000 (17:29 +0100)]
can: ems_usb: Fix possible tx overflow
[ Upstream commit
90cfde46586d2286488d8ed636929e936c0c9ab2 ]
This patch fixes the problem that more CAN messages could be sent to the
interface as could be send on the CAN bus. This was more likely for slow baud
rates. The sleeping _start_xmit was woken up in the _write_bulk_callback. Under
heavy TX load this produced another bulk transfer without checking the
free_slots variable and hence caused the overflow in the interface.
Signed-off-by: Gerhard Uttenthaler <uttenthaler@ems-wuensche.com>
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>
Lisa Du [Wed, 17 Feb 2016 01:32:52 +0000 (09:32 +0800)]
drivers: android: correct the size of struct binder_uintptr_t for BC_DEAD_BINDER_DONE
[ Upstream commit
7a64cd887fdb97f074c3fda03bee0bfb9faceac3 ]
There's one point was missed in the patch commit
da49889deb34 ("staging:
binder: Support concurrent 32 bit and 64 bit processes."). When configure
BINDER_IPC_32BIT, the size of binder_uintptr_t was 32bits, but size of
void * is 64bit on 64bit system. Correct it here.
Signed-off-by: Lisa Du <cldu@marvell.com>
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Fixes:
da49889deb34 ("staging: binder: Support concurrent 32 bit and 64 bit processes.")
Cc: <stable@vger.kernel.org>
Acked-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Nishanth Menon [Sat, 20 Feb 2016 00:09:51 +0000 (18:09 -0600)]
hwmon: (gpio-fan) Remove un-necessary speed_index lookup for thermal hook
[ Upstream commit
000e0949148382c4962489593a2f05504c2a6771 ]
Thermal hook gpio_fan_get_cur_state is only interested in knowing
the current speed index that was setup in the system, this is
already available as part of fan_data->speed_index which is always
set by set_fan_speed. Using get_fan_speed_index is useful when we
have no idea about the fan speed configuration (for example during
fan_ctrl_init).
When thermal framework invokes
gpio_fan_get_cur_state=>get_fan_speed_index via gpio_fan_get_cur_state
especially in a polled configuration for thermal governor, we
basically hog the i2c interface to the extent that other functions
fail to get any traffic out :(.
Instead, just provide the last state set in the driver - since the gpio
fan driver is responsible for the fan state immaterial of override, the
fan_data->speed_index should accurately reflect the state.
Fixes:
b5cf88e46bad ("(gpio-fan): Add thermal control hooks")
Reported-by: Tony Lindgren <tony@atomide.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Eduardo Valentin <edubezval@gmail.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Cc: stable@vger.kernel.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Peter Rosin [Thu, 18 Feb 2016 13:07:52 +0000 (14:07 +0100)]
hwmon: (ads1015) Handle negative conversion values correctly
[ Upstream commit
acc146943957d7418a6846f06e029b2c5e87e0d5 ]
Make the divisor signed as DIV_ROUND_CLOSEST is undefined for negative
dividends when the divisor is unsigned.
Signed-off-by: Peter Rosin <peda@axentia.se>
Cc: stable@vger.kernel.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Alexandra Yates [Thu, 18 Feb 2016 03:36:20 +0000 (19:36 -0800)]
Adding Intel Lewisburg device IDs for SATA
[ Upstream commit
f5bdd66c705484b4bc77eb914be15c1b7881fae7 ]
This patch complements the list of device IDs previously
added for lewisburg sata.
Signed-off-by: Alexandra Yates <alexandra.yates@linux.intel.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Alexandra Yates [Tue, 3 Nov 2015 22:14:18 +0000 (14:14 -0800)]
ahci: add new Intel device IDs
[ Upstream commit
56e74338a535cbcc2f2da08b1ea1a92920194364 ]
Adding Intel codename Lewisburg platform device IDs for SATA.
Signed-off-by: Alexandra Yates <alexandra.yates@linux.intel.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Alexandra Yates [Mon, 16 Nov 2015 16:22:16 +0000 (11:22 -0500)]
ahci: Order SATA device IDs for codename Lewisburg
[ Upstream commit
4d92f0099a06ef0e36c7673f7c090f1a448b2d1b ]
This change was to preserve the ascending order of device IDs.
There was an exception with the first two Lewisburg device IDs to
keep all device IDs of the same kind grouped by code name.
Signed-off-by: Alexandra Yates <alexandra.yates@linux.intel.com>
signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Bjørn Mork [Fri, 12 Feb 2016 15:40:00 +0000 (16:40 +0100)]
USB: option: add "4G LTE usb-modem U901"
[ Upstream commit
d061c1caa31d4d9792cfe48a2c6b309a0e01ef46 ]
Thomas reports:
T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 4 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=05c6 ProdID=6001 Rev=00.00
S: Manufacturer=USB Modem
S: Product=USB Modem
S: SerialNumber=
1234567890ABCDEF
C: #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
I: If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
Cc: <stable@vger.kernel.org>
Reported-by: Thomas Schäfer <tschaefer@t-online.de>
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>
Ken Lin [Mon, 1 Feb 2016 19:57:25 +0000 (14:57 -0500)]
USB: cp210x: add IDs for GE B650V3 and B850V3 boards
[ Upstream commit
6627ae19385283b89356a199d7f03c75ba35fb29 ]
Add USB ID for cp2104/5 devices on GE B650v3 and B850v3 boards.
Signed-off-by: Ken Lin <ken.lin@advantech.com.tw>
Signed-off-by: Akshay Bhat <akshay.bhat@timesys.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Andrey Skvortsov [Thu, 28 Jan 2016 21:07:30 +0000 (00:07 +0300)]
USB: option: add support for SIM7100E
[ Upstream commit
3158a8d416f4e1b79dcc867d67cb50013140772c ]
$ lsusb:
Bus 001 Device 101: ID 1e0e:9001 Qualcomm / Option
$ usb-devices:
T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=101 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 2
P: Vendor=1e0e ProdID=9001 Rev= 2.32
S: Manufacturer=SimTech, Incorporated
S: Product=SimTech, Incorporated
S: SerialNumber=
0123456789ABCDEF
C:* #Ifs= 7 Cfg#= 1 Atr=80 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
I:* If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
The last interface (6) is used for Android Composite ADB interface.
Serial port layout:
0: QCDM/DIAG
1: NMEA
2: AT
3: AT/PPP
4: audio
Signed-off-by: Andrey Skvortsov <andrej.skvortzov@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>
Benjamin Coddington [Wed, 17 Feb 2016 15:41:41 +0000 (10:41 -0500)]
NFSv4: Fix a dentry leak on alias use
[ Upstream commit
d9dfd8d741683347ee159d25f5b50c346a0df557 ]
In the case where d_add_unique() finds an appropriate alias to use it will
have already incremented the reference count. An additional dget() to swap
the open context's dentry is unnecessary and will leak a reference.
Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
Fixes:
275bb307865a3 ("NFSv4: Move dentry instantiation into the NFSv4-...")
Cc: stable@vger.kernel.org # 3.10+
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
John Youn [Wed, 17 Feb 2016 04:10:53 +0000 (20:10 -0800)]
usb: dwc3: Fix assignment of EP transfer resources
[ Upstream commit
c450960187f45d4260db87c7dd4fc0bceb5565d8 ]
The assignement of EP transfer resources was not handled properly in the
dwc3 driver. Commit
aebda6187181 ("usb: dwc3: Reset the transfer
resource index on SET_INTERFACE") previously fixed one aspect of this
where resources may be exhausted with multiple calls to SET_INTERFACE.
However, it introduced an issue where composite devices with multiple
interfaces can be assigned the same transfer resources for different
endpoints. This patch solves both issues.
The assignment of transfer resources cannot perfectly follow the data
book due to the fact that the controller driver does not have all
knowledge of the configuration in advance. It is given this information
piecemeal by the composite gadget framework after every
SET_CONFIGURATION and SET_INTERFACE. Trying to follow the databook
programming model in this scenario can cause errors. For two reasons:
1) The databook says to do DEPSTARTCFG for every SET_CONFIGURATION and
SET_INTERFACE (8.1.5). This is incorrect in the scenario of multiple
interfaces.
2) The databook does not mention doing more DEPXFERCFG for new endpoint
on alt setting (8.1.6).
The following simplified method is used instead:
All hardware endpoints can be assigned a transfer resource and this
setting will stay persistent until either a core reset or hibernation.
So whenever we do a DEPSTARTCFG(0) we can go ahead and do DEPXFERCFG for
every hardware endpoint as well. We are guaranteed that there are as
many transfer resources as endpoints.
This patch triggers off of the calling dwc3_gadget_start_config() for
EP0-out, which always happens first, and which should only happen in one
of the above conditions.
Fixes:
aebda6187181 ("usb: dwc3: Reset the transfer resource index on SET_INTERFACE")
Cc: <stable@vger.kernel.org> # v3.2+
Reported-by: Ravi Babu <ravibabu@ti.com>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Hans Verkuil [Wed, 10 Feb 2016 10:09:10 +0000 (08:09 -0200)]
[media] adv7604: fix tx 5v detect regression
[ Upstream commit
0ba4581c84cfb39fd527f6b3457f1c97f6356c04 ]
The 5 volt detect functionality broke in 3.14: the code reads IO register 0x70
again after it has already been cleared. Instead it should use the cached
irq_reg_0x70 value and the io_write to 0x71 to clear 0x70 can be dropped since
this has already been done.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Cc: <stable@vger.kernel.org> # for v3.14 and up
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Konrad Rzeszutek Wilk [Thu, 11 Feb 2016 21:10:26 +0000 (16:10 -0500)]
xen/pcifront: Fix mysterious crashes when NUMA locality information was extracted.
[ Upstream commit
4d8c8bd6f2062c9988817183a91fe2e623c8aa5e ]
Occasionaly PV guests would crash with:
pciback 0000:00:00.1: Xen PCI mapped GSI0 to IRQ16
BUG: unable to handle kernel paging request at
0000000d1a8c0be0
.. snip..
<
ffffffff8139ce1b>] find_next_bit+0xb/0x10
[<
ffffffff81387f22>] cpumask_next_and+0x22/0x40
[<
ffffffff813c1ef8>] pci_device_probe+0xb8/0x120
[<
ffffffff81529097>] ? driver_sysfs_add+0x77/0xa0
[<
ffffffff815293e4>] driver_probe_device+0x1a4/0x2d0
[<
ffffffff813c1ddd>] ? pci_match_device+0xdd/0x110
[<
ffffffff81529657>] __device_attach_driver+0xa7/0xb0
[<
ffffffff815295b0>] ? __driver_attach+0xa0/0xa0
[<
ffffffff81527622>] bus_for_each_drv+0x62/0x90
[<
ffffffff8152978d>] __device_attach+0xbd/0x110
[<
ffffffff815297fb>] device_attach+0xb/0x10
[<
ffffffff813b75ac>] pci_bus_add_device+0x3c/0x70
[<
ffffffff813b7618>] pci_bus_add_devices+0x38/0x80
[<
ffffffff813dc34e>] pcifront_scan_root+0x13e/0x1a0
[<
ffffffff817a0692>] pcifront_backend_changed+0x262/0x60b
[<
ffffffff814644c6>] ? xenbus_gather+0xd6/0x160
[<
ffffffff8120900f>] ? put_object+0x2f/0x50
[<
ffffffff81465c1d>] xenbus_otherend_changed+0x9d/0xa0
[<
ffffffff814678ee>] backend_changed+0xe/0x10
[<
ffffffff81463a28>] xenwatch_thread+0xc8/0x190
[<
ffffffff810f22f0>] ? woken_wake_function+0x10/0x10
which was the result of two things:
When we call pci_scan_root_bus we would pass in 'sd' (sysdata)
pointer which was an 'pcifront_sd' structure. However in the
pci_device_add it expects that the 'sd' is 'struct sysdata' and
sets the dev->node to what is in sd->node (offset 4):
set_dev_node(&dev->dev, pcibus_to_node(bus));
__pcibus_to_node(const struct pci_bus *bus)
{
const struct pci_sysdata *sd = bus->sysdata;
return sd->node;
}
However our structure was pcifront_sd which had nothing at that
offset:
struct pcifront_sd {
int domain; /* 0 4 */
/* XXX 4 bytes hole, try to pack */
struct pcifront_device * pdev; /* 8 8 */
}
That is an hole - filled with garbage as we used kmalloc instead of
kzalloc (the second problem).
This patch fixes the issue by:
1) Use kzalloc to initialize to a well known state.
2) Put 'struct pci_sysdata' at the start of 'pcifront_sd'. That
way access to the 'node' will access the right offset.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: <stable@vger.kernel.org>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Konrad Rzeszutek Wilk [Thu, 11 Feb 2016 21:10:23 +0000 (16:10 -0500)]
xen/pciback: Check PF instead of VF for PCI_COMMAND_MEMORY
[ Upstream commit
d52a24819677bbb45eb1ce93a42daa1ae6c4d61d ]
commit
8d47065f7d1980dde52abb874b301054f3013602 upstream.
Commit
408fb0e5aa7fda0059db282ff58c3b2a4278baa0 (xen/pciback: Don't
allow MSI-X ops if PCI_COMMAND_MEMORY is not set) prevented enabling
MSI-X on passed-through virtual functions, because it checked the VF
for PCI_COMMAND_MEMORY but this is not a valid bit for VFs.
Instead, check the physical function for PCI_COMMAND_MEMORY.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Konrad Rzeszutek Wilk [Mon, 2 Nov 2015 23:13:27 +0000 (18:13 -0500)]
xen/pciback: Don't allow MSI-X ops if PCI_COMMAND_MEMORY is not set.
[ Upstream commit
408fb0e5aa7fda0059db282ff58c3b2a4278baa0 ]
commit
f598282f51 ("PCI: Fix the NIU MSI-X problem in a better way")
teaches us that dealing with MSI-X can be troublesome.
Further checks in the MSI-X architecture shows that if the
PCI_COMMAND_MEMORY bit is turned of in the PCI_COMMAND we
may not be able to access the BAR (since they are memory regions).
Since the MSI-X tables are located in there.. that can lead
to us causing PCIe errors. Inhibit us performing any
operation on the MSI-X unless the MEMORY bit is set.
Note that Xen hypervisor with:
"x86/MSI-X: access MSI-X table only after having enabled MSI-X"
will return:
xen_pciback: 0000:0a:00.1: error -6 enabling MSI-X for guest 3!
When the generic MSI code tries to setup the PIRQ without
MEMORY bit set. Which means with later versions of Xen
(4.6) this patch is not neccessary.
This is part of XSA-157
CC: stable@vger.kernel.org
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Konrad Rzeszutek Wilk [Mon, 2 Nov 2015 23:07:44 +0000 (18:07 -0500)]
xen/pciback: Return error on XEN_PCI_OP_enable_msix when device has MSI or MSI-X enabled
[ Upstream commit
5e0ce1455c09dd61d029b8ad45d82e1ac0b6c4c9 ]
The guest sequence of:
a) XEN_PCI_OP_enable_msix
b) XEN_PCI_OP_enable_msix
results in hitting an NULL pointer due to using freed pointers.
The device passed in the guest MUST have MSI-X capability.
The a) constructs and SysFS representation of MSI and MSI groups.
The b) adds a second set of them but adding in to SysFS fails (duplicate entry).
'populate_msi_sysfs' frees the newly allocated msi_irq_groups (note that
in a) pdev->msi_irq_groups is still set) and also free's ALL of the
MSI-X entries of the device (the ones allocated in step a) and b)).
The unwind code: 'free_msi_irqs' deletes all the entries and tries to
delete the pdev->msi_irq_groups (which hasn't been set to NULL).
However the pointers in the SysFS are already freed and we hit an
NULL pointer further on when 'strlen' is attempted on a freed pointer.
The patch adds a simple check in the XEN_PCI_OP_enable_msix to guard
against that. The check for msi_enabled is not stricly neccessary.
This is part of XSA-157
CC: stable@vger.kernel.org
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Konrad Rzeszutek Wilk [Thu, 11 Feb 2016 21:10:24 +0000 (16:10 -0500)]
xen/pciback: Save the number of MSI-X entries to be copied later.
[ Upstream commit
4cf5aa2ffe17403385d75a5b1d9d97071500ea18 ]
commit
d159457b84395927b5a52adb72f748dd089ad5e5 upstream.
Commit
8135cf8b092723dbfcc611fe6fdcb3a36c9951c5 (xen/pciback: Save
xen_pci_op commands before processing it) broke enabling MSI-X because
it would never copy the resulting vectors into the response. The
number of vectors requested was being overwritten by the return value
(typically zero for success).
Save the number of vectors before processing the op, so the correct
number of vectors are copied afterwards.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>