ARM: be strict about FP exceptions in kernel mode

The support code in vfp_support_entry does not care whether the
exception that caused it to be invoked occurred in kernel mode or
in user mode. However, neither condition that could trigger this
exception (lazy restore and VFP bounce to support code) is
currently allowable in kernel mode.

In either case, print a message describing the condition before
letting the undefined instruction handler run its course and trigger
an oops.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Acked-by: Nicolas Pitre <nico at linaro.org>
Signed-off-by: Paul Reioux <reioux@gmail.com>
 arm: vfp: always clear vfp_current_hw_state when forcing reload

The current thread trying to clear the held vfp state may not be
the owner of hw state. For example,
	Core0			Core1
				Thread1	uses VFP.
				  Thread1 vfpstate.hard.cpu = 1.
				  vfp_current_hw_state[1] points to Thread1
				    vfpstate.
	Going to suspend.
	Freeze Thread1.
				Thread1 is switched out.
				VFP HW registers saved to Thread1 vfpstate.
	Core0 disables Core1.
				Stopper thread calls vfp_force_reload().
				Stopper thread vfpstate.hard.cpu = NR_CPUS.
				...
				(No PM notifier for non-idle path. So
				  vfp_pm_suspend() is NOT called on Core1.)
				...
				Core1 is off and VFP HW registers are lost.
	...
	Core0 enables Core1.
	Core0 thaw Thread1.
	Thread1 migrate to Core1
	  before using VFP.
				Thread1 starts using VFP.
				Now we have vfp_current_hw_state[1] points
				  to Thread1 vfpstate. And Thread1 has
				  vfpstate.hard.cpu = 1.
				Thread1 does not need to reload saved vfpstate
				  to VFP HW.
				Thread1 continues running using corrupted VFP
				HW register.
This change fixes above gap by always clearing vfp_current_hw_state when
vfp_force_reload() is called.

Signed-off-by: Yuanyuan Zhong <zyy@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/565782
SLTApproved: Slta Waiver <sltawvr@motorola.com>
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Connie Zhao <czhao1@motorola.com>
SLTApproved: Peter Matsimanis <peterm@motorola.com>
Reviewed-by: Klocwork kwcheck <klocwork-kwcheck@sourceforge.mot.com>
Reviewed-by: Yi-Wei Zhao <gbjc64@motorola.com>
Reviewed-by: Check Patch <CHEKPACH@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
(cherry picked from commit bbf990e)

Change-Id: Ia21319aa9c895a471a7817a98f0931ce6ddfab1e
Reviewed-on: http://gerrit.pcs.mot.com/566746
SLTApproved: Slta Waiver <sltawvr@motorola.com>
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Check Patch <CHEKPACH@motorola.com>
Reviewed-by: Klocwork kwcheck <klocwork-kwcheck@sourceforge.mot.com>
Reviewed-by: Connie Zhao <czhao1@motorola.com>
SLTApproved: Connie Zhao <czhao1@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
Signed-off-by: Luis Cruz <ljc2491@gmail.com>
 ARM: add support for kernel mode NEON

In order to safely support the use of NEON instructions in
kernel mode, some precautions need to be taken:
- the userland context that may be present in the registers (even
  if the NEON/VFP is currently disabled) must be stored under the
  correct task (which may not be 'current' in the UP case),
- to avoid having to keep track of additional vfpstates for the
  kernel side, disallow the use of NEON in interrupt context
  and run with preemption disabled,
- after use, re-enable preemption and re-enable the lazy restore
  machinery by disabling the NEON/VFP unit.

This patch adds the functions kernel_neon_begin() and
kernel_neon_end() which take care of the above. It also adds
the Kconfig symbol KERNEL_MODE_NEON to enable it.

Change-Id: Iddde22ad8684e92e5f0aa4999962ad743eff8f7c
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Nicolas Pitre <nico@linaro.org>
 ARM: crypto: add NEON accelerated XOR implementation

Add a source file xor-neon.c (which is really just the reference
C implementation passed through the GCC vectorizer) and hook it
up to the XOR framework.

Change-Id: If251e5a16d628ddfdd8d6ce40b78014cd2962d7e
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Nicolas Pitre <nico@linaro.org>
 bdi: allow block devices to say that they require stable page writes

This patchset ("stable page writes, part 2") makes some key
modifications to the original 'stable page writes' patchset.  First, it
provides creators (devices and filesystems) of a backing_dev_info a flag
that declares whether or not it is necessary to ensure that page
contents cannot change during writeout.  It is no longer assumed that
this is true of all devices (which was never true anyway).  Second, the
flag is used to relaxed the wait_on_page_writeback calls so that wait
only occurs if the device needs it.  Third, it fixes up the remaining
disk-backed filesystems to use this improved conditional-wait logic to
provide stable page writes on those filesystems.

It is hoped that (for people not using checksumming devices, anyway)
this patchset will give back unnecessary performance decreases since the
original stable page write patchset went into 3.0.  Sorry about not
fixing it sooner.

Complaints were registered by several people about the long write
latencies introduced by the original stable page write patchset.
Generally speaking, the kernel ought to allocate as little extra memory
as possible to facilitate writeout, but for people who simply cannot
wait, a second page stability strategy is (re)introduced: snapshotting
page contents.  The waiting behavior is still the default strategy; to
enable page snapshotting, a superblock flag (MS_SNAP_STABLE) must be
set.  This flag is used to bandaid^Henable stable page writeback on
ext3[1], and is not used anywhere else.

Given that there are already a few storage devices and network FSes that
have rolled their own page stability wait/page snapshot code, it would
be nice to move towards consolidating all of these.  It seems possible
that iscsi and raid5 may wish to use the new stable page write support
to enable zero-copy writeout.

Thank you to Jan Kara for helping fix a couple more filesystems.

Per Andrew Morton's request, here are the result of using dbench to measure
latencies on ext2:

3.8.0-rc3:
   Operation      Count    AvgLat    MaxLat
   ----------------------------------------
   WriteX        109347     0.028    59.817
   ReadX         347180     0.004     3.391
   Flush          15514    29.828   287.283

  Throughput 57.429 MB/sec  4 clients  4 procs  max_latency=287.290 ms

3.8.0-rc3 + patches:
   WriteX        105556     0.029     4.273
   ReadX         335004     0.005     4.112
   Flush          14982    30.540   298.634

  Throughput 55.4496 MB/sec  4 clients  4 procs  max_latency=298.650 ms

As you can see, for ext2 the maximum write latency decreases from ~60ms
on a laptop hard disk to ~4ms.  I'm not sure why the flush latencies
increase, though I suspect that being able to dirty pages faster gives
the flusher more work to do.

On ext4, the average write latency decreases as well as all the maximum
latencies:

3.8.0-rc3:
   WriteX         85624     0.152    33.078
   ReadX         272090     0.010    61.210
   Flush          12129    36.219   168.260

  Throughput 44.8618 MB/sec  4 clients  4 procs  max_latency=168.276 ms

3.8.0-rc3 + patches:
   WriteX         86082     0.141    30.928
   ReadX         273358     0.010    36.124
   Flush          12214    34.800   165.689

  Throughput 44.9941 MB/sec  4 clients  4 procs  max_latency=165.722 ms

XFS seems to exhibit similar latency improvements as ext2:

3.8.0-rc3:
   WriteX        125739     0.028   104.343
   ReadX         399070     0.005     4.115
   Flush          17851    25.004   131.390

  Throughput 66.0024 MB/sec  4 clients  4 procs  max_latency=131.406 ms

3.8.0-rc3 + patches:
   WriteX        123529     0.028     6.299
   ReadX         392434     0.005     4.287
   Flush          17549    25.120   188.687

  Throughput 64.9113 MB/sec  4 clients  4 procs  max_latency=188.704 ms

...and btrfs, just to round things out, also shows some latency
decreases:

3.8.0-rc3:
   WriteX         67122     0.083    82.355
   ReadX         212719     0.005     2.828
   Flush           9547    47.561   147.418

  Throughput 35.3391 MB/sec  4 clients  4 procs  max_latency=147.433 ms

3.8.0-rc3 + patches:
   WriteX         64898     0.101    71.631
   ReadX         206673     0.005     7.123
   Flush           9190    47.963   219.034

  Throughput 34.0795 MB/sec  4 clients  4 procs  max_latency=219.044 ms

Before this patchset, all filesystems would block, regardless of whether
or not it was necessary.  ext3 would wait, but still generate occasional
checksum errors.  The network filesystems were left to do their own
thing, so they'd wait too.

After this patchset, all the disk filesystems except ext3 and btrfs will
wait only if the hardware requires it.  ext3 (if necessary) snapshots
pages instead of blocking, and btrfs provides its own bdi so the mm will
never wait.  Network filesystems haven't been touched, so either they
provide their own wait code, or they don't block at all.  The blocking
behavior is back to what it was before 3.0 if you don't have a disk
requiring stable page writes.

This patchset has been tested on 3.8.0-rc3 on x64 with ext3, ext4, and
xfs.  I've spot-checked 3.8.0-rc4 and seem to be getting the same
results as -rc3.

[1] The alternative fixes to ext3 include fixing the locking order and
page bit handling like we did for ext4 (but then why not just use
ext4?), or setting PG_writeback so early that ext3 becomes extremely
slow.  I tried that, but the number of write()s I could initiate dropped
by nearly an order of magnitude.  That was a bit much even for the
author of the stable page series! :)

This patch:

Creates a per-backing-device flag that tracks whether or not pages must
be held immutable during writeout.  Eventually it will be used to waive
wait_for_page_writeback() if nothing requires stable pages.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Artem Bityutskiy <dedekind1@gmail.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Mark Fasheh <mfasheh@suse.com>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Eric Van Hensbergen <ericvh@gmail.com>
Cc: Ron Minnich <rminnich@sandia.gov>
Cc: Latchesar Ionkov <lucho@ionkov.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
block: recursive merge requests

In a workload, thread 1 accesses a, a+2, ..., thread 2 accesses a+1, a+3,....
When the requests are flushed to queue, a and a+1 are merged to (a, a+1), a+2
and a+3 too to (a+2, a+3), but (a, a+1) and (a+2, a+3) aren't merged.

If we do recursive merge for such interleave access, some workloads throughput
get improvement. A recent worload I'm checking on is swap, below change
boostes the throughput around 5% ~ 10%.

Signed-off-by: Shaohua Li <shli@fusionio.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
sched: fix OOPS when build_sched_domains percpu allocation fails

From: "he, bo" <bo.he@intel.com>

Under extreme memory used up situation, percpu allocation
might fails. We hit it when system go to suspend-to-ram.

EIP: [<c124411a>] build_sched_domains+0x23a/0xad0
SS:ESP 0068:de725d04
CR2: 0000000034811000
---[ end trace d6086359b670b975 ]---
Kernel panic - not syncing: Fatal exception
Pid: 3026, comm: kworker/u:3 Tainted: G      D W
3.0.8-137473-gf42fbef #1
Call Trace:
 [<c18cc4f2>] panic+0x66/0x16c
 [<c12521a1>] ? oops_exit+0x61/0x90
 [<c1205f89>] oops_end+0xb9/0xd0
 [<c1227796>] no_context+0xc6/0x1f0
 [<c1227958>] __bad_area_nosemaphore+0x98/0x140
 [<c1204ebf>] ? dump_trace+0x7f/0xf0
 [<c1227d30>] ? pgtable_bad+0x130/0x130
 [<c1227a17>] bad_area_nosemaphore+0x17/0x20
 [<c1227fa0>] do_page_fault+0x270/0x3c0
 [<c1306afa>] ? pcpu_alloc+0x12ca/0x1300
 [<c1227d30>] ? pgtable_bad+0x130/0x130
 [<c1227d30>] ? pgtable_bad+0x130/0x130
 [<c18d09d3>] error_code+0x5f/0x64
 [<c13000d8>] ? shmem_setattr+0x198/0x230
 [<c1227d30>] ? pgtable_bad+0x130/0x130
 [<c124411a>] ? build_sched_domains+0x23a/0xad0
 [<c18d01a6>] ? _raw_spin_unlock_irqrestore+0x26/0x50
 [<c1244c37>] partition_sched_domains+0x287/0x4b0
 [<c12a77be>] cpuset_update_active_cpus+0x1fe/0x210
 [<c1673017>] ? __cpufreq_remove_dev+0x167/0x360
 [<c18cf03c>] ? down_write+0x1c/0x40
 [<c123712d>] cpuset_cpu_inactive+0x1d/0x30
 [<c127dff2>] notifier_call_chain+0x52/0x90
 [<c127e04e>] __raw_notifier_call_chain+0x1e/0x30
 [<c18b37c9>] _cpu_down+0x89/0x230
 [<c12547f9>] disable_nonboot_cpus+0x79/0x100
 [<c1299fb3>] suspend_devices_and_enter+0x133/0x2e0
 [<c129a27d>] enter_state+0x11d/0x180
 [<c129a307>] pm_suspend+0x27/0x70
 [<c129b8b6>] suspend+0x96/0x1d0
 [<c1271aa3>] process_one_work+0x103/0x400
 [<c129b820>] ? power_suspend_late+0x90/0x90
 [<c12728ac>] worker_thread+0x12c/0x4b0
 [<c123748d>] ? sub_preempt_count+0x3d/0x50
 [<c18d01a6>] ? _raw_spin_unlock_irqrestore+0x26/0x50
 [<c1272780>] ? manage_workers+0x520/0x520
 [<c1276f44>] kthread+0x74/0x80
 [<c1276ed0>] ? __init_kthread_worker+0x30/0x30
 [<c18d113a>] kernel_thread_helper+0x6/0x10
Signed-off-by: he, bo <bo.he@intel.com>
Reviewed-by: Zhang, Yanmin <yanmin.zhang@intel.com>
cpuidle: add an ignore flag to the Menu governor

- an attempt to try to boost the time it takes to wake,
  especially when waking while a wakelock is being held.
reduce memory usage by input driver

input: evdev: daisy-chain header and client buffers

The evdev driver calculates memory required to hold
client data using power-of-2 math, and then adds header
size, which pushes the request over the power of 2 and
requires 2x larger allocation.

Change the logic to daisy-chain the header and client array.
That way instead of single order4 allocation, we will make
order0+order2.

Change-Id: Ibebfcce40b56a0b9b8c98b2700fa99e5f4976e2e
Signed-off-by: Igor Kovalenko <cik009@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/533666
SLT-Approved: Slta Waiver <sltawvr@motorola.com>
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Christopher Fries <qcf001@motorola.com>
Reviewed-by: Jason Hrycay <jason.hrycay@motorola.com>
Reviewed-by: Klocwork kwcheck <klocwork-kwcheck@sourceforge.mot.com>
Reviewed-by: Check Patch <CHEKPACH@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
(cherry picked from commit 8aacc71ff8c7df743a1dfffbbc8e3190499299ae)

Signed-off-by: Luis Cruz <ljc2491@gmail.com>
 lib/scatterlist: error handling in __sg_alloc_table()

I was reviewing code which I suspected might allocate a zero size SG
table.  That will cause memory corruption.  Also we can't return before
doing the memset or we could end up using uninitialized memory in the
cleanup path.

Change-Id: Icee6be8ea22644d7f16264d9d2a0887c7145996b
CRs-Fixed: 611562
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
SELinux: Fix possible NULL pointer dereference in selinux_inode_permission()

While running stress tests on adding and deleting ftrace instances I hit
this bug:

  BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
  IP: selinux_inode_permission+0x85/0x160
  PGD 63681067 PUD 7ddbe067 PMD 0
  Oops: 0000 [#1] PREEMPT
  CPU: 0 PID: 5634 Comm: ftrace-test-mki Not tainted 3.13.0-rc4-test-00033-gd2a6dde-dirty #20
  Hardware name:                  /DG965MQ, BIOS MQ96510J.86A.0372.2006.0605.1717 06/05/2006
  task: ffff880078375800 ti: ffff88007ddb0000 task.ti: ffff88007ddb0000
  RIP: 0010:[<ffffffff812d8bc5>]  [<ffffffff812d8bc5>] selinux_inode_permission+0x85/0x160
  RSP: 0018:ffff88007ddb1c48  EFLAGS: 00010246
  RAX: 0000000000000000 RBX: 0000000000800000 RCX: ffff88006dd43840
  RDX: 0000000000000001 RSI: 0000000000000081 RDI: ffff88006ee46000
  RBP: ffff88007ddb1c88 R08: 0000000000000000 R09: ffff88007ddb1c54
  R10: 6e6576652f6f6f66 R11: 0000000000000003 R12: 0000000000000000
  R13: 0000000000000081 R14: ffff88006ee46000 R15: 0000000000000000
  FS:  00007f217b5b6700(0000) GS:ffffffff81e21000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033^M
  CR2: 0000000000000020 CR3: 000000006a0fe000 CR4: 00000000000007f0
  Call Trace:
    security_inode_permission+0x1c/0x30
    __inode_permission+0x41/0xa0
    inode_permission+0x18/0x50
    link_path_walk+0x66/0x920
    path_openat+0xa6/0x6c0
    do_filp_open+0x43/0xa0
    do_sys_open+0x146/0x240
    SyS_open+0x1e/0x20
    system_call_fastpath+0x16/0x1b
  Code: 84 a1 00 00 00 81 e3 00 20 00 00 89 d8 83 c8 02 40 f6 c6 04 0f 45 d8 40 f6 c6 08 74 71 80 cf 02 49 8b 46 38 4c 8d 4d cc 45 31 c0 <0f> b7 50 20 8b 70 1c 48 8b 41 70 89 d9 8b 78 04 e8 36 cf ff ff
  RIP  selinux_inode_permission+0x85/0x160
  CR2: 0000000000000020

Investigating, I found that the inode->i_security was NULL, and the
dereference of it caused the oops.

in selinux_inode_permission():

	isec = inode->i_security;

	rc = avc_has_perm_noaudit(sid, isec->sid, isec->sclass, perms, 0, &avd);

Note, the crash came from stressing the deletion and reading of debugfs
files.  I was not able to recreate this via normal files.  But I'm not
sure they are safe.  It may just be that the race window is much harder
to hit.

What seems to have happened (and what I have traced), is the file is
being opened at the same time the file or directory is being deleted.
As the dentry and inode locks are not held during the path walk, nor is
the inodes ref counts being incremented, there is nothing saving these
structures from being discarded except for an rcu_read_lock().

The rcu_read_lock() protects against freeing of the inode, but it does
not protect freeing of the inode_security_struct.  Now if the freeing of
the i_security happens with a call_rcu(), and the i_security field of
the inode is not changed (it gets freed as the inode gets freed) then
there will be no issue here.  (Linus Torvalds suggested not setting the
field to NULL such that we do not need to check if it is NULL in the
permission check).

Note, this is a hack, but it fixes the problem at hand.  A real fix is
to restructure the destroy_inode() to call all the destructor handlers
from the RCU callback.  But that is a major job to do, and requires a
lot of work.  For now, we just band-aid this bug with this fix (it
works), and work on a more maintainable solution in the future.

Link: http://lkml.kernel.org/r/20140109101932.0508dec7@gandalf.local.home
Link: http://lkml.kernel.org/r/20140109182756.17abaaa8@gandalf.local.home

Cc: stable@vger.kernel.org
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
 SELinux: Fix kernel BUG on empty security contexts.

Setting an empty security context (length=0) on a file will
lead to incorrectly dereferencing the type and other fields
of the security context structure, yielding a kernel BUG.
As a zero-length security context is never valid, just reject
all such security contexts whether coming from userspace
via setxattr or coming from the filesystem upon a getxattr
request by SELinux.

Setting a security context value (empty or otherwise) unknown to
SELinux in the first place is only possible for a root process
(CAP_MAC_ADMIN), and, if running SELinux in enforcing mode, only
if the corresponding SELinux mac_admin permission is also granted
to the domain by policy.  In Fedora policies, this is only allowed for
specific domains such as livecd for setting down security contexts
that are not defined in the build host policy.

[On Android, this can only be set by root/CAP_MAC_ADMIN processes,
and if running SELinux in enforcing mode, only if mac_admin permission
is granted in policy.  In Android 4.4, this would only be allowed for
root/CAP_MAC_ADMIN processes that are also in unconfined domains. In current
AOSP master, mac_admin is not allowed for any domains except the recovery
console which has a legitimate need for it.  The other potential vector
is mounting a maliciously crafted filesystem for which SELinux fetches
xattrs (e.g. an ext4 filesystem on a SDcard).  However, the end result is
only a local denial-of-service (DOS) due to kernel BUG.  This fix is
queued for 3.14.]

Reproducer:
su
setenforce 0
touch foo
setfattr -n security.selinux foo

Caveat:
Relabeling or removing foo after doing the above may not be possible
without booting with SELinux disabled.  Any subsequent access to foo
after doing the above will also trigger the BUG.

BUG output from Matthew Thode:
[  473.893141] ------------[ cut here ]------------
[  473.962110] kernel BUG at security/selinux/ss/services.c:654!
[  473.995314] invalid opcode: 0000 [#6] SMP
[  474.027196] Modules linked in:
[  474.058118] CPU: 0 PID: 8138 Comm: ls Tainted: G      D   I
3.13.0-grsec #1
[  474.116637] Hardware name: Supermicro X8ST3/X8ST3, BIOS 2.0
07/29/10
[  474.149768] task: ffff8805f50cd010 ti: ffff8805f50cd488 task.ti:
ffff8805f50cd488
[  474.183707] RIP: 0010:[<ffffffff814681c7>]  [<ffffffff814681c7>]
context_struct_compute_av+0xce/0x308
[  474.219954] RSP: 0018:ffff8805c0ac3c38  EFLAGS: 00010246
[  474.252253] RAX: 0000000000000000 RBX: ffff8805c0ac3d94 RCX:
0000000000000100
[  474.287018] RDX: ffff8805e8aac000 RSI: 00000000ffffffff RDI:
ffff8805e8aaa000
[  474.321199] RBP: ffff8805c0ac3cb8 R08: 0000000000000010 R09:
0000000000000006
[  474.357446] R10: 0000000000000000 R11: ffff8805c567a000 R12:
0000000000000006
[  474.419191] R13: ffff8805c2b74e88 R14: 00000000000001da R15:
0000000000000000
[  474.453816] FS:  00007f2e75220800(0000) GS:ffff88061fc00000(0000)
knlGS:0000000000000000
[  474.489254] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  474.522215] CR2: 00007f2e74716090 CR3: 00000005c085e000 CR4:
00000000000207f0
[  474.556058] Stack:
[  474.584325]  ffff8805c0ac3c98 ffffffff811b549b ffff8805c0ac3c98
ffff8805f1190a40
[  474.618913]  ffff8805a6202f08 ffff8805c2b74e88 00068800d0464990
ffff8805e8aac860
[  474.653955]  ffff8805c0ac3cb8 000700068113833a ffff880606c75060
ffff8805c0ac3d94
[  474.690461] Call Trace:
[  474.723779]  [<ffffffff811b549b>] ? lookup_fast+0x1cd/0x22a
[  474.778049]  [<ffffffff81468824>] security_compute_av+0xf4/0x20b
[  474.811398]  [<ffffffff8196f419>] avc_compute_av+0x2a/0x179
[  474.843813]  [<ffffffff8145727b>] avc_has_perm+0x45/0xf4
[  474.875694]  [<ffffffff81457d0e>] inode_has_perm+0x2a/0x31
[  474.907370]  [<ffffffff81457e76>] selinux_inode_getattr+0x3c/0x3e
[  474.938726]  [<ffffffff81455cf6>] security_inode_getattr+0x1b/0x22
[  474.970036]  [<ffffffff811b057d>] vfs_getattr+0x19/0x2d
[  475.000618]  [<ffffffff811b05e5>] vfs_fstatat+0x54/0x91
[  475.030402]  [<ffffffff811b063b>] vfs_lstat+0x19/0x1b
[  475.061097]  [<ffffffff811b077e>] SyS_newlstat+0x15/0x30
[  475.094595]  [<ffffffff8113c5c1>] ? __audit_syscall_entry+0xa1/0xc3
[  475.148405]  [<ffffffff8197791e>] system_call_fastpath+0x16/0x1b
[  475.179201] Code: 00 48 85 c0 48 89 45 b8 75 02 0f 0b 48 8b 45 a0 48
8b 3d 45 d0 b6 00 8b 40 08 89 c6 ff ce e8 d1 b0 06 00 48 85 c0 49 89 c7
75 02 <0f> 0b 48 8b 45 b8 4c 8b 28 eb 1e 49 8d 7d 08 be 80 01 00 00 e8
[  475.255884] RIP  [<ffffffff814681c7>]
context_struct_compute_av+0xce/0x308
[  475.296120]  RSP <ffff8805c0ac3c38>
[  475.328734] ---[ end trace f076482e9d754adc ]---

[sds:  commit message edited to note Android implications and
to generate a unique Change-Id for gerrit]

Change-Id: I4d5389f0cfa72b5f59dada45081fa47e03805413
Reported-by:  Matthew Thode <mthode@mthode.org>
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Cc: stable@vger.kernel.org
Signed-off-by: Paul Moore <pmoore@redhat.com>
add /dev/hci_tty module for userspace BT in 4.2.1

Change-Id: I50770b39a3f156e70b98c6f338b313af04e6f77d

Conflicts:

	arch/arm/configs/mapphone_maserati_jb_defconfig
	arch/arm/configs/mapphone_solana_jb_defconfig
	arch/arm/configs/mapphone_spyder_jb_defconfig
	arch/arm/configs/mapphone_targa_jb_defconfig

Conflicts:
	drivers/misc/ti-st/Kconfig
	drivers/misc/ti-st/Makefile
ti-st: tty_hci: Check kzalloc return value.

Check for error condition returned by kzalloc.

Change-Id: I658cba57b9177ff68feb63d6a0e701d2a226960f
Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk@ti.com>
ti-st: tty_hci: Remove redundant assignment.

Clean up for the code: remove redundant assignment.

Change-Id: I595b549fedec4c89177f342c957e95668f184442
Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk@ti.com>
ti-st: tty_hci: Fix race condition in hci_tty_open.

Race condition is possible in the hci_tty driver.
The race result in NULL pointer dereference due to
struct sk_buff_head rx_list is used without prior
initialization.

The error condition can easily reproduced with the script
and COM-7 wilink hardware module:
while [ 1 ]; do echo -n "fail" > /dev/nfc; sleep 2; done

[   56.229614] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[   56.238494] pgd = c0004000
[   56.241485] [00000000] *pgd=00000000
[   56.245513] Internal error: Oops: 805 [#1] PREEMPT SMP ARM
[   56.251586] Modules linked in: rproc_drm(O) tf_driver(O) gps_drv wl18xx(O) wl12xx(O) wlcore(O) mac80211(O) pvrsrvkm_sgx544_112(O) cfg80211(O) compat(O) [last unloaded: wlcore_sdio]
[   56.270141] CPU: 0    Tainted: G        W  O  (3.4.34-01546-g66a9034 #82)
[   56.277618] PC is at skb_queue_tail+0x2c/0x50
[   56.282409] LR is at _raw_spin_lock_irqsave+0x10/0x14
[   56.287994] pc : [<c04eeb04>]    lr : [<c0686618>]    psr: 60000193
[   56.287994] sp : d6cbde60  ip : d6cbde50  fp : d6cbde7c
[   56.300628] r10: d6ecf5d4  r9 : d6ecf558  r8 : 00000000
[   56.306335] r7 : d6ecf5ac  r6 : cb78347c  r5 : d67c6500  r4 : cb783470
[   56.313537] r3 : 00000000  r2 : a0000193  r1 : d67c6500  r0 : a0000193
[   56.320648] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[   56.328796] Control: 10c5387d  Table: 8b6a804a  DAC: 00000015
       [skiped ...]
[   57.452667] Backtrace:
[   57.455474] [<c04eead8>] (skb_queue_tail+0x0/0x50) from [<c0300bec>] (st_receive+0x18/0x34)
[   57.464630]  r6:d5920c59 r5:00000004 r4:cb783440 r3:c0300bd4
[   57.471191] [<c0300bd4>] (st_receive+0x0/0x34) from [<c02fe924>] (st_send_frame+0x50/0xac)
[   57.480255]  r4:d6ecf540 r3:c0300bd4
[   57.484344] [<c02fe8d4>] (st_send_frame+0x0/0xac) from [<c02ff13c>] (st_int_recv+0x1fc/0x3a0)
[   57.493713]  r5:00000000 r4:d6ecf540
[   57.497894] [<c02fef40>] (st_int_recv+0x0/0x3a0) from [<c02fe548>] (st_tty_receive+0x24/0x28)
[   57.507171] [<c02fe524>] (st_tty_receive+0x0/0x28) from [<c02bbac0>] (flush_to_ldisc+0x150/0x1b4)
[   57.516906] [<c02bb970>] (flush_to_ldisc+0x0/0x1b4) from [<c0061950>] (process_one_work+0x134/0x4ac)
[   57.526916] [<c006181c>] (process_one_work+0x0/0x4ac) from [<c0061e54>] (worker_thread+0x18c/0x3d8)
[   57.536865] [<c0061cc8>] (worker_thread+0x0/0x3d8) from [<c00668d0>] (kthread+0x90/0x9c)
[   57.545684] [<c0066840>] (kthread+0x0/0x9c) from [<c004a8a8>] (do_exit+0x0/0x804)
[   57.553894]  r6:c004a8a8 r5:c0066840 r4:d6c5dec4

Change-Id: Ife34d53b4fad45d1db600d71450b06dce0328b2c
Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk@ti.com>
ti-st: tty_hci: Properly unregister protocols in open.

In case of error condition registered protocols were not
unregistered from st core when open syscall was called. Memory
allocated for the driver data was just freed. Then callback
from st_register() called st_reg_complete_cb, and complete()
had the argument from the already freed memory.

This could be the reason of the null pointer dereference, as in
the log below. The issue is rarely reproduced.

[  132.189086] (stc): st_register(12)
[  132.198394] (stc):  chnl_id list empty :12
[  132.205352] (stk) : st_kim_start
[  132.329040] (stk) :ldisc_install = 1
[  133.087829] mtp_open
[  133.329010] (stk) :ldisc installation timeout
[  133.334960] (stk) :ldisc_install = 0
[  134.336853] (stk) : timed out waiting for ldisc to be un-installed
[  134.463165] (stk) :ldisc_install = 1
[  135.469757] (stk) :ldisc installation timeout
[  135.474334] (stk) :ldisc_install = 0
[  135.557830] init: sys_prop: permission denied uid:1003 name:service.bootanim.exit
[  135.653076] init: Boot Animation exit
[  135.895965] (hci_tty): inside hci_tty_open (d66bce38, d66ff480)
[  135.902435] (stc): st_register(4)
[  135.906494] (stc):  ST_REG_IN_PROGRESS:4
[  135.910858] (stc): add_channel_to_table: id 4
[  136.477478] (stk) : timed out waiting for ldisc to be un-installed
[  136.594635] (stk) :ldisc_install = 1
[  137.595001] (stk) :ldisc installation timeout
[  137.603759] (stk) :ldisc_install = 0
[  138.602508] (stk) : timed out waiting for ldisc to be un-installed
[  138.727478] (stk) :ldisc_install = 1
[  139.727722] (stk) :ldisc installation timeout
[  139.733734] (stk) :ldisc_install = 0
[  140.580657] binder: release 1324:1324 transaction 19588 out, still active
[  140.735321] (stk) : timed out waiting for ldisc to be un-installed
[  140.852447] (stk) :ldisc_install = 1
[  141.852478] (stk) :ldisc installation timeout
[  141.857360] (stk) :ldisc_install = 0
[  141.914978] (hci_tty): Timeout(6 sec),didn't get reg completion signal from ST
[  142.868072] (stk) : timed out waiting for ldisc to be un-installed
[  142.985382] (stk) :ldisc_install = 1
[  143.985351] (stk) :ldisc installation timeout
[  143.991546] (stk) :ldisc_install = 0
[  144.993072] (stk) : timed out waiting for ldisc to be un-installed
[  145.002960] (stc):  KIM failure complete callback
[  145.008392] (stc):  st_reg_complete
[  145.012725] (hci_tty): @ st_reg_completion_cb
[  145.017639] Unable to handle kernel NULL pointer dereference at virtual address 00000010
[  145.026428] pgd = c7cc0000
[  145.029388] [00000010] *pgd=00000000
[  145.033386] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[  145.039215] Modules linked in: rproc_drm(O) tf_driver(O) gps_drv wl18xx(O) wl12xx(O) wlcore(O) mac80211(O) cfg80211(O) pvrsrvkm_sgx540_120(O) compat(O)
[  145.054870] CPU: 1    Tainted: G        W  O  (3.4.34 #1)
[  145.060821] PC is at __wake_up_common+0x2c/0x94
[  145.065734] LR is at complete+0x4c/0x60
[  145.069915] pc : [<c006ee4c>]    lr : [<c0070378>]    psr: a0000093
         [skiped...]
[  146.023742] Backtrace:
[  146.026550] [<c006ee20>] (__wake_up_common+0x0/0x94) from [<c0070378>] (complete+0x4c/0x60)
[  146.035644] [<c007032c>] (complete+0x0/0x60) from [<c0301f20>] (st_reg_completion_cb+0x30/0x38)
[  146.045104]  r6:d6ef5cd0 r5:00000092 r4:d617dd40
[  146.050384] [<c0301ef0>] (st_reg_completion_cb+0x0/0x38) from [<c02ffd34>] (st_reg_complete+0x60/0xa8)
[  146.060516]  r5:d6ef5cc4 r4:00000004
[  146.064575] [<c02ffcd4>] (st_reg_complete+0x0/0xa8) from [<c02fffac>] (st_register+0x230/0x324)
[  146.074066] [<c02ffd7c>] (st_register+0x0/0x324) from [<c0323cac>] (nfc_drv_open+0xe8/0x1e4)
[  146.083251]  r7:c8ec3840 r6:c0a5f89c r5:00000000 r4:c6016140
[  146.089752] [<c0323bc4>] (nfc_drv_open+0x0/0x1e4) from [<c0117aec>] (chrdev_open+0x9c/0x164)
[  146.098937] [<c0117a50>] (chrdev_open+0x0/0x164) from [<c0111b88>] (__dentry_open+0x200/0x2b8)
[  146.108306]  r8:c0117a50 r7:d66b1b28 r6:d5e1e910 r5:d69806f0 r4:c8ec3840
[  146.115997] [<c0111988>] (__dentry_open+0x0/0x2b8) from [<c0112c24>] (nameidata_to_filp+0x68/0x70)
[  146.125701] [<c0112bbc>] (nameidata_to_filp+0x0/0x70) from [<c01211ac>] (do_last.isra.20+0x150/0x6d4)
[  146.135711]  r7:00000026 r6:00000000 r5:00020002 r4:c6ccfed8
[  146.142272] [<c012105c>] (do_last.isra.20+0x0/0x6d4) from [<c0121954>] (path_openat+0xc0/0x3b8)
[  146.151672] [<c0121894>] (path_openat+0x0/0x3b8) from [<c0121d5c>] (do_filp_open+0x34/0x88)
[  146.160766] [<c0121d28>] (do_filp_open+0x0/0x88) from [<c0112d20>] (do_sys_open+0xf4/0x18c)
[  146.169830]  r7:00000001 r6:00000027 r5:00020002 r4:d63d1000
[  146.176330] [<c0112c2c>] (do_sys_open+0x0/0x18c) from [<c0112de0>] (sys_open+0x28/0x2c)
[  146.185058] [<c0112db8>] (sys_open+0x0/0x2c) from [<c0013680>] (ret_fast_syscall+0x0/0x30)
[  146.194061] Code: e1a08003 e50b2030 e157000c e59b9004 (e41c400c)
[

Change-Id: I10085ef1b1bc91ce3be01e179aa995287af271f1
Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk@ti.com>
drivers:misc: ti-st: fix potential NULL pointer dereference in st_register()

drivers:misc: ti-st: fix potential NULL pointer dereference in st_register()

Remove the pointless NULL dereference above the NULL test.

dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ti-st: use cpu friendly wait_for_completions

Be nice to CPU and don't hog the resources, use a nice wait_for_interruptible
timeout for completions instead of wait_for_timeout which is
non-interruptible.

Change-Id: I87542c2980978543bc3832f45592b719a61ba5b8
Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>

Conflicts:
	drivers/misc/ti-st/st_kim.c
ti-st: use msleep_interruptible instead of mdelay

Be nice to CPU and use msleep_interruptible instead of msleep which chops the
CPU up into a spin loop.
Used for all delays > 20ms.

Change-Id: I8f84ff34d9191e8fde9af28f81681470571c0b51
Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>