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

bus: mvebu: pass the coherency availability information at init time

2015-07-04T02:48:09+00:00

commit 5686a1e5aa436c49187a60052d5885fb1f541ce6 upstream.

Until now, the mvebu-mbus was guessing by itself whether hardware I/O
coherency was available or not by poking into the Device Tree to see
if the coherency fabric Device Tree node was present or not.

However, on some upcoming SoCs, the presence or absence of the
coherency fabric DT node isn't sufficient: in CONFIG_SMP, the
coherency can be enabled, but not in !CONFIG_SMP.

In order to clean this up, the mvebu_mbus_dt_init() function is
extended to get a boolean argument telling whether coherency is
enabled or not. Therefore, the logic to decide whether coherency is
available or not now belongs to the core SoC code instead of the
mvebu-mbus driver itself, which is much better.

Signed-off-by: Thomas Petazzoni
Link: https://lkml.kernel.org/r/1397483228-25625-4-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper

[ Greg Ungerer: back ported to linux-3.10.y
Back port necessary due to large code differences in affected files.
This change in combination with commit e553554536 ("ARM: mvebu: disable
I/O coherency on non-SMP situations on Armada 370/375/38x/XP") is
critical to the hardware I/O coherency being set correctly by both the
mbus driver and all peripheral hardware drivers. Without this change
drivers will incorrectly enable I/O coherency window attributes and
this causes rare unreliable system behavior including oops. ]

Signed-off-by: Greg Ungerer
Acked-by: Gregory CLEMENT
Signed-off-by: Greg Kroah-Hartman

include/linux/sched.h: don't use task->pid/tgid in same_thread_group/has_group_leader_pid

2015-07-04T02:48:08+00:00

commit e1403b8edf669ff49bbdf602cc97fefa2760cb15 upstream.

task_struct->pid/tgid should go away.

1. Change same_thread_group() to use task->signal for comparison.

2. Change has_group_leader_pid(task) to compare task_pid(task) with
   signal->leader_pid.

Signed-off-by: Oleg Nesterov 
Cc: Michal Hocko 
Cc: Sergey Dyasly 
Reviewed-by: "Eric W. Biederman" 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

get rid of s_files and files_lock

2015-07-04T02:48:08+00:00

commit eee5cc2702929fd41cce28058dc6d6717f723f87 upstream.

The only thing we need it for is alt-sysrq-r (emergency remount r/o)
and these days we can do just as well without going through the
list of files.

Signed-off-by: Al Viro 
[wangkai: backport to 3.10: adjust context]
Signed-off-by: Wang Kai 
Signed-off-by: Greg Kroah-Hartman

fput: turn "list_head delayed_fput_list" into llist_head

2015-07-04T02:48:08+00:00

commit 4f5e65a1cc90bbb15b9f6cdc362922af1bcc155a upstream.

fput() and delayed_fput() can use llist and avoid the locking.

This is unlikely path, it is not that this change can improve
the performance, but this way the code looks simpler.

Signed-off-by: Oleg Nesterov 
Suggested-by: Andrew Morton 
Cc: Al Viro 
Cc: Andrey Vagin 
Cc: "Eric W. Biederman" 
Cc: David Howells 
Cc: Huang Ying 
Cc: Peter Zijlstra 
Signed-off-by: Andrew Morton 
Signed-off-by: Al Viro 
Signed-off-by: Wang Kai 
Signed-off-by: Greg Kroah-Hartman

libata: Ignore spurious PHY event on LPM policy change

2015-06-06T06:19:58+00:00

commit 09c5b4803a80a5451d950d6a539d2eb311dc0fb1 upstream.

When the LPM policy is set to ATA_LPM_MAX_POWER, the device might
generate a spurious PHY event that cuases errors on the link.
Ignore this event if it occured within 10s after the policy change.

The timeout was chosen observing that on a Dell XPS13 9333 these
spurious events can occur up to roughly 6s after the policy change.

Link: http://lkml.kernel.org/g/3352987.ugV1Ipy7Z5@xps13
Signed-off-by: Gabriele Mazzotta 
Signed-off-by: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman

libata: Add helper to determine when PHY events should be ignored

2015-06-06T06:19:58+00:00

commit 8393b811f38acdf7fd8da2028708edad3e68ce1f upstream.

This is a preparation commit that will allow to add other criteria
according to which PHY events should be dropped.

Signed-off-by: Gabriele Mazzotta 
Signed-off-by: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman

revert "softirq: Add support for triggering softirq work on softirqs"

2015-05-17T16:51:33+00:00

commit fc21c0cff2f425891b28ff6fb6b03b325c977428 upstream.

This commit was incomplete in that code to remove items from the per-cpu
lists was missing and never acquired a user in the 5 years it has been in
the tree.  We're going to implement what it seems to try to archive in a
simpler way, and this code is in the way of doing so.

Signed-off-by: Christoph Hellwig 
Cc: Jan Kara 
Cc: Jens Axboe 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Cc: Pan Xinhui 
Signed-off-by: Greg Kroah-Hartman

nilfs2: fix sanity check of btree level in nilfs_btree_root_broken()

2015-05-17T16:51:32+00:00

commit d8fd150fe3935e1692bf57c66691e17409ebb9c1 upstream.

The range check for b-tree level parameter in nilfs_btree_root_broken()
is wrong; it accepts the case of "level == NILFS_BTREE_LEVEL_MAX" even
though the level is limited to values in the range of 0 to
(NILFS_BTREE_LEVEL_MAX - 1).

Since the level parameter is read from storage device and used to index
nilfs_btree_path array whose element count is NILFS_BTREE_LEVEL_MAX, it
can cause memory overrun during btree operations if the boundary value
is set to the level parameter on device.

This fixes the broken sanity check and adds a comment to clarify that
the upper bound NILFS_BTREE_LEVEL_MAX is exclusive.

Signed-off-by: Ryusuke Konishi 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

usb: define a generic USB_RESUME_TIMEOUT macro

2015-05-06T19:56:22+00:00

commit 62f0342de1f012f3e90607d39e20fce811391169 upstream.

Every USB Host controller should use this new
macro to define for how long resume signalling
should be driven on the bus.

Currently, almost every single USB controller
is using a 20ms timeout for resume signalling.

That's problematic for two reasons:

a) sometimes that 20ms timer expires a little
before 20ms, which makes us fail certification

b) some (many) devices actually need more than
20ms resume signalling.

Sure, in case of (b) we can state that the device
is against the USB spec, but the fact is that
we have no control over which device the certification
lab will use. We also have no control over which host
they will use. Most likely they'll be using a Windows
PC which, again, we have no control over how that
USB stack is written and how long resume signalling
they are using.

At the end of the day, we must make sure Linux passes
electrical compliance when working as Host or as Device
and currently we don't pass compliance as host because
we're driving resume signallig for exactly 20ms and
that confuses certification test setup resulting in
Certification failure.

Acked-by: Greg Kroah-Hartman 
Acked-by: Peter Chen 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

vm: add VM_FAULT_SIGSEGV handling support

2015-04-29T08:34:00+00:00

commit 33692f27597fcab536d7cbbcc8f52905133e4aa7 upstream.

The core VM already knows about VM_FAULT_SIGBUS, but cannot return a
"you should SIGSEGV" error, because the SIGSEGV case was generally
handled by the caller - usually the architecture fault handler.

That results in lots of duplication - all the architecture fault
handlers end up doing very similar "look up vma, check permissions, do
retries etc" - but it generally works.  However, there are cases where
the VM actually wants to SIGSEGV, and applications _expect_ SIGSEGV.

In particular, when accessing the stack guard page, libsigsegv expects a
SIGSEGV.  And it usually got one, because the stack growth is handled by
that duplicated architecture fault handler.

However, when the generic VM layer started propagating the error return
from the stack expansion in commit fee7e49d4514 ("mm: propagate error
from stack expansion even for guard page"), that now exposed the
existing VM_FAULT_SIGBUS result to user space.  And user space really
expected SIGSEGV, not SIGBUS.

To fix that case, we need to add a VM_FAULT_SIGSEGV, and teach all those
duplicate architecture fault handlers about it.  They all already have
the code to handle SIGSEGV, so it's about just tying that new return
value to the existing code, but it's all a bit annoying.

This is the mindless minimal patch to do this.  A more extensive patch
would be to try to gather up the mostly shared fault handling logic into
one generic helper routine, and long-term we really should do that
cleanup.

Just from this patch, you can generally see that most architectures just
copied (directly or indirectly) the old x86 way of doing things, but in
the meantime that original x86 model has been improved to hold the VM
semaphore for shorter times etc and to handle VM_FAULT_RETRY and other
"newer" things, so it would be a good idea to bring all those
improvements to the generic case and teach other architectures about
them too.

Reported-and-tested-by: Takashi Iwai 
Tested-by: Jan Engelhardt 
Acked-by: Heiko Carstens  # "s390 still compiles and boots"
Cc: linux-arch@vger.kernel.org
Signed-off-by: Linus Torvalds 
[shengyong: Backport to 3.10
 - adjust context
 - ignore modification for arch nios2, because 3.10 does not support it
 - ignore modification for driver lustre, because 3.10 does not support it
 - ignore VM_FAULT_FALLBACK in VM_FAULT_ERROR, becase 3.10 does not support
   this flag
 - add SIGSEGV handling to powerpc/cell spu_fault.c, because 3.10 does not
   separate it to copro_fault.c
 - add SIGSEGV handling in mm/memory.c, because 3.10 does not separate it
   to gup.c
]
Signed-off-by: Sheng Yong 
Signed-off-by: Greg Kroah-Hartman