linux-stable.git, branch v3.4.111

Linux 3.4.111

2016-03-21T01:17:59+00:00

KVM: x86: move steal time initialization to vcpu entry time

2016-03-21T01:17:59+00:00

commit 7cae2bedcbd4680b155999655e49c27b9cf020fa upstream.

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 
Reviewed-by: David Matlack 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Zefan Li

dm btree remove: fix a bug when rebalancing nodes after removal

2016-03-21T01:17:58+00:00

commit 2871c69e025e8bc507651d5a9cf81a8a7da9d24b upstream.

Commit 4c7e309340ff ("dm btree remove: fix bug in redistribute3") wasn't
a complete fix for redistribute3().

The redistribute3 function takes 3 btree nodes and shares out the entries
evenly between them.  If the three nodes in total contained
(MAX_ENTRIES * 3) - 1 entries between them then this was erroneously getting
rebalanced as (MAX_ENTRIES - 1) on the left and right, and (MAX_ENTRIES + 1) in
the center.

Fix this issue by being more careful about calculating the target number
of entries for the left and right nodes.

Unit tested in userspace using this program:
https://github.com/jthornber/redistribute3-test/blob/master/redistribute3_t.c

Signed-off-by: Joe Thornber 
Signed-off-by: Mike Snitzer 
Signed-off-by: Zefan Li

usb: dwc3: Fix assignment of EP transfer resources

2016-03-21T01:17:58+00:00

commit c450960187f45d4260db87c7dd4fc0bceb5565d8 upstream.

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")
Reported-by: Ravi Babu 
Signed-off-by: John Youn 
Signed-off-by: Felipe Balbi 
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li

ALSA: usb-audio: Add a more accurate volume quirk for AudioQuest DragonFly

2016-03-21T01:17:58+00:00

commit 42e3121d90f42e57f6dbd6083dff2f57b3ec7daa upstream.

AudioQuest DragonFly DAC reports a volume control range of 0..50
(0x0000..0x0032) which in USB Audio means a range of 0 .. 0.2dB, which
is obviously incorrect and would cause software using the dB information
in e.g. volume sliders to have a massive volume difference in 100..102%
range.

Commit 2d1cb7f658fb ("ALSA: usb-audio: add dB range mapping for some
devices") added a dB range mapping for it with range 0..50 dB.

However, the actual volume mapping seems to be neither linear volume nor
linear dB scale, but instead quite close to the cubic mapping e.g.
alsamixer uses, with a range of approx. -53...0 dB.

Replace the previous quirk with a custom dB mapping based on some basic
output measurements, using a 10-item range TLV (which will still fit in
alsa-lib MAX_TLV_RANGE_SIZE).

Tested on AudioQuest DragonFly HW v1.2. The quirk is only applied if the
range is 0..50, so if this gets fixed/changed in later HW revisions it
will no longer be applied.

v2: incorporated Takashi Iwai's suggestion for the quirk application
method

Signed-off-by: Anssi Hannula 
Signed-off-by: Takashi Iwai 
[lizf: Backoported to 3.4: use dev_info() instead of usb_audio_info()]
Signed-off-by: Zefan Li

ALSA: tlv: add DECLARE_TLV_DB_RANGE()

2016-03-21T01:17:58+00:00

commit bf1d1c9b6179faa3bc32cee882462bc8eebde25d upstream.

Add a DECLARE_TLV_DB_RANGE() macro so that dB range information
can be specified without having to count the items manually for
TLV_DB_RANGE_HEAD().

Signed-off-by: Clemens Ladisch 
Signed-off-by: Takashi Iwai 
Signed-off-by: Zefan Li

ALSA: tlv: compute TLV_*_ITEM lengths automatically

2016-03-21T01:17:58+00:00

commit b5b9eb546762c4015c67c31364a6ec6f83fd2ada upstream.

Add helper macros with a little bit of preprocessor magic to
automatically compute the length of a TLV item.  This lets us avoid
having to compute this by hand, and will allow to use items that do
not use a fixed length.

Signed-off-by: Clemens Ladisch 
Signed-off-by: Takashi Iwai 
Signed-off-by: Zefan Li

x86/LDT: Print the real LDT base address

2016-03-21T01:17:57+00:00

commit 0d430e3fb3f7cdc13c0d22078b820f682821b45a upstream.

This was meant to print base address and entry count; make it do so
again.

Fixes: 37868fe113ff "x86/ldt: Make modify_ldt synchronous"
Signed-off-by: Jan Beulich 
Acked-by: Andy Lutomirski 
Link: http://lkml.kernel.org/r/56797D8402000078000C24F0@prv-mh.provo.novell.com
Signed-off-by: Thomas Gleixner 
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li

af_unix: Guard against other == sk in unix_dgram_sendmsg

2016-03-21T01:17:57+00:00

commit a5527dda344fff0514b7989ef7a755729769daa1 upstream.

The unix_dgram_sendmsg routine use the following test

if (unlikely(unix_peer(other) != sk && unix_recvq_full(other))) {

to determine if sk and other are in an n:1 association (either
established via connect or by using sendto to send messages to an
unrelated socket identified by address). This isn't correct as the
specified address could have been bound to the sending socket itself or
because this socket could have been connected to itself by the time of
the unix_peer_get but disconnected before the unix_state_lock(other). In
both cases, the if-block would be entered despite other == sk which
might either block the sender unintentionally or lead to trying to unlock
the same spin lock twice for a non-blocking send. Add a other != sk
check to guard against this.

Fixes: 7d267278a9ec ("unix: avoid use-after-free in ep_remove_wait_queue")
Reported-By: Philipp Hahn 
Signed-off-by: Rainer Weikusat 
Tested-by: Philipp Hahn 
Signed-off-by: David S. Miller 
Signed-off-by: Zefan Li

net: fix warnings in 'make htmldocs' by moving macro definition out of field declaration

2016-03-21T01:17:57+00:00

commit 7bbadd2d1009575dad675afc16650ebb5aa10612 upstream.

Docbook does not like the definition of macros inside a field declaration
and adds a warning. Move the definition out.

Fixes: 79462ad02e86180 ("net: add validation for the socket syscall protocol argument")
Reported-by: kbuild test robot 
Signed-off-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller 
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li