linux.git/include, branch v3.12.11

percpu_ida: Make percpu_ida_alloc + callers accept task state bitmask

2014-02-13T21:50:19+00:00

commit 6f6b5d1ec56acdeab0503d2b823f6f88a0af493e upstream.

This patch changes percpu_ida_alloc() + callers to accept task state
bitmask for prepare_to_wait() for code like target/iscsi that needs
it for interruptible sleep, that is provided in a subsequent patch.

It now expects TASK_UNINTERRUPTIBLE when the caller is able to sleep
waiting for a new tag, or TASK_RUNNING when the caller cannot sleep,
and is forced to return a negative value when no tags are available.

v2 changes:
  - Include blk-mq + tcm_fc + vhost/scsi + target/iscsi changes
  - Drop signal_pending_state() call
v3 changes:
  - Only call prepare_to_wait() + finish_wait() when != TASK_RUNNING
    (PeterZ)

Reported-by: Linus Torvalds 
Cc: Linus Torvalds 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Jens Axboe 
Signed-off-by: Kent Overstreet 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Greg Kroah-Hartman

ore: Fix wrong math in allocation of per device BIO

2014-02-13T21:50:14+00:00

commit aad560b7f63b495f48a7232fd086c5913a676e6f upstream.

At IO preparation we calculate the max pages at each device and
allocate a BIO per device of that size. The calculation was wrong
on some unaligned corner cases offset/length combination and would
make prepare return with -ENOMEM. This would be bad for pnfs-objects
that would in that case IO through MDS. And fatal for exofs were it
would fail writes with EIO.

Fix it by doing the proper math, that will work in all cases. (I
ran a test with all possible offset/length combinations this time
round).

Also when reading we do not need to allocate for the parity units
since we jump over them.

Also lower the max_io_length to take into account the parity pages
so not to allocate BIOs bigger than PAGE_SIZE

Signed-off-by: Boaz Harrosh 
Signed-off-by: Greg Kroah-Hartman

fs/compat: fix lookup_dcookie() parameter handling

2014-02-13T21:50:14+00:00

commit d8d14bd09cddbaf0168d61af638455a26bd027ff upstream.

Commit d5dc77bfeeab ("consolidate compat lookup_dcookie()") coverted all
architectures to the new compat_sys_lookup_dcookie() syscall.

The "len" paramater of the new compat syscall must have the type
compat_size_t in order to enforce zero extension for architectures where
the ABI requires that the caller of a function performed zero and/or
sign extension to 64 bit of all parameters.

Signed-off-by: Heiko Carstens 
Cc: Al Viro 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Hendrik Brueckner 
Cc: Martin Schwidefsky 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

fs/compat: fix parameter handling for compat readv/writev syscalls

2014-02-13T21:50:14+00:00

commit dfd948e32af2e7b28bcd7a490c0a30d4b8df2a36 upstream.

We got a report that the pwritev syscall does not work correctly in
compat mode on s390.

It turned out that with commit 72ec35163f9f ("switch compat readv/writev
variants to COMPAT_SYSCALL_DEFINE") we lost the zero extension of a
couple of syscall parameters because the some parameter types haven't
been converted from unsigned long to compat_ulong_t.

This is needed for architectures where the ABI requires that the caller
of a function performed zero and/or sign extension to 64 bit of all
parameters.

Signed-off-by: Heiko Carstens 
Cc: Al Viro 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Hendrik Brueckner 
Cc: Martin Schwidefsky 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

mm/page-writeback.c: do not count anon pages as dirtyable memory

2014-02-13T21:50:11+00:00

commit a1c3bfb2f67ef766de03f1f56bdfff9c8595ab14 upstream.

The VM is currently heavily tuned to avoid swapping.  Whether that is
good or bad is a separate discussion, but as long as the VM won't swap
to make room for dirty cache, we can not consider anonymous pages when
calculating the amount of dirtyable memory, the baseline to which
dirty_background_ratio and dirty_ratio are applied.

A simple workload that occupies a significant size (40+%, depending on
memory layout, storage speeds etc.) of memory with anon/tmpfs pages and
uses the remainder for a streaming writer demonstrates this problem.  In
that case, the actual cache pages are a small fraction of what is
considered dirtyable overall, which results in an relatively large
portion of the cache pages to be dirtied.  As kswapd starts rotating
these, random tasks enter direct reclaim and stall on IO.

Only consider free pages and file pages dirtyable.

Signed-off-by: Johannes Weiner 
Reported-by: Tejun Heo 
Tested-by: Tejun Heo 
Reviewed-by: Rik van Riel 
Cc: Mel Gorman 
Cc: Wu Fengguang 
Reviewed-by: Michal Hocko 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

xen/pvhvm: If xen_platform_pci=0 is set don't blow up (v4).

2014-02-13T21:50:10+00:00

commit 51c71a3bbaca868043cc45b3ad3786dd48a90235 upstream.

The user has the option of disabling the platform driver:
00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)

which is used to unplug the emulated drivers (IDE, Realtek 8169, etc)
and allow the PV drivers to take over. If the user wishes
to disable that they can set:

  xen_platform_pci=0
  (in the guest config file)

or
  xen_emul_unplug=never
  (on the Linux command line)

except it does not work properly. The PV drivers still try to
load and since the Xen platform driver is not run - and it
has not initialized the grant tables, most of the PV drivers
stumble upon:

input: Xen Virtual Keyboard as /devices/virtual/input/input5
input: Xen Virtual Pointer as /devices/virtual/input/input6M
------------[ cut here ]------------
kernel BUG at /home/konrad/ssd/konrad/linux/drivers/xen/grant-table.c:1206!
invalid opcode: 0000 [#1] SMP
Modules linked in: xen_kbdfront(+) xenfs xen_privcmd
CPU: 6 PID: 1389 Comm: modprobe Not tainted 3.13.0-rc1upstream-00021-ga6c892b-dirty #1
Hardware name: Xen HVM domU, BIOS 4.4-unstable 11/26/2013
RIP: 0010:[]  [] get_free_entries+0x2e0/0x300
Call Trace:
 [] ? evdev_connect+0x1e3/0x240
 [] gnttab_grant_foreign_access+0x2e/0x70
 [] xenkbd_connect_backend+0x41/0x290 [xen_kbdfront]
 [] xenkbd_probe+0x2f2/0x324 [xen_kbdfront]
 [] xenbus_dev_probe+0x77/0x130
 [] xenbus_frontend_dev_probe+0x47/0x50
 [] driver_probe_device+0x89/0x230
 [] __driver_attach+0x9b/0xa0
 [] ? driver_probe_device+0x230/0x230
 [] ? driver_probe_device+0x230/0x230
 [] bus_for_each_dev+0x8c/0xb0
 [] driver_attach+0x19/0x20
 [] bus_add_driver+0x1a0/0x220
 [] driver_register+0x5f/0xf0
 [] xenbus_register_driver_common+0x15/0x20
 [] xenbus_register_frontend+0x23/0x40
 [] ? 0xffffffffa0014fff
 [] xenkbd_init+0x2b/0x1000 [xen_kbdfront]
 [] do_one_initcall+0x49/0x170

.. snip..

which is hardly nice. This patch fixes this by having each
PV driver check for:
 - if running in PV, then it is fine to execute (as that is their
   native environment).
 - if running in HVM, check if user wanted 'xen_emul_unplug=never',
   in which case bail out and don't load any PV drivers.
 - if running in HVM, and if PCI device 5853:0001 (xen_platform_pci)
   does not exist, then bail out and not load PV drivers.
 - (v2) if running in HVM, and if the user wanted 'xen_emul_unplug=ide-disks',
   then bail out for all PV devices _except_ the block one.
   Ditto for the network one ('nics').
 - (v2) if running in HVM, and if the user wanted 'xen_emul_unplug=unnecessary'
   then load block PV driver, and also setup the legacy IDE paths.
   In (v3) make it actually load PV drivers.

Reported-by: Sander Eikelenboom 
Reported-and-Tested-by: Fabio Fantoni 
Signed-off-by: Konrad Rzeszutek Wilk 
[v2: Add extra logic to handle the myrid ways 'xen_emul_unplug'
can be used per Ian and Stefano suggestion]
[v3: Make the unnecessary case work properly]
[v4: s/disks/ide-disks/ spotted by Fabio]
Reviewed-by: Stefano Stabellini 
Acked-by: Bjorn Helgaas  [for PCI parts]
Signed-off-by: Greg Kroah-Hartman

audit: correct a type mismatch in audit_syscall_exit()

2014-02-13T21:50:10+00:00

commit 06bdadd7634551cfe8ce071fe44d0311b3033d9e upstream.

audit_syscall_exit() saves a result of regs_return_value() in intermediate
"int" variable and passes it to __audit_syscall_exit(), which expects its
second argument as a "long" value.  This will result in truncating the
value returned by a system call and making a wrong audit record.

I don't know why gcc compiler doesn't complain about this, but anyway it
causes a problem at runtime on arm64 (and probably most 64-bit archs).

Signed-off-by: AKASHI Takahiro 
Cc: Al Viro 
Cc: Eric Paris 
Signed-off-by: Andrew Morton 
Signed-off-by: Eric Paris 
Signed-off-by: Greg Kroah-Hartman

fuse: fix pipe_buf_operations

2014-02-13T21:50:10+00:00

commit 28a625cbc2a14f17b83e47ef907b2658576a32aa upstream.

Having this struct in module memory could Oops when if the module is
unloaded while the buffer still persists in a pipe.

Since sock_pipe_buf_ops is essentially the same as fuse_dev_pipe_buf_steal
merge them into nosteal_pipe_buf_ops (this is the same as
default_pipe_buf_ops except stealing the page from the buffer is not
allowed).

Reported-by: Al Viro 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman

libata: disable LPM for some WD SATA-I devices

2014-02-06T19:22:19+00:00

commit ecd75ad514d73efc1bbcc5f10a13566c3ace5f53 upstream.

For some reason, some early WD drives spin up and down drives
erratically when the link is put into slumber mode which can reduce
the life expectancy of the device significantly.  Unfortunately, we
don't have full list of devices and given the nature of the issue it'd
be better to err on the side of false positives than the other way
around.  Let's disable LPM on all WD devices which match one of the
known problematic model prefixes and are SATA-I.

As horkage list doesn't support matching SATA capabilities, this is
implemented as two horkages - WD_BROKEN_LPM and NOLPM.  The former is
set for the known prefixes and sets the latter if the matched device
is SATA-I.

Note that this isn't optimal as this disables all LPM operations and
partial link power state reportedly works fine on these; however, the
way LPM is implemented in libata makes it difficult to precisely map
libata LPM setting to specific link power state.  Well, these devices
are already fairly outdated.  Let's just disable whole LPM for now.

Signed-off-by: Tejun Heo 
Reported-and-tested-by: Nikos Barkas 
Reported-and-tested-by: Ioannis Barkas 
References: https://bugzilla.kernel.org/show_bug.cgi?id=57211
Signed-off-by: Greg Kroah-Hartman

usb: chipidea: add freescale imx28 special write register method

2014-02-06T19:22:14+00:00

commit ed8f8318d2ef3e5f9e4ddf79349508c116b68d7f upstream.

According to Freescale imx28 Errata, "ENGR119653 USB: ARM to USB
register error issue", All USB register write operations must
use the ARM SWP instruction. So, we implement special hw_write
and hw_test_and_clear for imx28.

Discussion for it at below:
http://marc.info/?l=linux-usb&m=137996395529294&w=2

This patch is needed for stable tree 3.11+.

Cc: robert.hodaszi@digi.com
Signed-off-by: Peter Chen 
Signed-off-by: Marc Kleine-Budde 
Tested-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman