firefly-linux-kernel-4.4.55.git
9 years agoMerge branch 'linaro-android-3.10-lsk' of git://android.git.linaro.org/kernel/linaro...
Alex Shi [Fri, 17 Apr 2015 05:40:43 +0000 (13:40 +0800)]
Merge branch 'linaro-android-3.10-lsk' of git://android.git.linaro.org/kernel/linaro-android into linux-linaro-lsk-android

 Remove conflictsed drivers/staging/android/logger.c

9 years agotcp: Silence warning: ‘in6’ may be used uninitialized
Jon Medhurst [Thu, 16 Apr 2015 12:46:53 +0000 (18:16 +0530)]
tcp: Silence warning: ‘in6’ may be used uninitialized

Initialise in6 to avoid...

In file included from include/net/inetpeer.h:15:0,
                 from include/net/route.h:28,
                 from include/net/inet_hashtables.h:32,
                 from include/net/tcp.h:37,
                 from net/ipv4/tcp.c:275:
net/ipv4/tcp.c: In function ‘tcp_nuke_addr’:
include/net/ipv6.h:417:34: warning: ‘in6’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  return ((ul1[0] ^ ul2[0]) | (ul1[1] ^ ul2[1])) == 0UL;
                                  ^
net/ipv4/tcp.c:3513:19: note: ‘in6’ was declared here
  struct in6_addr *in6;

Signed-off-by: Jon Medhurst <tixy@linaro.org>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
9 years agocgroup: Fix build warnings when CGROUP not defined
Jon Medhurst [Thu, 16 Apr 2015 12:43:10 +0000 (18:13 +0530)]
cgroup: Fix build warnings when CGROUP not defined

Commit 57114e95e8 ("cgroup: refactor allow_attach function into common
code") unnecessarily added a dummy definition for
subsys_cgroup_allow_attach when CONFIG_CGROUP is not set, so remove it
to prevent warnings like...

include/linux/cgroup.h:907:18: warning: 'struct cgroup_taskset' declared inside parameter list
           struct cgroup_taskset *tset)
                  ^
include/linux/cgroup.h:907:18: warning: its scope is only this definition or declaration, which is probably not what you want
include/linux/cgroup.h:907:18: warning: 'struct cgroup' declared inside parameter list
  CC      kernel/events/core.o
In file included from kernel/events/core.c:41:0:
include/linux/cgroup.h:907:18: warning: 'struct cgroup_taskset' declared inside parameter list
           struct cgroup_taskset *tset)

Signed-off-by: Jon Medhurst <tixy@linaro.org>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
9 years agocpuidle: governor: menu: fix unused function warning
Amit Pundir [Thu, 16 Apr 2015 12:41:20 +0000 (18:11 +0530)]
cpuidle: governor: menu: fix unused function warning

Fixes warning caused by commit df99953c42c6 ("cpuidle: governor:
menu: don't use loadavg")

Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
9 years agodrivers/base: cpu: fix CPU_AUTOPROBE
Ryan Harkin [Thu, 16 Apr 2015 09:09:16 +0000 (14:39 +0530)]
drivers/base: cpu: fix CPU_AUTOPROBE

Use CONFIG_HAVE_CPU_AUTOPROBE instead of CONFIG_ARCH_HAS_CPU_AUTOPROBE

Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
Signed-off-by: Jon Medhurst <tixy@linaro.org>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
9 years agoMerge branch 'android-3.10' of https://android.googlesource.com/kernel/common
Amit Pundir [Thu, 16 Apr 2015 08:04:01 +0000 (13:34 +0530)]
Merge branch 'android-3.10' of https://android.googlesource.com/kernel/common

* android-3.10: (23 commits)
  proc: uid_cputime: create uids from kuids
  wakeup: Add last wake up source logging for suspend abort reason.
  selinux: add SOCK_DIAG_BY_FAMILY to the list of netlink message types
  selinux/nlmsg: add XFRM_MSG_MAPPING
  selinux/nlmsg: add XFRM_MSG_MIGRATE
  selinux/nlmsg: add XFRM_MSG_REPORT
  selinux/nlmsg: add XFRM_MSG_[NEW|GET]SADINFO
  selinux/nlmsg: add XFRM_MSG_GETSPDINFO
  selinux/nlmsg: add XFRM_MSG_NEWSPDINFO
  SELinux: per-command whitelisting of ioctls
  security: lsm_audit: add ioctl specific auditing
  Power: Report suspend times from last_suspend_time
  arm: crypto: Add optimized SHA-256/224
  proc: uid: Adds accounting for the cputimes per uid.
  USB: gadget: android: Integrate f_midi USB MIDI gadget driver part deux
  android: base-cfg: disable ALARM_DEV
  staging: Remove logger and alarm-dev from android Makefile
  staging: Remove the Android alarm-dev driver
  staging: Remove the Android logger driver
  net: ping: fix constness inconsistency in ipv6_chk_addr
  ...

9 years agoproc: uid_cputime: create uids from kuids
Amit Pundir [Tue, 14 Apr 2015 19:10:21 +0000 (00:40 +0530)]
proc: uid_cputime: create uids from kuids

Create uids from kuids using from_kuid_munged(),
otherwise we run into following build error and warnings:
--------------------
  CC      drivers/misc/uid_cputime.o
drivers/misc/uid_cputime.c: In function ‘uid_stat_show’:
drivers/misc/uid_cputime.c:90:36: error: incompatible type for argument 1 of ‘find_or_register_uid’
drivers/misc/uid_cputime.c:54:26: note: expected ‘uid_t’ but argument is of type ‘kuid_t’
drivers/misc/uid_cputime.c:94:4: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘kuid_t’ [-Wformat]
drivers/misc/uid_cputime.c: In function ‘process_notifier’:
drivers/misc/uid_cputime.c:194:6: error: incompatible types when assigning to type ‘uid_t’ from type ‘kuid_t’
make[2]: *** [drivers/misc/uid_cputime.o] Error 1
--------------------

Change-Id: Ifecb98001f7fe2fac74d1ef3e1abd03d43fc9059
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
(cherry picked from commit b0f4decae627cf2d74e6f72c7ecb939c77d48625)

9 years agoMerge branch 'linux-linaro-lsk' into linux-linaro-lsk-android
Alex Shi [Wed, 15 Apr 2015 12:08:38 +0000 (20:08 +0800)]
Merge branch 'linux-linaro-lsk' into linux-linaro-lsk-android

9 years agoconfigs: Remove duplicate CONFIG_FUNCTION_TRACER
Jon Medhurst [Wed, 15 Apr 2015 10:24:40 +0000 (11:24 +0100)]
configs: Remove duplicate CONFIG_FUNCTION_TRACER

To avoid the following warning when running merge_config.sh with
this config fragment...

./.tmp.config.37TtCkZvtp:92:warning: override: reassigning to symbol FUNCTION_TRACER

Signed-off-by: Jon Medhurst <tixy@linaro.org>
9 years agokconfig: Fix warning "‘jump’ may be used uninitialized"
Peter Kümmel [Wed, 15 Apr 2015 10:24:39 +0000 (11:24 +0100)]
kconfig: Fix warning "‘jump’ may be used uninitialized"

Warning:
In file included from scripts/kconfig/zconf.tab.c:2537:0:
scripts/kconfig/menu.c: In function ‘get_symbol_str’:
scripts/kconfig/menu.c:590:18: warning: ‘jump’ may be used uninitialized in this function [-Wmaybe-uninitialized]
     jump->offset = strlen(r->s);

Simplifies the test logic because (head && local) means (jump != 0)
and makes GCC happy when checking if the jump pointer was initialized.

Signed-off-by: Peter Kümmel <syntheticpp@gmx.net>
Signed-off-by: Michal Marek <mmarek@suse.cz>
(cherry picked from commit 2d560306096739e2251329ab5c16059311a151b0)
Signed-off-by: Jon Medhurst <tixy@linaro.org>
9 years agokconfig: fix bug in search results string: use strlen(gstr->s), not gstr->len
Martin Walch [Wed, 15 Apr 2015 10:24:38 +0000 (11:24 +0100)]
kconfig: fix bug in search results string: use strlen(gstr->s), not gstr->len

The struct gstr has a capacity that may differ from the actual string length.

However, a string manipulation in the function search_conf made the assumption
that it is the same, which led to messing up some search results, especially
when the content of the gstr in use had not yet reached at least 63 chars.

Signed-off-by: Martin Walch <walch.martin@web.de>
Acked-by: Wang YanQing <udknight@gmail.com>
Acked-by: Benjamin Poirier <bpoirier@suse.de>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
(cherry picked from commit 503c823048e81cc85c0e9d8c297cc70203e335e5)
Signed-off-by: Jon Medhurst <tixy@linaro.org>
9 years agoscripts/sortextable: suppress warning: `relocs_size' may be used uninitialized
Tim Gardner [Wed, 15 Apr 2015 10:24:37 +0000 (11:24 +0100)]
scripts/sortextable: suppress warning: `relocs_size' may be used uninitialized

In file included from scripts/sortextable.c:194:0:
scripts/sortextable.c: In function `main':
scripts/sortextable.h:176:3: warning: `relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized]
   memset(relocs, 0, relocs_size);
   ^
scripts/sortextable.h:106:6: note: `relocs_size' was declared here
  int relocs_size;
      ^
In file included from scripts/sortextable.c:192:0:
scripts/sortextable.h:176:3: warning: `relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized]
   memset(relocs, 0, relocs_size);
   ^
scripts/sortextable.h:106:6: note: `relocs_size' was declared here
  int relocs_size;
      ^

gcc 4.9.1

Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Reviewed-by: Jamie Iles <jamie.iles@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 7cbc0ea79da2cbe70d8da9319895f07f872a3190)
Signed-off-by: Jon Medhurst <tixy@linaro.org>
9 years agonetfilter: nfnetlink_queue: Fix "discards ‘const’ qualifier" warning
Jon Medhurst [Wed, 15 Apr 2015 10:24:36 +0000 (11:24 +0100)]
netfilter: nfnetlink_queue: Fix "discards ‘const’ qualifier" warning

nfqnl_zcopy can now modify the 'from' sk_buff, so drop the const
qualifier and fix build warnings like:

net/netfilter/nfnetlink_queue_core.c: In function ‘nfqnl_zcopy’:
net/netfilter/nfnetlink_queue_core.c:264:15: warning: passing argument 1 of ‘skb_orphan_frags’ discards ‘const’ qualifier from pointer target type
  if (unlikely(skb_orphan_frags(from, GFP_ATOMIC))) {

Fixes: c5f0c0e75254 ("core, nfqueue, openvswitch: Orphan frags in skb_zerocopy and handle errors")
Signed-off-by: Jon Medhurst <tixy@linaro.org>
9 years agodrm/cma: Fix printk formats in drm_gem_cma_describe
Jon Medhurst [Wed, 15 Apr 2015 10:24:35 +0000 (11:24 +0100)]
drm/cma: Fix printk formats in drm_gem_cma_describe

This fixes the following warnings when building for arm64...

drivers/gpu/drm/drm_gem_cma_helper.c: In function ‘drm_gem_cma_descr    ibe’:
drivers/gpu/drm/drm_gem_cma_helper.c:273:4: warning: format ‘%Zx’ expects argument of type ‘size_t’, but argument 6 has type ‘dma_addr_t’ [-Wformat=]
    off, cma_obj->paddr, cma_obj->vaddr, obj->size);
    ^
drivers/gpu/drm/drm_gem_cma_helper.c:273:4: warning: format ‘%d’ expects argument of type ‘int’, but argument 8 has type ‘size_t’ [-Wformat=]

Signed-off-by: Jon Medhurst <tixy@linaro.org>
9 years agodrivers/base: cpu: fix merge problem
Ryan Harkin [Tue, 14 Apr 2015 16:03:34 +0000 (17:03 +0100)]
drivers/base: cpu: fix merge problem

In LSK's linux-linaro-lsk-android branch, this merge

bb0dddf6157bc679de9143507375fce3f13fcd00

broke drivers/base/cpu.c

Because this patch appears twice:
197028d  2014-02-08  cpu: add generic support for CPU feature based
module autoloading  [Ard Biesheuvel]
126ef42  2014-02-08  cpu: add generic support for CPU feature based
module autoloading  [Ard Biesheuvel]

And the merge edited the file to the old contents.

Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
Signed-off-by: Jon Medhurst <tixy@linaro.org>
9 years agoMerge branch 'linux-linaro-lsk' into linux-linaro-lsk-android
Alex Shi [Wed, 15 Apr 2015 08:52:39 +0000 (16:52 +0800)]
Merge branch 'linux-linaro-lsk' into linux-linaro-lsk-android

9 years agoMerge branch 'for-lsk' of git://git.linaro.org/arm/big.LITTLE/mp into linux-linaro-lsk
Alex Shi [Wed, 15 Apr 2015 08:51:30 +0000 (16:51 +0800)]
Merge branch 'for-lsk' of git://git.linaro.org/arm/big.LITTLE/mp into linux-linaro-lsk

9 years agosched: hmp: fix spinlock recursion in active migration
Kevin Hilman [Wed, 8 Apr 2015 21:32:07 +0000 (14:32 -0700)]
sched: hmp: fix spinlock recursion in active migration

Commit cd5c2cc93d3d (hmp: Remove potential for task_struct access
race) introduced a put_task_struct() to prevent races, but in doing so
introduced potential spinlock recursion.  (This change was further
consolidated in commit 0baa5811bacf -- sched: hmp: unify active
migration code.)

Unfortunately, the put_task_struct() is done while the runqueue
spinlock is held, but put_task_struct() can also cause a reschedule
causing the runqueue lock to be acquired recursively.

To fix, move the put_task_struct() outside the runqueue spinlock.

Reported-by: Victor Lixin <victor.lixin@hisilicon.com>
Cc: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
Cc: Liviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: Kevin Hilman <khilman@linaro.org>
Reviewed-by: Jon Medhurst <tixy@linaro.org>
Reviewed-by: Alex Shi <alex.shi@linaro.org>
Reviewed-by: Chris Redpath <chris.redpath@arm.com>
Signed-off-by: Jon Medhurst <tixy@linaro.org>
9 years agowakeup: Add last wake up source logging for suspend abort reason.
Ruchi Kandoi [Wed, 8 Apr 2015 22:42:29 +0000 (15:42 -0700)]
wakeup: Add last wake up source logging for suspend abort reason.

There is a possibility that a wakeup source event is received after
the device prepares to suspend which might cause the suspend to abort.

This patch adds the functionality of reporting the last active wakeup
source which is currently not active but caused the suspend to abort reason
via the /sys/kernel/power/last_wakeup_reason file.

Change-Id: I1760d462f497b33e425f5565cb6cff5973932ec3
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
9 years agoselinux: add SOCK_DIAG_BY_FAMILY to the list of netlink message types
Paul Moore [Tue, 28 Jan 2014 19:45:41 +0000 (14:45 -0500)]
selinux: add SOCK_DIAG_BY_FAMILY to the list of netlink message types

commit 6a96e15096da6e7491107321cfa660c7c2aa119d upstream.

The SELinux AF_NETLINK/NETLINK_SOCK_DIAG socket class was missing the
SOCK_DIAG_BY_FAMILY definition which caused SELINUX_ERR messages when
the ss tool was run.

 # ss
 Netid  State  Recv-Q Send-Q  Local Address:Port   Peer Address:Port
 u_str  ESTAB  0      0                  * 14189             * 14190
 u_str  ESTAB  0      0                  * 14145             * 14144
 u_str  ESTAB  0      0                  * 14151             * 14150
 {...}
 # ausearch -m SELINUX_ERR
 ----
 time->Thu Jan 23 11:11:16 2014
 type=SYSCALL msg=audit(1390493476.445:374):
  arch=c000003e syscall=44 success=yes exit=40
  a0=3 a1=7fff03aa11f0 a2=28 a3=0 items=0 ppid=1852 pid=1895
  auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
  tty=pts0 ses=1 comm="ss" exe="/usr/sbin/ss"
  subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
 type=SELINUX_ERR msg=audit(1390493476.445:374):
  SELinux:  unrecognized netlink message type=20 for sclass=32

Change-Id: I22218ec620bc3ee6396145f1c2ad8ed222648309
Signed-off-by: Paul Moore <pmoore@redhat.com>
9 years agoselinux/nlmsg: add XFRM_MSG_MAPPING
Nicolas Dichtel [Fri, 10 Apr 2015 14:24:28 +0000 (16:24 +0200)]
selinux/nlmsg: add XFRM_MSG_MAPPING

commit bd2cba07381a6dba60bc1c87ed8b37931d244da1 upstream (net-next).

This command is missing.

Change-Id: Ida52130382e42355e5f3b39134aa61a1ea98026d
Fixes: 3a2dfbe8acb1 ("xfrm: Notify changes in UDP encapsulation via netlink")
CC: Martin Willi <martin@strongswan.org>
Reported-by: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
9 years agoselinux/nlmsg: add XFRM_MSG_MIGRATE
Nicolas Dichtel [Fri, 10 Apr 2015 14:24:27 +0000 (16:24 +0200)]
selinux/nlmsg: add XFRM_MSG_MIGRATE

commit 8d465bb777179c4bea731b828ec484088cc9fbc1 upstream (net-next).

This command is missing.

Change-Id: Id2c9344ca1ab2c96e0b758ad1efb38e16cf23b86
Fixes: 5c79de6e79cd ("[XFRM]: User interface for handling XFRM_MSG_MIGRATE")
Reported-by: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
9 years agoselinux/nlmsg: add XFRM_MSG_REPORT
Nicolas Dichtel [Fri, 10 Apr 2015 14:24:26 +0000 (16:24 +0200)]
selinux/nlmsg: add XFRM_MSG_REPORT

commit b0b59b0056acd6f157a04cc895f7e24692fb08aa upstream (net-next).

This command is missing.

Change-Id: I8fa3b1b9815296d3b001244d2212f79f5654bd01
Fixes: 97a64b4577ae ("[XFRM]: Introduce XFRM_MSG_REPORT.")
Reported-by: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
9 years agoselinux/nlmsg: add XFRM_MSG_[NEW|GET]SADINFO
Nicolas Dichtel [Wed, 8 Apr 2015 16:36:42 +0000 (18:36 +0200)]
selinux/nlmsg: add XFRM_MSG_[NEW|GET]SADINFO

commit 5b5800fad072133e4a9c2efbf735baaac83dec86 upstream (net-next).

These commands are missing.

Change-Id: I3fd1d3d700592c653e1a5c5199125805d55aaa95
Fixes: 28d8909bc790 ("[XFRM]: Export SAD info.")
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
9 years agoselinux/nlmsg: add XFRM_MSG_GETSPDINFO
Nicolas Dichtel [Wed, 8 Apr 2015 16:36:41 +0000 (18:36 +0200)]
selinux/nlmsg: add XFRM_MSG_GETSPDINFO

commit 5e6deebafb45fb271ae6939d48832e920b8fb74e upstream (net-next).

This command is missing.

Change-Id: Id0a0d9bf7a4af98a8f761fec902d1296138a911f
Fixes: ecfd6b183780 ("[XFRM]: Export SPD info")
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
9 years agoselinux/nlmsg: add XFRM_MSG_NEWSPDINFO
Nicolas Dichtel [Wed, 8 Apr 2015 16:36:40 +0000 (18:36 +0200)]
selinux/nlmsg: add XFRM_MSG_NEWSPDINFO

commit 2b7834d3e1b828429faa5dc41a480919e52d3f31 upstream (net-next).

This new command is missing.

Change-Id: If511000c19aa9af7220ff775d88ace9834b35dcb
Fixes: 880a6fab8f6b ("xfrm: configure policy hash table thresholds by netlink")
Reported-by: Christophe Gouault <christophe.gouault@6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
9 years agoSELinux: per-command whitelisting of ioctls
Jeff Vander Stoep [Wed, 8 Apr 2015 18:27:46 +0000 (11:27 -0700)]
SELinux: per-command whitelisting of ioctls

Extend the generic ioctl permission check with support for per-command
filtering. Source/target/class sets including the ioctl permission may
additionally include a set of commands. Example:

allow <source> <target>:<class> { 0x8910-0x8926 0x892A-0x8935 }
auditallow <source> <target>:<class> 0x892A

When ioctl commands are omitted only the permissions are checked. This
feature is intended to provide finer granularity for the ioctl
permission which may be too imprecise in some circumstances. For
example, the same driver may use ioctls to provide important and
benign functionality such as driver version or socket type as well as
dangerous capabilities such as debugging features, read/write/execute
to physical memory or access to sensitive data. Per-command filtering
provides a mechanism to reduce the attack surface of the kernel, and
limit applications to the subset of commands required.

The format of the policy binary has been modified to include ioctl
commands, and the policy version number has been incremented to
POLICYDB_VERSION_IOCTL_OPERATIONS=30 to account for the format change.

Bug: 18087110
Change-Id: Ibf0e36728f6f3f0d5af56ccdeddee40800af689d
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
9 years agosecurity: lsm_audit: add ioctl specific auditing
Jeff Vander Stoep [Sat, 4 Apr 2015 23:15:54 +0000 (16:15 -0700)]
security: lsm_audit: add ioctl specific auditing

Add information about ioctl calls to the LSM audit data. Log the
file path and command number.

Bug: 18087110
Change-Id: Idbbd106db6226683cb30022d9e8f6f3b8fab7f84
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
9 years agoPower: Report suspend times from last_suspend_time
jinqian [Wed, 25 Mar 2015 23:18:44 +0000 (16:18 -0700)]
Power: Report suspend times from last_suspend_time

This node epxorts two values separated by space.
From left to right:
1. time spent in suspend/resume process
2. time spent sleep in suspend state

Change-Id: I2cb9a9408a5fd12166aaec11b935a0fd6a408c63

9 years agoarm: crypto: Add optimized SHA-256/224
Sami Tolvanen [Mon, 23 Mar 2015 14:42:55 +0000 (14:42 +0000)]
arm: crypto: Add optimized SHA-256/224

Add Andy Polyakov's optimized assembly and NEON implementations for
SHA-256/224.

The sha256-armv4.pl script for generating the assembly code is from
OpenSSL commit 51f8d095562f36cdaa6893597b5c609e943b0565.

Compared to sha256-generic these implementations have the following
tcrypt speed improvements on Motorola Nexus 6 (Snapdragon 805):

  bs    b/u      sha256-neon  sha256-asm
  16    16       x1.32        x1.19
  64    16       x1.27        x1.15
  64    64       x1.36        x1.20
  256   16       x1.22        x1.11
  256   64       x1.36        x1.19
  256   256      x1.59        x1.23
  1024  16       x1.21        x1.10
  1024  256      x1.65        x1.23
  1024  1024     x1.76        x1.25
  2048  16       x1.21        x1.10
  2048  256      x1.66        x1.23
  2048  1024     x1.78        x1.25
  2048  2048     x1.79        x1.25
  4096  16       x1.20        x1.09
  4096  256      x1.66        x1.23
  4096  1024     x1.79        x1.26
  4096  4096     x1.82        x1.26
  8192  16       x1.20        x1.09
  8192  256      x1.67        x1.23
  8192  1024     x1.80        x1.26
  8192  4096     x1.85        x1.28
  8192  8192     x1.85        x1.27

Where bs refers to block size and b/u to bytes per update.

Change-Id: I83938010007660f7f3f77f2946c8d22557e3a327
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
9 years agoproc: uid: Adds accounting for the cputimes per uid.
jinqian [Wed, 11 Mar 2015 17:44:50 +0000 (10:44 -0700)]
proc: uid: Adds accounting for the cputimes per uid.

Adds proc files /proc/uid_cputime/show_uid_stat and
/proc/uid_cputime/remove_uid_range.

show_uid_stat lists the total utime and stime for the active as well as
terminated processes for each of the uids.

Writing a range of uids to remove_uid_range will delete the accounting
for all the uids within that range.

Change-Id: I21d9210379da730b33ddc1a0ea663c8c9d2ac15b

9 years agoMerge branch 'linux-linaro-lsk' into linux-linaro-lsk-android
Alex Shi [Mon, 30 Mar 2015 03:38:42 +0000 (11:38 +0800)]
Merge branch 'linux-linaro-lsk' into linux-linaro-lsk-android

9 years ago Merge tag 'v3.10.73' into linux-linaro-lsk
Alex Shi [Mon, 30 Mar 2015 03:38:40 +0000 (11:38 +0800)]
 Merge tag 'v3.10.73' into linux-linaro-lsk

 This is the 3.10.73 stable release

9 years agoLinux 3.10.73
Greg Kroah-Hartman [Thu, 26 Mar 2015 14:01:29 +0000 (15:01 +0100)]
Linux 3.10.73

9 years agotarget: Allow Write Exclusive non-reservation holders to READ
Lee Duncan [Mon, 5 Jan 2015 18:49:44 +0000 (10:49 -0800)]
target: Allow Write Exclusive non-reservation holders to READ

commit 1ecc7586922662e3ca2f3f0c3f17fec8749fc621 upstream.

For PGR reservation of type Write Exclusive Access, allow all non
reservation holding I_T nexuses with active registrations to READ
from the device.

This addresses a bug where active registrations that attempted
to READ would result in an reservation conflict.

Signed-off-by: Lee Duncan <lduncan@suse.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agotarget: Allow AllRegistrants to re-RESERVE existing reservation
Nicholas Bellinger [Fri, 19 Dec 2014 00:49:23 +0000 (00:49 +0000)]
target: Allow AllRegistrants to re-RESERVE existing reservation

commit ae450e246e8540300699480a3780a420a028b73f upstream.

This patch changes core_scsi3_pro_release() logic to allow an
existing AllRegistrants type reservation to be re-reserved by
any registered I_T nexus.

This addresses a issue where AllRegistrants type RESERVE was
receiving RESERVATION_CONFLICT status if dev_pr_res_holder did
not match the same I_T nexus, instead of just returning GOOD
status following spc4r34 Section 5.9.9:

"If the device server receives a PERSISTENT RESERVE OUT command
 with RESERVE service action where the TYPE field and the SCOPE
 field contain the same values as the existing type and scope
 from a persistent reservation holder, it shall not make any
 change to the existing persistent reservation and shall complete
 the command with GOOD status."

Reported-by: Ilias Tsitsimpis <i.tsitsimpis@gmail.com>
Cc: Ilias Tsitsimpis <i.tsitsimpis@gmail.com>
Cc: Lee Duncan <lduncan@suse.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agotarget: Fix R_HOLDER bit usage for AllRegistrants
Nicholas Bellinger [Sun, 14 Dec 2014 09:47:19 +0000 (01:47 -0800)]
target: Fix R_HOLDER bit usage for AllRegistrants

commit d16ca7c5198fd668db10d2c7b048ed3359c12c54 upstream.

This patch fixes the usage of R_HOLDER bit for an All Registrants
reservation in READ_FULL_STATUS, where only the registration who
issued RESERVE was being reported as having an active reservation.

It changes core_scsi3_pri_read_full_status() to check ahead of the
list walk of active registrations to see if All Registrants is active,
and if so set R_HOLDER bit and scope/type fields for all active
registrations.

Reported-by: Ilias Tsitsimpis <i.tsitsimpis@gmail.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agotarget/pscsi: Fix NULL pointer dereference in get_device_type
Nicholas Bellinger [Fri, 27 Feb 2015 11:54:13 +0000 (03:54 -0800)]
target/pscsi: Fix NULL pointer dereference in get_device_type

commit 215a8fe4198f607f34ecdbc9969dae783d8b5a61 upstream.

This patch fixes a NULL pointer dereference OOPs with pSCSI backends
within target_core_stat.c code.  The bug is caused by a configfs attr
read if no pscsi_dev_virt->pdv_sd has been configured.

Reported-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agoiscsi-target: Avoid early conn_logout_comp for iser connections
Nicholas Bellinger [Mon, 23 Feb 2015 08:57:51 +0000 (00:57 -0800)]
iscsi-target: Avoid early conn_logout_comp for iser connections

commit f068fbc82e7696d67b1bb8189306865bedf368b6 upstream.

This patch fixes a iser specific logout bug where early complete()
of conn->conn_logout_comp in iscsit_close_connection() was causing
isert_wait4logout() to complete too soon, triggering a use after
free NULL pointer dereference of iscsi_conn memory.

The complete() was originally added for traditional iscsi-target
when a ISCSI_LOGOUT_OP failed in iscsi_target_rx_opcode(), but given
iser-target does not wait in logout failure, this special case needs
to be avoided.

Reported-by: Sagi Grimberg <sagig@mellanox.com>
Cc: Sagi Grimberg <sagig@mellanox.com>
Cc: Slava Shwartsman <valyushash@gmail.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agotarget: Fix reference leak in target_get_sess_cmd() error path
Bart Van Assche [Wed, 18 Feb 2015 14:33:58 +0000 (15:33 +0100)]
target: Fix reference leak in target_get_sess_cmd() error path

commit 7544e597343e2166daba3f32e4708533aa53c233 upstream.

This patch fixes a se_cmd->cmd_kref leak buf when se_sess->sess_tearing_down
is true within target_get_sess_cmd() submission path code.

This se_cmd reference leak can occur during active session shutdown when
ack_kref=1 is passed by target_submit_cmd_[map_sgls,tmr]() callers.

Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agoARM: at91: pm: fix at91rm9200 standby
Alexandre Belloni [Tue, 3 Mar 2015 18:58:22 +0000 (19:58 +0100)]
ARM: at91: pm: fix at91rm9200 standby

commit 84e871660bebfddb9a62ebd6f19d02536e782f0a upstream.

at91rm9200 standby and suspend to ram has been broken since
00482a4078f4. It is wrongly using AT91_BASE_SYS which is a physical address
and actually doesn't correspond to any register on at91rm9200.

Use the correct at91_ramc_base[0] instead.

Fixes: 00482a4078f4 (ARM: at91: implement the standby function for pm/cpuidle)
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agoipvs: rerouting to local clients is not needed anymore
Julian Anastasov [Thu, 18 Dec 2014 20:41:23 +0000 (22:41 +0200)]
ipvs: rerouting to local clients is not needed anymore

commit 579eb62ac35845686a7c4286c0a820b4eb1f96aa upstream.

commit f5a41847acc5 ("ipvs: move ip_route_me_harder for ICMP")
from 2.6.37 introduced ip_route_me_harder() call for responses to
local clients, so that we can provide valid rt_src after SNAT.
It was used by TCP to provide valid daddr for ip_send_reply().
After commit 0a5ebb8000c5 ("ipv4: Pass explicit daddr arg to
ip_send_reply()." from 3.0 this rerouting is not needed anymore
and should be avoided, especially in LOCAL_IN.

Fixes 3.12.33 crash in xfrm reported by Florian Wiessner:
"3.12.33 - BUG xfrm_selector_match+0x25/0x2f6"

Reported-by: Smart Weblications GmbH - Florian Wiessner <f.wiessner@smart-weblications.de>
Tested-by: Smart Weblications GmbH - Florian Wiessner <f.wiessner@smart-weblications.de>
Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agoipvs: add missing ip_vs_pe_put in sync code
Julian Anastasov [Sat, 21 Feb 2015 19:03:10 +0000 (21:03 +0200)]
ipvs: add missing ip_vs_pe_put in sync code

commit 528c943f3bb919aef75ab2fff4f00176f09a4019 upstream.

ip_vs_conn_fill_param_sync() gets in param.pe a module
reference for persistence engine from __ip_vs_pe_getbyname()
but forgets to put it. Problem occurs in backup for
sync protocol v1 (2.6.39).

Also, pe_data usually comes in sync messages for
connection templates and ip_vs_conn_new() copies
the pointer only in this case. Make sure pe_data
is not leaked if it comes unexpectedly for normal
connections. Leak can happen only if bogus messages
are sent to backup server.

Fixes: fe5e7a1efb66 ("IPVS: Backup, Adding Version 1 receive capability")
Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agopowerpc/smp: Wait until secondaries are active & online
Michael Ellerman [Tue, 24 Feb 2015 06:58:02 +0000 (17:58 +1100)]
powerpc/smp: Wait until secondaries are active & online

commit 875ebe940d77a41682c367ad799b4f39f128d3fa upstream.

Anton has a busy ppc64le KVM box where guests sometimes hit the infamous
"kernel BUG at kernel/smpboot.c:134!" issue during boot:

  BUG_ON(td->cpu != smp_processor_id());

Basically a per CPU hotplug thread scheduled on the wrong CPU. The oops
output confirms it:

  CPU: 0
  Comm: watchdog/130

The problem is that we aren't ensuring the CPU active bit is set for the
secondary before allowing the master to continue on. The master unparks
the secondary CPU's kthreads and the scheduler looks for a CPU to run
on. It calls select_task_rq() and realises the suggested CPU is not in
the cpus_allowed mask. It then ends up in select_fallback_rq(), and
since the active bit isnt't set we choose some other CPU to run on.

This seems to have been introduced by 6acbfb96976f "sched: Fix hotplug
vs. set_cpus_allowed_ptr()", which changed from setting active before
online to setting active after online. However that was in turn fixing a
bug where other code assumed an active CPU was also online, so we can't
just revert that fix.

The simplest fix is just to spin waiting for both active & online to be
set. We already have a barrier prior to set_cpu_online() (which also
sets active), to ensure all other setup is completed before online &
active are set.

Fixes: 6acbfb96976f ("sched: Fix hotplug vs. set_cpus_allowed_ptr()")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agox86/vdso: Fix the build on GCC5
Jiri Slaby [Thu, 5 Mar 2015 08:13:31 +0000 (09:13 +0100)]
x86/vdso: Fix the build on GCC5

commit e893286918d2cde3a94850d8f7101cd1039e0c62 upstream.

On gcc5 the kernel does not link:

  ld: .eh_frame_hdr table[4] FDE at 0000000000000648 overlaps table[5] FDE at 0000000000000670.

Because prior GCC versions always emitted NOPs on ALIGN directives, but
gcc5 started omitting them.

.LSTARTFDEDLSI1 says:

        /* HACK: The dwarf2 unwind routines will subtract 1 from the
           return address to get an address in the middle of the
           presumed call instruction.  Since we didn't get here via
           a call, we need to include the nop before the real start
           to make up for it.  */
        .long .LSTART_sigreturn-1-.     /* PC-relative start address */

But commit 69d0627a7f6e ("x86 vDSO: reorder vdso32 code") from 2.6.25
replaced .org __kernel_vsyscall+32,0x90 by ALIGN right before
__kernel_sigreturn.

Of course, ALIGN need not generate any NOP in there. Esp. gcc5 collapses
vclock_gettime.o and int80.o together with no generated NOPs as "ALIGN".

So fix this by adding to that point at least a single NOP and make the
function ALIGN possibly with more NOPs then.

Kudos for reporting and diagnosing should go to Richard.

Reported-by: Richard Biener <rguenther@suse.de>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1425543211-12542-1-git-send-email-jslaby@suse.cz
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agox86/fpu: Drop_fpu() should not assume that tsk equals current
Oleg Nesterov [Fri, 13 Mar 2015 08:53:10 +0000 (09:53 +0100)]
x86/fpu: Drop_fpu() should not assume that tsk equals current

commit f4c3686386393c120710dd34df2a74183ab805fd upstream.

drop_fpu() does clear_used_math() and usually this is correct
because tsk == current.

However switch_fpu_finish()->restore_fpu_checking() is called before
__switch_to() updates the "current_task" variable. If it fails,
we will wrongly clear the PF_USED_MATH flag of the previous task.

So use clear_stopped_child_used_math() instead.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Pekka Riikonen <priikone@iki.fi>
Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Cc: Suresh Siddha <sbsiddha@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20150309171041.GB11388@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agox86/fpu: Avoid math_state_restore() without used_math() in __restore_xstate_sig()
Oleg Nesterov [Fri, 13 Mar 2015 08:53:09 +0000 (09:53 +0100)]
x86/fpu: Avoid math_state_restore() without used_math() in __restore_xstate_sig()

commit a7c80ebcac3068b1c3cb27d538d29558c30010c8 upstream.

math_state_restore() assumes it is called with irqs disabled,
but this is not true if the caller is __restore_xstate_sig().

This means that if ia32_fxstate == T and __copy_from_user()
fails, __restore_xstate_sig() returns with irqs disabled too.

This triggers:

  BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:41
   dump_stack
   ___might_sleep
   ? _raw_spin_unlock_irqrestore
   __might_sleep
   down_read
   ? _raw_spin_unlock_irqrestore
   print_vma_addr
   signal_fault
   sys32_rt_sigreturn

Change __restore_xstate_sig() to call set_used_math()
unconditionally. This avoids enabling and disabling interrupts
in math_state_restore(). If copy_from_user() fails, we can
simply do fpu_finit() by hand.

[ Note: this is only the first step. math_state_restore() should
        not check used_math(), it should set this flag. While
init_fpu() should simply die. ]

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Pekka Riikonen <priikone@iki.fi>
Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Suresh Siddha <sbsiddha@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20150307153844.GB25954@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agocrypto: aesni - fix memory usage in GCM decryption
Stephan Mueller [Thu, 12 Mar 2015 08:17:51 +0000 (09:17 +0100)]
crypto: aesni - fix memory usage in GCM decryption

commit ccfe8c3f7e52ae83155cb038753f4c75b774ca8a upstream.

The kernel crypto API logic requires the caller to provide the
length of (ciphertext || authentication tag) as cryptlen for the
AEAD decryption operation. Thus, the cipher implementation must
calculate the size of the plaintext output itself and cannot simply use
cryptlen.

The RFC4106 GCM decryption operation tries to overwrite cryptlen memory
in req->dst. As the destination buffer for decryption only needs to hold
the plaintext memory but cryptlen references the input buffer holding
(ciphertext || authentication tag), the assumption of the destination
buffer length in RFC4106 GCM operation leads to a too large size. This
patch simply uses the already calculated plaintext size.

In addition, this patch fixes the offset calculation of the AAD buffer
pointer: as mentioned before, cryptlen already includes the size of the
tag. Thus, the tag does not need to be added. With the addition, the AAD
will be written beyond the already allocated buffer.

Note, this fixes a kernel crash that can be triggered from user space
via AF_ALG(aead) -- simply use the libkcapi test application
from [1] and update it to use rfc4106-gcm-aes.

Using [1], the changes were tested using CAVS vectors to demonstrate
that the crypto operation still delivers the right results.

[1] http://www.chronox.de/libkcapi.html

CC: Tadeusz Struk <tadeusz.struk@intel.com>
Signed-off-by: Stephan Mueller <smueller@chronox.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agolibsas: Fix Kernel Crash in smp_execute_task
James Bottomley [Thu, 5 Mar 2015 00:18:33 +0000 (16:18 -0800)]
libsas: Fix Kernel Crash in smp_execute_task

commit 6302ce4d80aa82b3fdb5c5cd68e7268037091b47 upstream.

This crash was reported:

[  366.947370] sd 3:0:1:0: [sdb] Spinning up disk....
[  368.804046] BUG: unable to handle kernel NULL pointer dereference at           (null)
[  368.804072] IP: [<ffffffff81358457>] __mutex_lock_common.isra.7+0x9c/0x15b
[  368.804098] PGD 0
[  368.804114] Oops: 0002 [#1] SMP
[  368.804143] CPU 1
[  368.804151] Modules linked in: sg netconsole s3g(PO) uinput joydev hid_multitouch usbhid hid snd_hda_codec_via cpufreq_userspace cpufreq_powersave cpufreq_stats uhci_hcd cpufreq_conservative snd_hda_intel snd_hda_codec snd_hwdep snd_pcm sdhci_pci snd_page_alloc sdhci snd_timer snd psmouse evdev serio_raw pcspkr soundcore xhci_hcd shpchp s3g_drm(O) mvsas mmc_core ahci libahci drm i2c_core acpi_cpufreq mperf video processor button thermal_sys dm_dmirror exfat_fs exfat_core dm_zcache dm_mod padlock_aes aes_generic padlock_sha iscsi_target_mod target_core_mod configfs sswipe libsas libata scsi_transport_sas picdev via_cputemp hwmon_vid fuse parport_pc ppdev lp parport autofs4 ext4 crc16 mbcache jbd2 sd_mod crc_t10dif usb_storage scsi_mod ehci_hcd usbcore usb_common
[  368.804749]
[  368.804764] Pid: 392, comm: kworker/u:3 Tainted: P        W  O 3.4.87-logicube-ng.22 #1 To be filled by O.E.M. To be filled by O.E.M./EPIA-M920
[  368.804802] RIP: 0010:[<ffffffff81358457>]  [<ffffffff81358457>] __mutex_lock_common.isra.7+0x9c/0x15b
[  368.804827] RSP: 0018:ffff880117001cc0  EFLAGS: 00010246
[  368.804842] RAX: 0000000000000000 RBX: ffff8801185030d0 RCX: ffff88008edcb420
[  368.804857] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff8801185030d4
[  368.804873] RBP: ffff8801181531c0 R08: 0000000000000020 R09: 00000000fffffffe
[  368.804885] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801185030d4
[  368.804899] R13: 0000000000000002 R14: ffff880117001fd8 R15: ffff8801185030d8
[  368.804916] FS:  0000000000000000(0000) GS:ffff88011fc80000(0000) knlGS:0000000000000000
[  368.804931] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  368.804946] CR2: 0000000000000000 CR3: 000000000160b000 CR4: 00000000000006e0
[  368.804962] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  368.804978] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  368.804995] Process kworker/u:3 (pid: 392, threadinfo ffff880117000000, task ffff8801181531c0)
[  368.805009] Stack:
[  368.805017]  ffff8801185030d8 0000000000000000 ffffffff8161ddf0 ffffffff81056f7c
[  368.805062]  000000000000b503 ffff8801185030d0 ffff880118503000 0000000000000000
[  368.805100]  ffff8801185030d0 ffff8801188b8000 ffff88008edcb420 ffffffff813583ac
[  368.805135] Call Trace:
[  368.805153]  [<ffffffff81056f7c>] ? up+0xb/0x33
[  368.805168]  [<ffffffff813583ac>] ? mutex_lock+0x16/0x25
[  368.805194]  [<ffffffffa018c414>] ? smp_execute_task+0x4e/0x222 [libsas]
[  368.805217]  [<ffffffffa018ce1c>] ? sas_find_bcast_dev+0x3c/0x15d [libsas]
[  368.805240]  [<ffffffffa018ce4f>] ? sas_find_bcast_dev+0x6f/0x15d [libsas]
[  368.805264]  [<ffffffffa018e989>] ? sas_ex_revalidate_domain+0x37/0x2ec [libsas]
[  368.805280]  [<ffffffff81355a2a>] ? printk+0x43/0x48
[  368.805296]  [<ffffffff81359a65>] ? _raw_spin_unlock_irqrestore+0xc/0xd
[  368.805318]  [<ffffffffa018b767>] ? sas_revalidate_domain+0x85/0xb6 [libsas]
[  368.805336]  [<ffffffff8104e5d9>] ? process_one_work+0x151/0x27c
[  368.805351]  [<ffffffff8104f6cd>] ? worker_thread+0xbb/0x152
[  368.805366]  [<ffffffff8104f612>] ? manage_workers.isra.29+0x163/0x163
[  368.805382]  [<ffffffff81052c4e>] ? kthread+0x79/0x81
[  368.805399]  [<ffffffff8135fea4>] ? kernel_thread_helper+0x4/0x10
[  368.805416]  [<ffffffff81052bd5>] ? kthread_flush_work_fn+0x9/0x9
[  368.805431]  [<ffffffff8135fea0>] ? gs_change+0x13/0x13
[  368.805442] Code: 83 7d 30 63 7e 04 f3 90 eb ab 4c 8d 63 04 4c 8d 7b 08 4c 89 e7 e8 fa 15 00 00 48 8b 43 10 4c 89 3c 24 48 89 63 10 48 89 44 24 08 <48> 89 20 83 c8 ff 48 89 6c 24 10 87 03 ff c8 74 35 4d 89 ee 41
[  368.805851] RIP  [<ffffffff81358457>] __mutex_lock_common.isra.7+0x9c/0x15b
[  368.805877]  RSP <ffff880117001cc0>
[  368.805886] CR2: 0000000000000000
[  368.805899] ---[ end trace b720682065d8f4cc ]---

It's directly caused by 89d3cf6 [SCSI] libsas: add mutex for SMP task
execution, but shows a deeper cause: expander functions expect to be able to
cast to and treat domain devices as expanders.  The correct fix is to only do
expander discover when we know we've got an expander device to avoid wrongly
casting a non-expander device.

Reported-by: Praveen Murali <pmurali@logicube.com>
Tested-by: Praveen Murali <pmurali@logicube.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agoxen-pciback: limit guest control of command register
Jan Beulich [Wed, 11 Mar 2015 13:51:17 +0000 (13:51 +0000)]
xen-pciback: limit guest control of command register

commit af6fc858a35b90e89ea7a7ee58e66628c55c776b upstream.

Otherwise the guest can abuse that control to cause e.g. PCIe
Unsupported Request responses by disabling memory and/or I/O decoding
and subsequently causing (CPU side) accesses to the respective address
ranges, which (depending on system configuration) may be fatal to the
host.

Note that to alter any of the bits collected together as
PCI_COMMAND_GUEST permissive mode is now required to be enabled
globally or on the specific device.

This is CVE-2015-2150 / XSA-120.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agonilfs2: fix deadlock of segment constructor during recovery
Ryusuke Konishi [Thu, 12 Mar 2015 23:26:00 +0000 (16:26 -0700)]
nilfs2: fix deadlock of segment constructor during recovery

commit 283ee1482f349d6c0c09dfb725db5880afc56813 upstream.

According to a report from Yuxuan Shui, nilfs2 in kernel 3.19 got stuck
during recovery at mount time.  The code path that caused the deadlock was
as follows:

  nilfs_fill_super()
    load_nilfs()
      nilfs_salvage_orphan_logs()
        * Do roll-forwarding, attach segment constructor for recovery,
          and kick it.

        nilfs_segctor_thread()
          nilfs_segctor_thread_construct()
           * A lock is held with nilfs_transaction_lock()
             nilfs_segctor_do_construct()
               nilfs_segctor_drop_written_files()
                 iput()
                   iput_final()
                     write_inode_now()
                       writeback_single_inode()
                         __writeback_single_inode()
                           do_writepages()
                             nilfs_writepage()
                               nilfs_construct_dsync_segment()
                                 nilfs_transaction_lock() --> deadlock

This can happen if commit 7ef3ff2fea8b ("nilfs2: fix deadlock of segment
constructor over I_SYNC flag") is applied and roll-forward recovery was
performed at mount time.  The roll-forward recovery can happen if datasync
write is done and the file system crashes immediately after that.  For
instance, we can reproduce the issue with the following steps:

 < nilfs2 is mounted on /nilfs (device: /dev/sdb1) >
 # dd if=/dev/zero of=/nilfs/test bs=4k count=1 && sync
 # dd if=/dev/zero of=/nilfs/test conv=notrunc oflag=dsync bs=4k
 count=1 && reboot -nfh
 < the system will immediately reboot >
 # mount -t nilfs2 /dev/sdb1 /nilfs

The deadlock occurs because iput() can run segment constructor through
writeback_single_inode() if MS_ACTIVE flag is not set on sb->s_flags.  The
above commit changed segment constructor so that it calls iput()
asynchronously for inodes with i_nlink == 0, but that change was
imperfect.

This fixes the another deadlock by deferring iput() in segment constructor
even for the case that mount is not finished, that is, for the case that
MS_ACTIVE flag is not set.

Signed-off-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Reported-by: Yuxuan Shui <yshuiv7@gmail.com>
Tested-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agoregulator: core: Fix enable GPIO reference counting
Doug Anderson [Tue, 3 Mar 2015 23:20:47 +0000 (15:20 -0800)]
regulator: core: Fix enable GPIO reference counting

commit 29d62ec5f87fbeec8413e2215ddad12e7f972e4c upstream.

Normally _regulator_do_enable() isn't called on an already-enabled
rdev.  That's because the main caller, _regulator_enable() always
calls _regulator_is_enabled() and only calls _regulator_do_enable() if
the rdev was not already enabled.

However, there is one caller of _regulator_do_enable() that doesn't
check: regulator_suspend_finish().  While we might want to make
regulator_suspend_finish() behave more like _regulator_enable(), it's
probably also a good idea to make _regulator_do_enable() robust if it
is called on an already enabled rdev.

At the moment, _regulator_do_enable() is _not_ robust for already
enabled rdevs if we're using an ena_pin.  Each time
_regulator_do_enable() is called for an rdev using an ena_pin the
reference count of the ena_pin is incremented even if the rdev was
already enabled.  This is not as intended because the ena_pin is for
something else: for keeping track of how many active rdevs there are
sharing the same ena_pin.

Here's how the reference counting works here:

* Each time _regulator_enable() is called we increment
  rdev->use_count, so _regulator_enable() calls need to be balanced
  with _regulator_disable() calls.

* There is no explicit reference counting in _regulator_do_enable()
  which is normally just a warapper around rdev->desc->ops->enable()
  with code for supporting delays.  It's not expected that the
  "ops->enable()" call do reference counting.

* Since regulator_ena_gpio_ctrl() does have reference counting
  (handling the sharing of the pin amongst multiple rdevs), we
  shouldn't call it if the current rdev is already enabled.

Note that as part of this we cleanup (remove) the initting of
ena_gpio_state in regulator_register().  In _regulator_do_enable(),
_regulator_do_disable() and _regulator_is_enabled() is is clear that
ena_gpio_state should be the state of whether this particular rdev has
requested the GPIO be enabled.  regulator_register() was initting it
as the actual state of the pin.

Fixes: 967cfb18c0e3 ("regulator: core: manage enable GPIO list")
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agoregulator: Only enable disabled regulators on resume
Javier Martinez Canillas [Mon, 2 Mar 2015 20:40:39 +0000 (21:40 +0100)]
regulator: Only enable disabled regulators on resume

commit 0548bf4f5ad6fc3bd93c4940fa48078b34609682 upstream.

The _regulator_do_enable() call ought to be a no-op when called on an
already-enabled regulator.  However, as an optimization
_regulator_enable() doesn't call _regulator_do_enable() on an already
enabled regulator.  That means we never test the case of calling
_regulator_do_enable() during normal usage and there may be hidden
bugs or warnings.  We have seen warnings issued by the tps65090 driver
and bugs when using the GPIO enable pin.

Let's match the same optimization that _regulator_enable() in
regulator_suspend_finish().  That may speed up suspend/resume and also
avoids exposing hidden bugs.

[Use much clearer commit message from Doug Anderson]

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agoALSA: hda - Treat stereo-to-mono mix properly
Takashi Iwai [Mon, 16 Mar 2015 09:18:08 +0000 (10:18 +0100)]
ALSA: hda - Treat stereo-to-mono mix properly

commit cc261738add93947d138d2fabad9f4dbed4e5c00 upstream.

The commit [ef403edb7558: ALSA: hda - Don't access stereo amps for
mono channel widgets] fixed the handling of mono widgets in general,
but it still misses an exceptional case: namely, a mono mixer widget
taking a single stereo input.  In this case, it has stereo volumes
although it's a mono widget, and thus we have to take care of both
left and right input channels, as stated in HD-audio spec ("7.1.3
Widget Interconnection Rules").

This patch covers this missing piece by adding proper checks of stereo
amps in both the generic parser and the proc output codes.

Reported-by: Raymond Yau <superquad.vortex2@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agoALSA: hda - Add workaround for MacBook Air 5,2 built-in mic
Takashi Iwai [Thu, 12 Mar 2015 19:47:15 +0000 (20:47 +0100)]
ALSA: hda - Add workaround for MacBook Air 5,2 built-in mic

commit 2ddee91abe9cc34ddb6294ee14702b46ae07d460 upstream.

MacBook Air 5,2 has the same problem as MacBook Pro 8,1 where the
built-in mic records only the right channel.  Apply the same
workaround as MBP8,1 to spread the mono channel via a Cirrus codec
vendor-specific COEF setup.

Reported-and-tested-by: Vasil Zlatanov <vasil.zlatanov@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agoALSA: hda - Set single_adc_amp flag for CS420x codecs
Takashi Iwai [Thu, 12 Mar 2015 19:28:04 +0000 (20:28 +0100)]
ALSA: hda - Set single_adc_amp flag for CS420x codecs

commit bad994f5b4ab57eec8d56c180edca00505c3eeb2 upstream.

CS420x codecs seem to deal only the single amps of ADC nodes even
though the nodes receive multiple inputs.  This leads to the
inconsistent amp value after S3/S4 resume, for example.

The fix is just to set codec->single_adc_amp flag.  Then the driver
handles these ADC amps as if single connections.

Reported-and-tested-by: Vasil Zlatanov <vasil.zlatanov@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agoALSA: hda - Don't access stereo amps for mono channel widgets
Takashi Iwai [Thu, 12 Mar 2015 07:30:11 +0000 (08:30 +0100)]
ALSA: hda - Don't access stereo amps for mono channel widgets

commit ef403edb75580a3ec5d155f5de82155f0419c621 upstream.

The current HDA generic parser initializes / modifies the amp values
always in stereo, but this seems causing the problem on ALC3229 codec
that has a few mono channel widgets: namely, these mono widgets react
to actions for both channels equally.

In the driver code, we do care the mono channel and create a control
only for the left channel (as defined in HD-audio spec) for such a
node.  When the control is updated, only the left channel value is
changed.  However, in the resume, the right channel value is also
restored from the initial value we took as stereo, and this overwrites
the left channel value.  This ends up being the silent output as the
right channel has been never touched and remains muted.

This patch covers the places where unconditional stereo amp accesses
are done and converts to the conditional accesses.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94581
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agoALSA: hda - Fix built-in mic on Compaq Presario CQ60
Takashi Iwai [Wed, 11 Mar 2015 15:05:19 +0000 (16:05 +0100)]
ALSA: hda - Fix built-in mic on Compaq Presario CQ60

commit ddb6ca75b5671b8fbf1909bc588c449ee74b34f9 upstream.

Compaq Presario CQ60 laptop with CX20561 gives a wrong pin for the
built-in mic NID 0x17 instead of NID 0x1d, and it results in the
non-working mic.  This patch just remaps the pin correctly via fixup.

Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=920604
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agoALSA: control: Add sanity checks for user ctl id name string
Takashi Iwai [Wed, 11 Mar 2015 17:12:49 +0000 (18:12 +0100)]
ALSA: control: Add sanity checks for user ctl id name string

commit be3bb8236db2d0fcd705062ae2e2a9d75131222f upstream.

There was no check about the id string of user control elements, so we
accepted even a control element with an empty string, which is
obviously bogus.  This patch adds more sanity checks of id strings.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agospi: pl022: Fix race in giveback() leading to driver lock-up
Alexander Sverdlin [Fri, 27 Feb 2015 15:30:21 +0000 (16:30 +0100)]
spi: pl022: Fix race in giveback() leading to driver lock-up

commit cd6fa8d2ca53cac3226fdcffcf763be390abae32 upstream.

Commit fd316941c ("spi/pl022: disable port when unused") introduced a race,
which leads to possible driver lock up (easily reproducible on SMP).

The problem happens in giveback() function where the completion of the transfer
is signalled to SPI subsystem and then the HW SPI controller is disabled. Another
transfer might be setup in between, which brings driver in locked-up state.

Exact event sequence on SMP:

core0                                   core1

                                        => pump_transfers()
                                        /* message->state == STATE_DONE */
                                          => giveback()
                                            => spi_finalize_current_message()

=> pl022_unprepare_transfer_hardware()
=> pl022_transfer_one_message
  => flush()
  => do_interrupt_dma_transfer()
    => set_up_next_transfer()
    /* Enable SSP, turn on interrupts */
    writew((readw(SSP_CR1(pl022->virtbase)) |
           SSP_CR1_MASK_SSE), SSP_CR1(pl022->virtbase));

...

=> pl022_interrupt_handler()
  => readwriter()

                                        /* disable the SPI/SSP operation */
                                        => writew((readw(SSP_CR1(pl022->virtbase)) &
                                                  (~SSP_CR1_MASK_SSE)), SSP_CR1(pl022->virtbase));

Lockup! SPI controller is disabled and the data will never be received. Whole
SPI subsystem is waiting for transfer ACK and blocked.

So, only signal transfer completion after disabling the controller.

Fixes: fd316941c (spi/pl022: disable port when unused)
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agotpm/ibmvtpm: Additional LE support for tpm_ibmvtpm_send
jmlatten@linux.vnet.ibm.com [Sat, 21 Feb 2015 00:11:24 +0000 (18:11 -0600)]
tpm/ibmvtpm: Additional LE support for tpm_ibmvtpm_send

commit 62dfd912ab3b5405b6fe72d0135c37e9648071f1 upstream.

Problem: When IMA and VTPM are both enabled in kernel config,
kernel hangs during bootup on LE OS.

Why?: IMA calls tpm_pcr_read() which results in tpm_ibmvtpm_send
and tpm_ibmtpm_recv getting called. A trace showed that
tpm_ibmtpm_recv was hanging.

Resolution: tpm_ibmtpm_recv was hanging because tpm_ibmvtpm_send
was sending CRQ message that probably did not make much sense
to phype because of Endianness. The fix below sends correctly
converted CRQ for LE. This was not caught before because it
seems IMA is not enabled by default in kernel config and
IMA exercises this particular code path in vtpm.

Tested with IMA and VTPM enabled in kernel config and VTPM
enabled on both a BE OS and a LE OS ppc64 lpar. This exercised
CRQ and TPM command code paths in vtpm.
Patch is against Peter's tpmdd tree on github which included
Vicky's previous vtpm le patches.

Signed-off-by: Joy Latten <jmlatten@linux.vnet.ibm.com>
Reviewed-by: Ashley Lai <ashley@ahsleylai.com>
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agoworkqueue: fix hang involving racing cancel[_delayed]_work_sync()'s for PREEMPT_NONE
Tejun Heo [Thu, 5 Mar 2015 13:04:13 +0000 (08:04 -0500)]
workqueue: fix hang involving racing cancel[_delayed]_work_sync()'s for PREEMPT_NONE

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 <tj@kernel.org>
Reported-by: Rabin Vincent <rabin.vincent@axis.com>
Cc: Tomeu Vizoso <tomeu.vizoso@gmail.com>
Tested-by: Jesper Nilsson <jesper.nilsson@axis.com>
Tested-by: Rabin Vincent <rabin.vincent@axis.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agocan: add missing initialisations in CAN related skbuffs
Oliver Hartkopp [Mon, 23 Feb 2015 19:37:54 +0000 (20:37 +0100)]
can: add missing initialisations in CAN related skbuffs

commit 969439016d2cf61fef53a973d7e6d2061c3793b1 upstream.

When accessing CAN network interfaces with AF_PACKET sockets e.g. by dhclient
this can lead to a skb_under_panic due to missing skb initialisations.

Add the missing initialisations at the CAN skbuff creation times on driver
level (rx path) and in the network layer (tx path).

Reported-by: Austin Schuh <austin@peloton-tech.com>
Reported-by: Daniel Steer <daniel.steer@mclaren.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agoChange email address for 8250_pci
Russell King [Fri, 6 Mar 2015 10:49:21 +0000 (10:49 +0000)]
Change email address for 8250_pci

commit f2e0ea861117bda073d1d7ffbd3120c07c0d5d34 upstream.

I'm still receiving reports to my email address, so let's point this
at the linux-serial mailing list instead.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agovirtio_console: init work unconditionally
Michael S. Tsirkin [Thu, 5 Mar 2015 00:15:30 +0000 (10:45 +1030)]
virtio_console: init work unconditionally

commit 4f6e24ed9de8634d6471ef86b382cba6d4e57ca8 upstream.

when multiport is off, we don't initialize config work,
but we then cancel uninitialized control_work on freeze.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Amit Shah <amit.shah@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agofuse: notify: don't move pages
Miklos Szeredi [Thu, 26 Feb 2015 10:45:47 +0000 (11:45 +0100)]
fuse: notify: don't move pages

commit 0d2783626a53d4c922f82d51fa675cb5d13f0d36 upstream.

fuse_try_move_page() is not prepared for replacing pages that have already
been read.

Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agofuse: set stolen page uptodate
Miklos Szeredi [Thu, 26 Feb 2015 10:45:47 +0000 (11:45 +0100)]
fuse: set stolen page uptodate

commit aa991b3b267e24f578bac7b09cc57579b660304b upstream.

Regular pipe buffers' ->steal method (generic_pipe_buf_steal()) doesn't set
PG_uptodate.

Don't warn on this condition, just set the uptodate flag.

Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agodrm/radeon: drop setting UPLL to sleep mode
Christian König [Thu, 19 Feb 2015 08:40:28 +0000 (09:40 +0100)]
drm/radeon: drop setting UPLL to sleep mode

commit a17d4996e051e78d164989b894608cf37cd5110b upstream.

Just keep it working, seems to fix some PLL problems.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=73378

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agodrm/radeon: do a posting read in rs600_set_irq
Alex Deucher [Tue, 3 Mar 2015 01:39:56 +0000 (20:39 -0500)]
drm/radeon: do a posting read in rs600_set_irq

commit 54acf107e4e66d1f4a697e08a7f60dba9fcf07c3 upstream.

To make sure the writes go through the pci bridge.

bug:
https://bugzilla.kernel.org/show_bug.cgi?id=90741

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agodrm/radeon: do a posting read in si_set_irq
Alex Deucher [Tue, 3 Mar 2015 01:43:53 +0000 (20:43 -0500)]
drm/radeon: do a posting read in si_set_irq

commit 0586915ec10d0ae60de5cd3381ad25a704760402 upstream.

To make sure the writes go through the pci bridge.

bug:
https://bugzilla.kernel.org/show_bug.cgi?id=90741

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agodrm/radeon: do a posting read in r600_set_irq
Alex Deucher [Tue, 3 Mar 2015 01:41:31 +0000 (20:41 -0500)]
drm/radeon: do a posting read in r600_set_irq

commit 9d1393f23d5656cdd5f368efd60694d4aeed81d3 upstream.

To make sure the writes go through the pci bridge.

bug:
https://bugzilla.kernel.org/show_bug.cgi?id=90741

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agodrm/radeon: do a posting read in r100_set_irq
Alex Deucher [Tue, 3 Mar 2015 01:36:26 +0000 (20:36 -0500)]
drm/radeon: do a posting read in r100_set_irq

commit f957063fee6392bb9365370db6db74dc0b2dce0a upstream.

To make sure the writes go through the pci bridge.

bug:
https://bugzilla.kernel.org/show_bug.cgi?id=90741

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agodrm/radeon: do a posting read in evergreen_set_irq
Alex Deucher [Tue, 3 Mar 2015 01:42:53 +0000 (20:42 -0500)]
drm/radeon: do a posting read in evergreen_set_irq

commit c320bb5f6dc0cb88a811cbaf839303e0a3916a92 upstream.

To make sure the writes go through the pci bridge.

bug:
https://bugzilla.kernel.org/show_bug.cgi?id=90741

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agodrm/radeon: fix DRM_IOCTL_RADEON_CS oops
Tommi Rantala [Mon, 2 Mar 2015 19:36:07 +0000 (21:36 +0200)]
drm/radeon: fix DRM_IOCTL_RADEON_CS oops

commit a28b2a47edcd0cb7c051b445f71a426000394606 upstream.

Passing zeroed drm_radeon_cs struct to DRM_IOCTL_RADEON_CS produces the
following oops.

Fix by always calling INIT_LIST_HEAD() to avoid the crash in list_sort().

----------------------------------

 #include <stdint.h>
 #include <fcntl.h>
 #include <unistd.h>
 #include <sys/ioctl.h>
 #include <drm/radeon_drm.h>

 static const struct drm_radeon_cs cs;

 int main(int argc, char **argv)
 {
         return ioctl(open(argv[1], O_RDWR), DRM_IOCTL_RADEON_CS, &cs);
 }

----------------------------------

[ttrantal@test2 ~]$ ./main /dev/dri/card0
[   46.904650] BUG: unable to handle kernel NULL pointer dereference at           (null)
[   46.905022] IP: [<ffffffff814d6df2>] list_sort+0x42/0x240
[   46.905022] PGD 68f29067 PUD 688b5067 PMD 0
[   46.905022] Oops: 0002 [#1] SMP
[   46.905022] CPU: 0 PID: 2413 Comm: main Not tainted 4.0.0-rc1+ #58
[   46.905022] Hardware name: Hewlett-Packard HP Compaq dc5750 Small Form Factor/0A64h, BIOS 786E3 v02.10 01/25/2007
[   46.905022] task: ffff880058e2bcc0 ti: ffff880058e64000 task.ti: ffff880058e64000
[   46.905022] RIP: 0010:[<ffffffff814d6df2>]  [<ffffffff814d6df2>] list_sort+0x42/0x240
[   46.905022] RSP: 0018:ffff880058e67998  EFLAGS: 00010246
[   46.905022] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[   46.905022] RDX: ffffffff81644410 RSI: ffff880058e67b40 RDI: ffff880058e67a58
[   46.905022] RBP: ffff880058e67a88 R08: 0000000000000000 R09: 0000000000000000
[   46.905022] R10: ffff880058e2bcc0 R11: ffffffff828e6ca0 R12: ffffffff81644410
[   46.905022] R13: ffff8800694b8018 R14: 0000000000000000 R15: ffff880058e679b0
[   46.905022] FS:  00007fdc65a65700(0000) GS:ffff88006d600000(0000) knlGS:0000000000000000
[   46.905022] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   46.905022] CR2: 0000000000000000 CR3: 0000000058dd9000 CR4: 00000000000006f0
[   46.905022] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   46.905022] DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400
[   46.905022] Stack:
[   46.905022]  ffff880058e67b40 ffff880058e2bcc0 ffff880058e67a78 0000000000000000
[   46.905022]  0000000000000000 0000000000000000 0000000000000000 0000000000000000
[   46.905022]  0000000000000000 0000000000000000 0000000000000000 0000000000000000
[   46.905022] Call Trace:
[   46.905022]  [<ffffffff81644a65>] radeon_cs_parser_fini+0x195/0x220
[   46.905022]  [<ffffffff81645069>] radeon_cs_ioctl+0xa9/0x960
[   46.905022]  [<ffffffff815e1f7c>] drm_ioctl+0x19c/0x640
[   46.905022]  [<ffffffff810f8fdd>] ? trace_hardirqs_on_caller+0xfd/0x1c0
[   46.905022]  [<ffffffff810f90ad>] ? trace_hardirqs_on+0xd/0x10
[   46.905022]  [<ffffffff8160c066>] radeon_drm_ioctl+0x46/0x80
[   46.905022]  [<ffffffff81211868>] do_vfs_ioctl+0x318/0x570
[   46.905022]  [<ffffffff81462ef6>] ? selinux_file_ioctl+0x56/0x110
[   46.905022]  [<ffffffff81211b41>] SyS_ioctl+0x81/0xa0
[   46.905022]  [<ffffffff81dc6312>] system_call_fastpath+0x12/0x17
[   46.905022] Code: 48 89 b5 10 ff ff ff 0f 84 03 01 00 00 4c 8d bd 28 ff ff
ff 31 c0 48 89 fb b9 15 00 00 00 49 89 d4 4c 89 ff f3 48 ab 48 8b 46 08 <48> c7
00 00 00 00 00 48 8b 0e 48 85 c9 0f 84 7d 00 00 00 c7 85
[   46.905022] RIP  [<ffffffff814d6df2>] list_sort+0x42/0x240
[   46.905022]  RSP <ffff880058e67998>
[   46.905022] CR2: 0000000000000000
[   47.149253] ---[ end trace 09576b4e8b2c20b8 ]---

Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agotcp: make connect() mem charging friendly
Eric Dumazet [Tue, 18 Nov 2014 07:06:20 +0000 (23:06 -0800)]
tcp: make connect() mem charging friendly

[ Upstream commit 355a901e6cf1b2b763ec85caa2a9f04fbcc4ab4a ]

While working on sk_forward_alloc problems reported by Denys
Fedoryshchenko, we found that tcp connect() (and fastopen) do not call
sk_wmem_schedule() for SYN packet (and/or SYN/DATA packet), so
sk_forward_alloc is negative while connect is in progress.

We can fix this by calling regular sk_stream_alloc_skb() both for the
SYN packet (in tcp_connect()) and the syn_data packet in
tcp_send_syn_data()

Then, tcp_send_syn_data() can avoid copying syn_data as we simply
can manipulate syn_data->cb[] to remove SYN flag (and increment seq)

Instead of open coding memcpy_fromiovecend(), simply use this helper.

This leaves in socket write queue clean fast clone skbs.

This was tested against our fastopen packetdrill tests.

Reported-by: Denys Fedoryshchenko <nuclearcat@nuclearcat.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agonet: compat: Update get_compat_msghdr() to match copy_msghdr_from_user() behaviour
Catalin Marinas [Fri, 20 Mar 2015 16:48:13 +0000 (16:48 +0000)]
net: compat: Update get_compat_msghdr() to match copy_msghdr_from_user() behaviour

[ Upstream commit 91edd096e224941131f896b86838b1e59553696a ]

Commit db31c55a6fb2 (net: clamp ->msg_namelen instead of returning an
error) introduced the clamping of msg_namelen when the unsigned value
was larger than sizeof(struct sockaddr_storage). This caused a
msg_namelen of -1 to be valid. The native code was subsequently fixed by
commit dbb490b96584 (net: socket: error on a negative msg_namelen).

In addition, the native code sets msg_namelen to 0 when msg_name is
NULL. This was done in commit (6a2a2b3ae075 net:socket: set msg_namelen
to 0 if msg_name is passed as NULL in msghdr struct from userland) and
subsequently updated by 08adb7dabd48 (fold verify_iovec() into
copy_msghdr_from_user()).

This patch brings the get_compat_msghdr() in line with
copy_msghdr_from_user().

Fixes: db31c55a6fb2 (net: clamp ->msg_namelen instead of returning an error)
Cc: David S. Miller <davem@davemloft.net>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agotcp: fix tcp fin memory accounting
Josh Hunt [Thu, 19 Mar 2015 23:19:30 +0000 (19:19 -0400)]
tcp: fix tcp fin memory accounting

[ Upstream commit d22e1537181188e5dc8cbc51451832625035bdc2 ]

tcp_send_fin() does not account for the memory it allocates properly, so
sk_forward_alloc can be negative in cases where we've sent a FIN:

ss example output (ss -amn | grep -B1 f4294):
tcp    FIN-WAIT-1 0      1            192.168.0.1:45520         192.0.2.1:8080
skmem:(r0,rb87380,t0,tb87380,f4294966016,w1280,o0,bl0)
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agoRevert "net: cx82310_eth: use common match macro"
Ondrej Zary [Wed, 18 Mar 2015 22:01:01 +0000 (23:01 +0100)]
Revert "net: cx82310_eth: use common match macro"

[ Upstream commit 8d006e0105978619fb472e150c88b0d49337fe2b ]

This reverts commit 11ad714b98f6d9ca0067568442afe3e70eb94845 because
it breaks cx82310_eth.

The custom USB_DEVICE_CLASS macro matches
bDeviceClass, bDeviceSubClass and bDeviceProtocol
but the common USB_DEVICE_AND_INTERFACE_INFO matches
bInterfaceClass, bInterfaceSubClass and bInterfaceProtocol instead, which are
not specified.

Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agorxrpc: bogus MSG_PEEK test in rxrpc_recvmsg()
Al Viro [Sat, 14 Mar 2015 05:34:56 +0000 (05:34 +0000)]
rxrpc: bogus MSG_PEEK test in rxrpc_recvmsg()

[ Upstream commit 7d985ed1dca5c90535d67ce92ef6ca520302340a ]

[I would really like an ACK on that one from dhowells; it appears to be
quite straightforward, but...]

MSG_PEEK isn't passed to ->recvmsg() via msg->msg_flags; as the matter of
fact, neither the kernel users of rxrpc, nor the syscalls ever set that bit
in there.  It gets passed via flags; in fact, another such check in the same
function is done correctly - as flags & MSG_PEEK.

It had been that way (effectively disabled) for 8 years, though, so the patch
needs beating up - that case had never been tested.  If it is correct, it's
-stable fodder.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agocaif: fix MSG_OOB test in caif_seqpkt_recvmsg()
Al Viro [Sat, 14 Mar 2015 05:22:21 +0000 (05:22 +0000)]
caif: fix MSG_OOB test in caif_seqpkt_recvmsg()

[ Upstream commit 3eeff778e00c956875c70b145c52638c313dfb23 ]

It should be checking flags, not msg->msg_flags.  It's ->sendmsg()
instances that need to look for that in ->msg_flags, ->recvmsg() ones
(including the other ->recvmsg() instance in that file, as well as
unix_dgram_recvmsg() this one claims to be imitating) check in flags.
Braino had been introduced in commit dcda13 ("caif: Bugfix - use MSG_TRUNC
in receive") back in 2010, so it goes quite a while back.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agoinet_diag: fix possible overflow in inet_diag_dump_one_icsk()
Eric Dumazet [Fri, 13 Mar 2015 16:49:59 +0000 (09:49 -0700)]
inet_diag: fix possible overflow in inet_diag_dump_one_icsk()

[ Upstream commit c8e2c80d7ec00d020320f905822bf49c5ad85250 ]

inet_diag_dump_one_icsk() allocates too small skb.

Add inet_sk_attr_size() helper right before inet_sk_diag_fill()
so that it can be updated if/when new attributes are added.

iproute2/ss currently does not use this dump_one() interface,
this might explain nobody noticed this problem yet.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agords: avoid potential stack overflow
Arnd Bergmann [Wed, 11 Mar 2015 21:46:59 +0000 (22:46 +0100)]
rds: avoid potential stack overflow

[ Upstream commit f862e07cf95d5b62a5fc5e981dd7d0dbaf33a501 ]

The rds_iw_update_cm_id function stores a large 'struct rds_sock' object
on the stack in order to pass a pair of addresses. This happens to just
fit withint the 1024 byte stack size warning limit on x86, but just
exceed that limit on ARM, which gives us this warning:

net/rds/iw_rdma.c:200:1: warning: the frame size of 1056 bytes is larger than 1024 bytes [-Wframe-larger-than=]

As the use of this large variable is basically bogus, we can rearrange
the code to not do that. Instead of passing an rds socket into
rds_iw_get_device, we now just pass the two addresses that we have
available in rds_iw_update_cm_id, and we change rds_iw_get_mr accordingly,
to create two address structures on the stack there.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agonet: sysctl_net_core: check SNDBUF and RCVBUF for min length
Alexey Kodanev [Wed, 11 Mar 2015 11:29:17 +0000 (14:29 +0300)]
net: sysctl_net_core: check SNDBUF and RCVBUF for min length

[ Upstream commit b1cb59cf2efe7971d3d72a7b963d09a512d994c9 ]

sysctl has sysctl.net.core.rmem_*/wmem_* parameters which can be
set to incorrect values. Given that 'struct sk_buff' allocates from
rcvbuf, incorrectly set buffer length could result to memory
allocation failures. For example, set them as follows:

    # sysctl net.core.rmem_default=64
      net.core.wmem_default = 64
    # sysctl net.core.wmem_default=64
      net.core.wmem_default = 64
    # ping localhost -s 1024 -i 0 > /dev/null

This could result to the following failure:

skbuff: skb_over_panic: text:ffffffff81628db4 len:-32 put:-32
head:ffff88003a1cc200 data:ffff88003a1cc200 tail:0xffffffe0 end:0xc0 dev:<NULL>
kernel BUG at net/core/skbuff.c:102!
invalid opcode: 0000 [#1] SMP
...
task: ffff88003b7f5550 ti: ffff88003ae88000 task.ti: ffff88003ae88000
RIP: 0010:[<ffffffff8155fbd1>]  [<ffffffff8155fbd1>] skb_put+0xa1/0xb0
RSP: 0018:ffff88003ae8bc68  EFLAGS: 00010296
RAX: 000000000000008d RBX: 00000000ffffffe0 RCX: 0000000000000000
RDX: ffff88003fdcf598 RSI: ffff88003fdcd9c8 RDI: ffff88003fdcd9c8
RBP: ffff88003ae8bc88 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000001 R11: 00000000000002b2 R12: 0000000000000000
R13: 0000000000000000 R14: ffff88003d3f7300 R15: ffff88000012a900
FS:  00007fa0e2b4a840(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000d0f7e0 CR3: 000000003b8fb000 CR4: 00000000000006f0
Stack:
 ffff88003a1cc200 00000000ffffffe0 00000000000000c0 ffffffff818cab1d
 ffff88003ae8bd68 ffffffff81628db4 ffff88003ae8bd48 ffff88003b7f5550
 ffff880031a09408 ffff88003b7f5550 ffff88000012aa48 ffff88000012ab00
Call Trace:
 [<ffffffff81628db4>] unix_stream_sendmsg+0x2c4/0x470
 [<ffffffff81556f56>] sock_write_iter+0x146/0x160
 [<ffffffff811d9612>] new_sync_write+0x92/0xd0
 [<ffffffff811d9cd6>] vfs_write+0xd6/0x180
 [<ffffffff811da499>] SyS_write+0x59/0xd0
 [<ffffffff81651532>] system_call_fastpath+0x12/0x17
Code: 00 00 48 89 44 24 10 8b 87 c8 00 00 00 48 89 44 24 08 48 8b 87 d8 00
      00 00 48 c7 c7 30 db 91 81 48 89 04 24 31 c0 e8 4f a8 0e 00 <0f> 0b
      eb fe 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 48 83
RIP  [<ffffffff8155fbd1>] skb_put+0xa1/0xb0
RSP <ffff88003ae8bc68>
Kernel panic - not syncing: Fatal exception

Moreover, the possible minimum is 1, so we can get another kernel panic:
...
BUG: unable to handle kernel paging request at ffff88013caee5c0
IP: [<ffffffff815604cf>] __alloc_skb+0x12f/0x1f0
...

Signed-off-by: Alexey Kodanev <alexey.kodanev@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agosparc64: Fix several bugs in memmove().
David S. Miller [Mon, 23 Mar 2015 16:22:10 +0000 (09:22 -0700)]
sparc64: Fix several bugs in memmove().

[ Upstream commit 2077cef4d5c29cf886192ec32066f783d6a80db8 ]

Firstly, handle zero length calls properly.  Believe it or not there
are a few of these happening during early boot.

Next, we can't just drop to a memcpy() call in the forward copy case
where dst <= src.  The reason is that the cache initializing stores
used in the Niagara memcpy() implementations can end up clearing out
cache lines before we've sourced their original contents completely.

For example, considering NG4memcpy, the main unrolled loop begins like
this:

     load   src + 0x00
     load   src + 0x08
     load   src + 0x10
     load   src + 0x18
     load   src + 0x20
     store  dst + 0x00

Assume dst is 64 byte aligned and let's say that dst is src - 8 for
this memcpy() call.  That store at the end there is the one to the
first line in the cache line, thus clearing the whole line, which thus
clobbers "src + 0x28" before it even gets loaded.

To avoid this, just fall through to a simple copy only mildly
optimized for the case where src and dst are 8 byte aligned and the
length is a multiple of 8 as well.  We could get fancy and call
GENmemcpy() but this is good enough for how this thing is actually
used.

Reported-by: David Ahern <david.ahern@oracle.com>
Reported-by: Bob Picco <bpicco@meloft.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agosparc: Touch NMI watchdog when walking cpus and calling printk
David Ahern [Thu, 19 Mar 2015 20:06:53 +0000 (16:06 -0400)]
sparc: Touch NMI watchdog when walking cpus and calling printk

[ Upstream commit 31aaa98c248da766ece922bbbe8cc78cfd0bc920 ]

With the increase in number of CPUs calls to functions that dump
output to console (e.g., arch_trigger_all_cpu_backtrace) can take
a long time to complete. If IRQs are disabled eventually the NMI
watchdog kicks in and creates more havoc. Avoid by telling the NMI
watchdog everything is ok.

Signed-off-by: David Ahern <david.ahern@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agosparc: perf: Make counting mode actually work
David Ahern [Thu, 19 Mar 2015 20:06:17 +0000 (16:06 -0400)]
sparc: perf: Make counting mode actually work

[ Upstream commit d51291cb8f32bfae6b331e1838651f3ddefa73a5 ]

Currently perf-stat (aka, counting mode) does not work:

$ perf stat ls
...
 Performance counter stats for 'ls':

          1.585665      task-clock (msec)         #    0.580 CPUs utilized
                24      context-switches          #    0.015 M/sec
                 0      cpu-migrations            #    0.000 K/sec
                86      page-faults               #    0.054 M/sec
   <not supported>      cycles
   <not supported>      stalled-cycles-frontend
   <not supported>      stalled-cycles-backend
   <not supported>      instructions
   <not supported>      branches
   <not supported>      branch-misses

       0.002735100 seconds time elapsed

The reason is that state is never reset (stays with PERF_HES_UPTODATE set).
Add a call to sparc_pmu_enable_event during the added_event handling.
Clean up the encoding since pmu_start calls sparc_pmu_enable_event which
does the same. Passing PERF_EF_RELOAD to sparc_pmu_start means the call
to sparc_perf_event_set_period can be removed as well.

With this patch:

$ perf stat ls
...
 Performance counter stats for 'ls':

          1.552890      task-clock (msec)         #    0.552 CPUs utilized
                24      context-switches          #    0.015 M/sec
                 0      cpu-migrations            #    0.000 K/sec
                86      page-faults               #    0.055 M/sec
         5,748,997      cycles                    #    3.702 GHz
   <not supported>      stalled-cycles-frontend:HG
   <not supported>      stalled-cycles-backend:HG
         1,684,362      instructions:HG           #    0.29  insns per cycle
           295,133      branches:HG               #  190.054 M/sec
            28,007      branch-misses:HG          #    9.49% of all branches

       0.002815665 seconds time elapsed

Signed-off-by: David Ahern <david.ahern@oracle.com>
Acked-by: Bob Picco <bob.picco@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agosparc: perf: Remove redundant perf_pmu_{en|dis}able calls
David Ahern [Thu, 19 Mar 2015 20:05:57 +0000 (16:05 -0400)]
sparc: perf: Remove redundant perf_pmu_{en|dis}able calls

[ Upstream commit 5b0d4b5514bbcce69b516d0742f2cfc84ebd6db3 ]

perf_pmu_disable is called by core perf code before pmu->del and the
enable function is called by core perf code afterwards. No need to
call again within sparc_pmu_del.

Ditto for pmu->add and sparc_pmu_add.

Signed-off-by: David Ahern <david.ahern@oracle.com>
Acked-by: Bob Picco <bob.picco@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agosparc: semtimedop() unreachable due to comparison error
Rob Gardner [Tue, 3 Mar 2015 06:16:55 +0000 (23:16 -0700)]
sparc: semtimedop() unreachable due to comparison error

[ Upstream commit 53eb2516972b8c4628651dfcb926cb9ef8b2864a ]

A bug was reported that the semtimedop() system call was always
failing eith ENOSYS.

Since SEMCTL is defined as 3, and SEMTIMEDOP is defined as 4,
the comparison "call <= SEMCTL" will always prevent SEMTIMEDOP
from getting through to the semaphore ops switch statement.

This is corrected by changing the comparison to "call <= SEMTIMEDOP".

Orabug: 20633375

Signed-off-by: Rob Gardner <rob.gardner@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agosparc32: destroy_context() and switch_mm() needs to disable interrupts.
Andreas Larsson [Thu, 18 Dec 2014 12:23:23 +0000 (13:23 +0100)]
sparc32: destroy_context() and switch_mm() needs to disable interrupts.

[ Upstream commit 66d0f7ec9f1038452178b1993fc07fd96d30fd38 ]

Load balancing can be triggered in the critical sections protected by
srmmu_context_spinlock in destroy_context() and switch_mm() and can hang
the cpu waiting for the rq lock of another cpu that in turn has called
switch_mm hangning on srmmu_context_spinlock leading to deadlock.

So, disable interrupt while taking srmmu_context_spinlock in
destroy_context() and switch_mm() so we don't deadlock.

See also commit 77b838fa1ef0 ("[SPARC64]: destroy_context() needs to disable
interrupts.")

Signed-off-by: Andreas Larsson <andreas@gaisler.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agoUSB: gadget: android: Integrate f_midi USB MIDI gadget driver part deux
Mark Salyzyn [Tue, 24 Mar 2015 19:42:35 +0000 (12:42 -0700)]
USB: gadget: android: Integrate f_midi USB MIDI gadget driver part deux

free_ep_req and alloc_ep_req are static open coded and conflicting
in f_midi.c. The exported versions are present in f_sourcesink.c.
Changed names to protect the innocent.

Change-Id: I4aee40054b5715d0532d433d23dea2bccff7ec30
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
9 years agoandroid: base-cfg: disable ALARM_DEV
Mark Salyzyn [Mon, 23 Mar 2015 21:15:38 +0000 (14:15 -0700)]
android: base-cfg: disable ALARM_DEV

Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Change-Id: If8d324ffdb4ebd56e5d68876f8e229547e20eaf5

9 years agostaging: Remove logger and alarm-dev from android Makefile
John Stultz [Tue, 27 Jan 2015 15:22:21 +0000 (07:22 -0800)]
staging: Remove logger and alarm-dev from android Makefile

My previous patches deleting logger and alarm-dev from staging
missed the android Makefile.

This patch cleans up the Makefile to remove the now non-existent
files.

Cc: Rom Lemarchand <romlem@google.com>,
Cc: Mark Salyzyn <salyzyn@google.com>,
Cc: Kees Cook <keescook@chromium.org>,
Cc: Android Kernel Team <kernel-team@android.com>,
Cc: Valentin Rothberg <valentinrothberg@gmail.com>,
Cc: Greg Hackmann <ghackmann@google.com>,
Cc: Elliott Hughes <enh@google.com>,
Cc: Todd Poynor <toddpoynor@google.com>,
Reported-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 13505761
Change-Id: Id8c027ce51a663ee2e9ea2618612921db7cf7635

9 years agostaging: Remove the Android alarm-dev driver
John Stultz [Tue, 20 Jan 2015 21:42:34 +0000 (13:42 -0800)]
staging: Remove the Android alarm-dev driver

The functionality provided by the Android alarm-dev driver
should now be present in the timerfd interface (thanks to
Greg Hackmann and Todd Poynor).

As of Lollipop, AOSP can make use of the timerfd if
alarm-dev is not present (though a fixup for setting the
rtc time if rtc0 isn't the backing for _ALARM clockids has
been applied post-Lollipop).

Thus, we should be able to remove alarm-dev from staging.

Cc: Greg Hackmann <ghackmann@google.com>
Cc: Elliott Hughes <enh@google.com>
Cc: Todd Poynor <toddpoynor@google.com>
Cc: Android Kernel Team <kernel-team@android.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Acked-by: Mark Salyzyn <salyzyn@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: Ia905d4b809cc1614ddde01ccb791fc56ac292fa7

9 years agostaging: Remove the Android logger driver
John Stultz [Mon, 26 Jan 2015 20:07:32 +0000 (12:07 -0800)]
staging: Remove the Android logger driver

With the relase of Lollipop, Android no longer
requires the logger driver.

There are three patches which the android dev's
still need before they drop logger on all their
devices:

[PATCH v4 1/5] pstores: use scnprintf
[PATCH v2 2/5] pstore: remove superfluous memory size check
[PATCH 3/5] pstore: handle zero-sized prz in series
[PATCH v4 4/5] pstore: add pmsg
[PATCH 5/5] pstore: selinux: add security in-core xattr support for pstore and debugfs

But these seem to have been acked and are hopefully
queued for upstream.

So this patch removes the logger driver from staging.

Cc: Rom Lemarchand <romlem@google.com>,
Cc: Mark Salyzyn <salyzyn@google.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Android Kernel Team <kernel-team@android.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 13505761
Change-Id: I21b6897f01871851e05b6eb53c7c08a1cb597e3d

9 years agoMerge branch 'linux-linaro-lsk' into linux-linaro-lsk-android
Alex Shi [Thu, 19 Mar 2015 00:57:07 +0000 (08:57 +0800)]
Merge branch 'linux-linaro-lsk' into linux-linaro-lsk-android

9 years ago Merge tag 'v3.10.72' into linux-linaro-lsk
Alex Shi [Thu, 19 Mar 2015 00:57:04 +0000 (08:57 +0800)]
 Merge tag 'v3.10.72' into linux-linaro-lsk

 This is the 3.10.72 stable release

9 years agoMerge branch 'linux-linaro-lsk' into linux-linaro-lsk-android
Mark Brown [Wed, 18 Mar 2015 14:34:36 +0000 (14:34 +0000)]
Merge branch 'linux-linaro-lsk' into linux-linaro-lsk-android

9 years agoLinux 3.10.72
Greg Kroah-Hartman [Wed, 18 Mar 2015 12:22:50 +0000 (13:22 +0100)]
Linux 3.10.72

9 years agoath5k: fix spontaneus AR5312 freezes
Sergey Ryazanov [Tue, 3 Feb 2015 21:21:13 +0000 (00:21 +0300)]
ath5k: fix spontaneus AR5312 freezes

commit 8bfae4f9938b6c1f033a5159febe97e441d6d526 upstream.

Sometimes while CPU have some load and ath5k doing the wireless
interface reset the whole WiSoC completely freezes. Set of tests shows
that using atomic delay function while we wait interface reset helps to
avoid such freezes.

The easiest way to reproduce this issue: create a station interface,
start continous scan with wpa_supplicant and load CPU by something. Or
just create multiple station interfaces and put them all in continous
scan.

This patch partially reverts the commit 1846ac3dbec0 ("ath5k: Use
usleep_range where possible"), which replaces initial udelay()
by usleep_range().

I do not know actual source of this issue, but all looks like that HW
freeze is caused by transaction on internal SoC bus, while wireless
block is in reset state.

Also I should note that I do not know how many chips are affected, but I
did not see this issue with chips, other than AR5312.

CC: Jiri Slaby <jirislaby@gmail.com>
CC: Nick Kossifidis <mickflemm@gmail.com>
CC: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Fixes: 1846ac3dbec0 ("ath5k: Use usleep_range where possible")
Reported-by: Christophe Prevotaux <c.prevotaux@rural-networks.com>
Tested-by: Christophe Prevotaux <c.prevotaux@rural-networks.com>
Tested-by: Eric Bree <ebree@nltinc.com>
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 years agoACPI / video: Load the module even if ACPI is disabled
Chris Wilson [Sun, 1 Mar 2015 10:41:37 +0000 (10:41 +0000)]
ACPI / video: Load the module even if ACPI is disabled

commit 6e17cb12881ba8d5e456b89f072dc6b70048af36 upstream.

i915.ko depends upon the acpi/video.ko module and so refuses to load if
ACPI is disabled at runtime if for example the BIOS is broken beyond
repair. acpi/video provides an optional service for i915.ko and so we
should just allow the modules to load, but do no nothing in order to let
the machines boot correctly.

Reported-by: Bill Augur <bill-auger@programmer.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@intel.com>
Acked-by: Aaron Lu <aaron.lu@intel.com>
[ rjw: Fixed up the new comment in acpi_video_init() ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>