linux-stable.git/include, branch v3.12.20

libata/ahci: accommodate tag ordered controllers

2014-05-15T07:56:00+00:00

commit 8a4aeec8d2d6a3edeffbdfae451cdf05cbf0fefd upstream.

The AHCI spec allows implementations to issue commands in tag order
rather than FIFO order:

	5.3.2.12 P:SelectCmd
	HBA sets pSlotLoc = (pSlotLoc + 1) mod (CAP.NCS + 1)
	or HBA selects the command to issue that has had the
	PxCI bit set to '1' longer than any other command
	pending to be issued.

The result is that commands posted sequentially (time-wise) may play out
of sequence when issued by hardware.

This behavior has likely been hidden by drives that arrange for commands
to complete in issue order.  However, it appears recent drives (two from
different vendors that we have found so far) inflict out-of-order
completions as a matter of course.  So, we need to take care to maintain
ordered submission, otherwise we risk triggering a drive to fall out of
sequential-io automation and back to random-io processing, which incurs
large latency and degrades throughput.

This issue was found in simple benchmarks where QD=2 seq-write
performance was 30-50% *greater* than QD=32 seq-write performance.

Tagging for -stable and making the change globally since it has a low
risk-to-reward ratio.  Also, word is that recent versions of an unnamed
OS also does it this way now.  So, drives in the field are already
experienced with this tag ordering scheme.

Cc: Dave Jiang 
Cc: Ed Ciechanowski 
Reviewed-by: Matthew Wilcox 
Signed-off-by: Dan Williams 
Signed-off-by: Tejun Heo 
Signed-off-by: Jiri Slaby

xattr: guard against simultaneous glibc header inclusion

2014-05-15T07:55:38+00:00

commit ea1a8217b06b41b31a2b60b0b83f75c77ef9c873 upstream.

If the glibc xattr.h header is included after the uapi header,
compilation fails due to an enum re-using a #define from the uapi
header.

Protect against this by guarding the define and enum inclusions against
each other.

(See https://lists.debian.org/debian-glibc/2014/03/msg00029.html
and https://sourceware.org/glibc/wiki/Synchronizing_Headers
for more information.)

Signed-off-by: Serge Hallyn 
Cc: Andrew Morton 
Cc: Allan McRae 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Jiri Slaby

media: videodev2.h: add parenthesis around macro arguments

2014-05-15T07:55:25+00:00

commit aee786acfc0a12bcd37a1c60f3198fb25cf7181a upstream.

bt->width should be (bt)->width, and same for the other fields.

Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Jiri Slaby

nfsd: check passed socket's net matches NFSd superblock's one

2014-05-15T07:55:08+00:00

commit 3064639423c48d6e0eb9ecc27c512a58e38c6c57 upstream.

There could be a case, when NFSd file system is mounted in network, different
to socket's one, like below:

"ip netns exec" creates new network and mount namespace, which duplicates NFSd
mount point, created in init_net context. And thus NFS server stop in nested
network context leads to RPCBIND client destruction in init_net.
Then, on NFSd start in nested network context, rpc.nfsd process creates socket
in nested net and passes it into "write_ports", which leads to RPCBIND sockets
creation in init_net context because of the same reason (NFSd monut point was
created in init_net context). An attempt to register passed socket in nested
net leads to panic, because no RPCBIND client present in nexted network
namespace.

This patch add check that passed socket's net matches NFSd superblock's one.
And returns -EINVAL error to user psace otherwise.

v2: Put socket on exit.

Reported-by: Weng Meiling 
Signed-off-by: Stanislav Kinsbursky 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Jiri Slaby

Drivers: hv: vmbus: Negotiate version 3.0 when running on ws2012r2 hosts

2014-05-15T07:54:26+00:00

commit 03367ef5ea811475187a0732aada068919e14d61 upstream.

Only ws2012r2 hosts support the ability to reconnect to the host on VMBUS.
This functionality is needed by kexec in Linux. To use this functionality
we need to negotiate version 3.0 of the VMBUS protocol.

This patch has been backported to apply against the 3.12 stable tree.

Signed-off-by: K. Y. Srinivasan 
Cc:         [3.9+]
Signed-off-by: Jiri Slaby

Drivers: hv: vmbus: Specify the target CPU that should receive notification

2014-05-15T07:49:12+00:00

commit e28bab4828354583bb66ac09021ca69b341a7db4 upstream.

During the initial VMBUS connect phase, starting with WS2012 R2, we should
specify the VPCU in the guest that should receive the notification. Fix this
issue. This fix is required to properly connect to the host in the kexeced
kernel.

Signed-off-by: K. Y. Srinivasan 
Cc:         [3.9+]
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Jiri Slaby

tty: Fix low_latency BUG

2014-05-05T12:24:38+00:00

commit a9c3f68f3cd8d55f809fbdb0c138ed061ea1bd25 upstream.

The user-settable knob, low_latency, has been the source of
several BUG reports which stem from flush_to_ldisc() running
in interrupt context. Since 3.12, which added several sleeping
locks (termios_rwsem and buf->lock) to the input processing path,
the frequency of these BUG reports has increased.

Note that changes in 3.12 did not introduce this regression;
sleeping locks were first added to the input processing path
with the removal of the BKL from N_TTY in commit
a88a69c91256418c5907c2f1f8a0ec0a36f9e6cc,
'n_tty: Fix loss of echoed characters and remove bkl from n_tty'
and later in commit 38db89799bdf11625a831c5af33938dcb11908b6,
'tty: throttling race fix'. Since those changes, executing
flush_to_ldisc() in interrupt_context (ie, low_latency set), is unsafe.

However, since most devices do not validate if the low_latency
setting is appropriate for the context (process or interrupt) in
which they receive data, some reports are due to misconfiguration.
Further, serial dma devices for which dma fails, resort to
interrupt receiving as a backup without resetting low_latency.

Historically, low_latency was used to force wake-up the reading
process rather than wait for the next scheduler tick. The
effect was to trim multiple milliseconds of latency from
when the process would receive new data.

Recent tests [1] have shown that the reading process now receives
data with only 10's of microseconds latency without low_latency set.

Remove the low_latency rx steering from tty_flip_buffer_push();
however, leave the knob as an optional hint to drivers that can
tune their rx fifos and such like. Cleanup stale code comments
regarding low_latency.

[1] https://lkml.org/lkml/2014/2/20/434

"Yay.. thats an annoying historical pain in the butt gone."
	-- Alan Cox

Reported-by: Beat Bolli 
Reported-by: Pavel Roskin 
Acked-by: David Sterba 
Cc: Grant Edwards 
Cc: Stanislaw Gruszka 
Cc: Hal Murray 
Signed-off-by: Peter Hurley 
Signed-off-by: Alan Cox 
Signed-off-by: Jiri Slaby

bdi: avoid oops on device removal

2014-05-05T11:36:28+00:00

commit 5acda9d12dcf1ad0d9a5a2a7c646de3472fa7555 upstream.

After commit 839a8e8660b6 ("writeback: replace custom worker pool
implementation with unbound workqueue") when device is removed while we
are writing to it we crash in bdi_writeback_workfn() ->
set_worker_desc() because bdi->dev is NULL.

This can happen because even though bdi_unregister() cancels all pending
flushing work, nothing really prevents new ones from being queued from
balance_dirty_pages() or other places.

Fix the problem by clearing BDI_registered bit in bdi_unregister() and
checking it before scheduling of any flushing work.

Fixes: 839a8e8660b6777e7fe4e80af1a048aebe2b5977

Reviewed-by: Tejun Heo 
Signed-off-by: Jan Kara 
Cc: Derek Basehore 
Cc: Jens Axboe 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Jiri Slaby

printk: pr_debug_ratelimited: check state first to reduce "callbacks suppressed" messages

2014-05-05T09:17:02+00:00

commit 29fc2bc75393864bbc9b90a7a13a0d0e11c6f41e upstream.

pr_debug_ratelimited should be coded similarly to dev_dbg_ratelimited
to reduce the "callbacks suppressed" messages.

Add #include  to printk.h. Unfortunately, this
new #include must be after the prototype/declaration of function printk.

It may be better to split out these _ratelimited declarations into
a separate file one day.

Any use of these pr__ratelimited functions must also have another
specific #include .  Most users have this done indirectly
via #include 

printk.h may not #include  as it causes circular
dependencies and compilation failures.

Signed-off-by: Joe Perches 
Tested-by: Krzysztof Mazur 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Jiri Slaby

usbnet: include wait queue head in device structure

2014-04-18T09:07:13+00:00

[ Upstream commit 14a0d635d18d0fb552dcc979d6d25106e6541f2e ]

This fixes a race which happens by freeing an object on the stack.
Quoting Julius:
> The issue is
> that it calls usbnet_terminate_urbs() before that, which temporarily
> installs a waitqueue in dev->wait in order to be able to wait on the
> tasklet to run and finish up some queues. The waiting itself looks
> okay, but the access to 'dev->wait' is totally unprotected and can
> race arbitrarily. I think in this case usbnet_bh() managed to succeed
> it's dev->wait check just before usbnet_terminate_urbs() sets it back
> to NULL. The latter then finishes and the waitqueue_t structure on its
> stack gets overwritten by other functions halfway through the
> wake_up() call in usbnet_bh().

The fix is to just not allocate the data structure on the stack.
As dev->wait is abused as a flag it also takes a runtime PM change
to fix this bug.

Signed-off-by: Oliver Neukum 
Reported-by: Grant Grundler 
Tested-by: Grant Grundler 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby