linux-toradex.git/include, branch v3.12.42

arm/arm64: KVM: Require in-kernel vgic for the arch timers

2015-04-30T09:15:13+00:00

commit 05971120fca43e0357789a14b3386bb56eef2201 upstream.

It is curently possible to run a VM with architected timers support
without creating an in-kernel VGIC, which will result in interrupts from
the virtual timer going nowhere.

To address this issue, move the architected timers initialization to the
time when we run a VCPU for the first time, and then only initialize
(and enable) the architected timers if we have a properly created and
initialized in-kernel VGIC.

When injecting interrupts from the virtual timer to the vgic, the
current setup should ensure that this never calls an on-demand init of
the VGIC, which is the only call path that could return an error from
kvm_vgic_inject_irq(), so capture the return value and raise a warning
if there's an error there.

We also change the kvm_timer_init() function from returning an int to be
a void function, since the function always succeeds.

Reviewed-by: Marc Zyngier 
Signed-off-by: Christoffer Dall 
Signed-off-by: Shannon Zhao 
Signed-off-by: Jiri Slaby

ARM: KVM: fix non-VGIC compilation

2015-04-30T09:15:05+00:00

commit 6cbde8253a8143ada18ec0d1711230747a7c1934 upstream.

Add a stub for kvm_vgic_addr when compiling without
CONFIG_KVM_ARM_VGIC. The usefulness of this configurarion is extremely
doubtful, but let's fix it anyway (until we decide that we'll always
support a VGIC).

Reported-by: Michele Paolino 
Cc: Paolo Bonzini 
Cc: Christoffer Dall 
Signed-off-by: Marc Zyngier 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Shannon Zhao 
Signed-off-by: Jiri Slaby

nick kvfree() from apparmor

2015-04-27T17:59:54+00:00

commit 39f1f78d53b9bcbca91967380c5f0f2305a5c55f upstream.

too many places open-code it

Signed-off-by: Al Viro 
Signed-off-by: Jiri Slaby

Defer processing of REQ_PREEMPT requests for blocked devices

2015-04-22T06:58:38+00:00

commit bba0bdd7ad4713d82338bcd9b72d57e9335a664b upstream.

SCSI transport drivers and SCSI LLDs block a SCSI device if the
transport layer is not operational. This means that in this state
no requests should be processed, even if the REQ_PREEMPT flag has
been set. This patch avoids that a rescan shortly after a cable
pull sporadically triggers the following kernel oops:

BUG: unable to handle kernel paging request at ffffc9001a6bc084
IP: [] mlx4_ib_post_send+0xd2/0xb30 [mlx4_ib]
Process rescan-scsi-bus (pid: 9241, threadinfo ffff88053484a000, task ffff880534aae100)
Call Trace:
 [] srp_post_send+0x65/0x70 [ib_srp]
 [] srp_queuecommand+0x1cf/0x3e0 [ib_srp]
 [] scsi_dispatch_cmd+0x101/0x280 [scsi_mod]
 [] scsi_request_fn+0x411/0x4d0 [scsi_mod]
 [] __blk_run_queue+0x27/0x30
 [] blk_execute_rq_nowait+0x82/0x110
 [] blk_execute_rq+0x62/0xf0
 [] scsi_execute+0xe8/0x190 [scsi_mod]
 [] scsi_execute_req+0xa3/0x130 [scsi_mod]
 [] scsi_probe_lun+0x17a/0x450 [scsi_mod]
 [] scsi_probe_and_add_lun+0x156/0x480 [scsi_mod]
 [] __scsi_scan_target+0xdf/0x1f0 [scsi_mod]
 [] scsi_scan_host_selected+0x183/0x1c0 [scsi_mod]
 [] scsi_scan+0xdb/0xe0 [scsi_mod]
 [] store_scan+0x13/0x20 [scsi_mod]
 [] sysfs_write_file+0xcb/0x160
 [] vfs_write+0xce/0x140
 [] sys_write+0x53/0xa0
 [] system_call_fastpath+0x16/0x1b
 [<00007f611c9d9300>] 0x7f611c9d92ff

Reported-by: Max Gurtuvoy 
Signed-off-by: Bart Van Assche 
Reviewed-by: Mike Christie 
Signed-off-by: James Bottomley 
Signed-off-by: Jiri Slaby

remove extra definitions of U32_MAX

2015-04-22T06:58:25+00:00

commit 04f9b74e4d96d349de12fdd4e6626af4a9f75e09 upstream.

Now that the definition is centralized in , the
definitions of U32_MAX (and related) elsewhere in the kernel can be
removed.

Signed-off-by: Alex Elder 
Acked-by: Sage Weil 
Acked-by: David S. Miller 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Jiri Slaby

kernel.h: define u8, s8, u32, etc. limits

2015-04-22T06:58:17+00:00

commit 89a0714106aac7309c7dfa0f004b39e1e89d2942 upstream.

Create constants that define the maximum and minimum values
representable by the kernel types u8, s8, u16, s16, and so on.

Signed-off-by: Alex Elder 
Cc: Sage Weil 
Cc: David Miller 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Jiri Slaby

conditionally define U32_MAX

2015-04-22T06:58:14+00:00

commit 77719536dc00f8fd8f5abe6dadbde5331c37f996 upstream.

The symbol U32_MAX is defined in several spots.  Change these
definitions to be conditional.  This is in preparation for the next
patch, which centralizes the definition in .

Signed-off-by: Alex Elder 
Cc: Sage Weil 
Cc: David Miller 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Jiri Slaby

net: fix sparse warning in sk_dst_set()

2015-04-09T12:13:51+00:00

commit 5925a0555bdaf0b396a84318cbc21ba085f6c0d3 upstream.

sk_dst_cache has __rcu annotation, so we need a cast to avoid
following sparse error :

include/net/sock.h:1774:19: warning: incorrect type in initializer (different address spaces)
include/net/sock.h:1774:19:    expected struct dst_entry [noderef] *__ret
include/net/sock.h:1774:19:    got struct dst_entry *dst

Signed-off-by: Eric Dumazet 
Reported-by: kbuild test robot 
Fixes: 7f502361531e ("ipv4: irq safe sk_dst_[re]set() and ipv4_sk_update_pmtu() fix")
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

NFS: Add attribute update barriers to nfs_setattr_update_inode()

2015-04-09T12:13:22+00:00

commit f044636d972246d451e06226cc1675d5da389762 upstream.

Ensure that other operations which raced with our setattr RPC call
cannot revert the file attribute changes that were made on the server.
To do so, we artificially bump the attribute generation counter on
the inode so that all calls to nfs_fattr_init() that precede ours
will be dropped.

The motivation for the patch came from Chuck Lever's reports of readaheads
racing with truncate operations and causing the file size to be reverted.

Reported-by: Chuck Lever 
Signed-off-by: Trond Myklebust 
Tested-by: Chuck Lever 
Acked-by: NeilBrown 
Signed-off-by: Jiri Slaby

workqueue: fix hang involving racing cancel[_delayed]_work_sync()'s for PREEMPT_NONE

2015-04-09T11:14:05+00:00

commit 8603e1b30027f943cc9c1eef2b291d42c3347af1 upstream.

cancel[_delayed]_work_sync() are implemented using
__cancel_work_timer() which grabs the PENDING bit using
try_to_grab_pending() and then flushes the work item with PENDING set
to prevent the on-going execution of the work item from requeueing
itself.

try_to_grab_pending() can always grab PENDING bit without blocking
except when someone else is doing the above flushing during
cancelation.  In that case, try_to_grab_pending() returns -ENOENT.  In
this case, __cancel_work_timer() currently invokes flush_work().  The
assumption is that the completion of the work item is what the other
canceling task would be waiting for too and thus waiting for the same
condition and retrying should allow forward progress without excessive
busy looping

Unfortunately, this doesn't work if preemption is disabled or the
latter task has real time priority.  Let's say task A just got woken
up from flush_work() by the completion of the target work item.  If,
before task A starts executing, task B gets scheduled and invokes
__cancel_work_timer() on the same work item, its try_to_grab_pending()
will return -ENOENT as the work item is still being canceled by task A
and flush_work() will also immediately return false as the work item
is no longer executing.  This puts task B in a busy loop possibly
preventing task A from executing and clearing the canceling state on
the work item leading to a hang.

task A			task B			worker

						executing work
__cancel_work_timer()
  try_to_grab_pending()
  set work CANCELING
  flush_work()
    block for work completion
						completion, wakes up A
			__cancel_work_timer()
			while (forever) {
			  try_to_grab_pending()
			    -ENOENT as work is being canceled
			  flush_work()
			    false as work is no longer executing
			}

This patch removes the possible hang by updating __cancel_work_timer()
to explicitly wait for clearing of CANCELING rather than invoking
flush_work() after try_to_grab_pending() fails with -ENOENT.

Link: http://lkml.kernel.org/g/20150206171156.GA8942@axis.com

v3: bit_waitqueue() can't be used for work items defined in vmalloc
    area.  Switched to custom wake function which matches the target
    work item and exclusive wait and wakeup.

v2: v1 used wake_up() on bit_waitqueue() which leads to NULL deref if
    the target bit waitqueue has wait_bit_queue's on it.  Use
    DEFINE_WAIT_BIT() and __wake_up_bit() instead.  Reported by Tomeu
    Vizoso.

Signed-off-by: Tejun Heo 
Reported-by: Rabin Vincent 
Cc: Tomeu Vizoso 
Tested-by: Jesper Nilsson 
Tested-by: Rabin Vincent 
Signed-off-by: Jiri Slaby