futex: Prevent attaching to kernel threads

We happily allow userspace to declare a random kernel thread to be the
owner of a user space PI futex.

Found while analysing the fallout of Dave Jones syscall fuzzer.

We also should validate the thread group for private futexes and find
some fast way to validate whether the "alleged" owner has RW access on
the file which backs the SHM, but that's a separate issue.

Change-Id: I03941dc5737bcb9d3ddd2ec88f7c263c27a1247d
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Dave Jones <davej@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Darren Hart <darren@dvhart.com>
Cc: Davidlohr Bueso <davidlohr@hp.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Clark Williams <williams@redhat.com>
Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: Roland McGrath <roland@hack.frob.com>
Cc: Carlos ODonell <carlos@redhat.com>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: http://lkml.kernel.org/r/20140512201701.194824402@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
futex: Add another early deadlock detection check

Dave Jones trinity syscall fuzzer exposed an issue in the deadlock
detection code of rtmutex:
  http://lkml.kernel.org/r/20140429151655.GA14277@redhat.com

That underlying issue has been fixed with a patch to the rtmutex code,
but the futex code must not call into rtmutex in that case because
    - it can detect that issue early
    - it avoids a different and more complex fixup for backing out

If the user space variable got manipulated to 0x80000000 which means
no lock holder, but the waiters bit set and an active pi_state in the
kernel is found we can figure out the recursive locking issue by
looking at the pi_state owner. If that is the current task, then we
can safely return -EDEADLK.

The check should have been added in commit 59fa62451 (futex: Handle
futex_pi OWNER_DIED take over correctly) already, but I did not see
the above issue caused by user space manipulation back then.

Change-Id: I5242efcdc3c08159c652fe645e1f85b27687e6ca
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Dave Jones <davej@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Darren Hart <darren@dvhart.com>
Cc: Davidlohr Bueso <davidlohr@hp.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Clark Williams <williams@redhat.com>
Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: Roland McGrath <roland@hack.frob.com>
Cc: Carlos ODonell <carlos@redhat.com>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: http://lkml.kernel.org/r/20140512201701.097349971@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
futex-prevent-requeue-pi-on-same-futex.patch futex: Forbid uaddr == uaddr2 in futex_requeue(..., requeue_pi=1)

If uaddr == uaddr2, then we have broken the rule of only requeueing
from a non-pi futex to a pi futex with this call. If we attempt this,
then dangling pointers may be left for rt_waiter resulting in an
exploitable condition.

This change brings futex_requeue() into line with
futex_wait_requeue_pi() which performs the same check as per commit
6f7b0a2a5 (futex: Forbid uaddr == uaddr2 in futex_wait_requeue_pi())

[ tglx: Compare the resulting keys as well, as uaddrs might be
  	different depending on the mapping ]

Fixes CVE-2014-3153.

Change-Id: I473bf486ad451de0bfd049a110b69795a6fda451
Reported-by: Pinkie Pie
Signed-off-by: Will Drewry <wad@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
futex: Validate atomic acquisition in futex_lock_pi_atomic()

We need to protect the atomic acquisition in the kernel against rogue
user space which sets the user space futex to 0, so the kernel side
acquisition succeeds while there is existing state in the kernel
associated to the real owner.

Verify whether the futex has waiters associated with kernel state. If
it has, return -EINVAL. The state is corrupted already, so no point in
cleaning it up. Subsequent calls will fail as well. Not our problem.

[ tglx: Use futex_top_waiter() and explain why we do not need to try
  	restoring the already corrupted user space state. ]

Change-Id: Ic8714ed2e9dee323a011eed42f7c0159c65dfbf3
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Will Drewry <wad@chromium.org>
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
futex: Always cleanup owner tid in unlock_pi

If the owner died bit is set at futex_unlock_pi, we currently do not
cleanup the user space futex. So the owner TID of the current owner
(the unlocker) persists. That's observable inconsistant state,
especially when the ownership of the pi state got transferred.

Clean it up unconditionally.

Change-Id: I4eeb2e139b720f1dd46e43407a96b3d9a19aacd1
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Kees Cook <keescook@chromium.org>
Cc: Will Drewry <wad@chromium.org>
Cc: Darren Hart <dvhart@linux.intel.com>
Cc: stable@vger.kernel.org
futex: Make lookup_pi_state more robust

The current implementation of lookup_pi_state has ambigous handling of
the TID value 0 in the user space futex. We can get into the kernel
even if the TID value is 0, because either there is a stale waiters
bit or the owner died bit is set or we are called from the requeue_pi
path or from user space just for fun.

The current code avoids an explicit sanity check for pid = 0 in case
that kernel internal state (waiters) are found for the user space
address. This can lead to state leakage and worse under some
circumstances.

Handle the cases explicit:

     Waiter | pi_state | pi->owner | uTID      | uODIED | ?

[1]  NULL   | ---      | ---       | 0         | 0/1    | Valid
[2]  NULL   | ---      | ---       | >0        | 0/1    | Valid

[3]  Found  | NULL     | --        | Any       | 0/1    | Invalid

[4]  Found  | Found    | NULL      | 0         | 1      | Valid
[5]  Found  | Found    | NULL      | >0        | 1      | Invalid

[6]  Found  | Found    | task      | 0         | 1      | Valid

[7]  Found  | Found    | NULL      | Any       | 0      | Invalid

[8]  Found  | Found    | task      | ==taskTID | 0/1    | Valid
[9]  Found  | Found    | task      | 0         | 0      | Invalid
[10] Found  | Found    | task      | !=taskTID | 0/1    | Invalid

[1]  Indicates that the kernel can acquire the futex atomically. We
     came came here due to a stale FUTEX_WAITERS/FUTEX_OWNER_DIED bit.

[2]  Valid, if TID does not belong to a kernel thread. If no matching
     thread is found then it indicates that the owner TID has died.

[3]  Invalid. The waiter is queued on a non PI futex

[4]  Valid state after exit_robust_list(), which sets the user space
     value to FUTEX_WAITERS | FUTEX_OWNER_DIED.

[5]  The user space value got manipulated between exit_robust_list()
     and exit_pi_state_list()

[6]  Valid state after exit_pi_state_list() which sets the new owner in
     the pi_state but cannot access the user space value.

[7]  pi_state->owner can only be NULL when the OWNER_DIED bit is set.

[8]  Owner and user space value match

[9]  There is no transient state which sets the user space TID to 0
     except exit_robust_list(), but this is indicated by the
     FUTEX_OWNER_DIED bit. See [4]

[10] There is no transient state which leaves owner and user space
     TID out of sync.

Backport to 3.13
  conflicts: kernel/futex.c

Change-Id: Ic410036b38ccb7289b3d58eff56ad64d3a9dcada
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Johansen <john.johansen@canonical.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Will Drewry <wad@chromium.org>
Cc: Darren Hart <dvhart@linux.intel.com>
Cc: stable@vger.kernel.org
 n_tty: Fix n_tty_write crash when echoing in raw mode

The tty atomic_write_lock does not provide an exclusion guarantee for
the tty driver if the termios settings are LECHO & !OPOST.  And since
it is unexpected and not allowed to call TTY buffer helpers like
tty_insert_flip_string concurrently, this may lead to crashes when
concurrect writers call pty_write. In that case the following two
writers:
* the ECHOing from a workqueue and
* pty_write from the process
race and can overflow the corresponding TTY buffer like follows.

If we look into tty_insert_flip_string_fixed_flag, there is:
  int space = __tty_buffer_request_room(port, goal, flags);
  struct tty_buffer *tb = port->buf.tail;
  ...
  memcpy(char_buf_ptr(tb, tb->used), chars, space);
  ...
  tb->used += space;

so the race of the two can result in something like this:
              A                                B
__tty_buffer_request_room
                                  __tty_buffer_request_room
memcpy(buf(tb->used), ...)
tb->used += space;
                                  memcpy(buf(tb->used), ...) ->BOOM

B's memcpy is past the tty_buffer due to the previous A's tb->used
increment.

Since the N_TTY line discipline input processing can output
concurrently with a tty write, obtain the N_TTY ldisc output_lock to
serialize echo output with normal tty writes.  This ensures the tty
buffer helper tty_insert_flip_string is not called concurrently and
everything is fine.

Note that this is nicely reproducible by an ordinary user using
forkpty and some setup around that (raw termios + ECHO). And it is
present in kernels at least after commit
d945cb9 (pty: Rework the pty layer to
use the normal buffering logic) in 2.6.31-rc3.

js: add more info to the commit log
js: switch to bool
js: lock unconditionally
js: lock only the tty->ops->write call

References: CVE-2014-0196
Reported-and-tested-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[bwh: Backported to 3.2: output_lock is a member of struct tty_struct]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

Change-Id: Ifb8bf28246556efb3c42aa5d153ef7fb4ed95cbc
 zram: avoid invalid memory access in zram_exit()

commit 6030ea9 upstream.

Memory for zram->disk object may have already been freed after returning
from destroy_device(zram), then it's unsafe for zram_reset_device(zram)
to access zram->disk again.

We can't solve this bug by flipping the order of destroy_device(zram)
and zram_reset_device(zram), that will cause deadlock issues to the
zram sysfs handler.

So fix it by holding an extra reference to zram->disk before calling
destroy_device(zram).

Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Jianguo Wu <wujianguo@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 VFS: make vfs_fstat() use f[get|put]_light()

commit e994def upstream.

Use the *_light() versions that properly avoid doing the file user count
updates when they are unnecessary.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[xr: Backported to 3.4: adjust function name]
Signed-off-by: Rui Xiang <rui.xiang@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 tracing: Keep overwrite in sync between regular and snapshot buffers

commit 8090282 upstream.

Changing the overwrite mode for the ring buffer via the trace
option only sets the normal buffer. But the snapshot buffer could
swap with it, and then the snapshot would be in non overwrite mode
and the normal buffer would be in overwrite mode, even though the
option flag states otherwise.

Keep the two buffers overwrite modes in sync.

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Rui Xiang <rui.xiang@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 fs: cachefiles: add support for large files in filesystem caching

commit 98c350c upstream.

Support the caching of large files.

Addresses https://bugzilla.kernel.org/show_bug.cgi?id=31182

Signed-off-by: Justin Lecher <jlec@gentoo.org>
Signed-off-by: Suresh Jayaraman <sjayaraman@suse.com>
Tested-by: Suresh Jayaraman <sjayaraman@suse.com>
Acked-by: David Howells <dhowells@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[bwh: Backported to 3.2:
 - Adjust context
 - dentry_open() takes dentry and vfsmount pointers, not a path pointer]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Rui Xiang <rui.xiang@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The gcc warns like:

  cpufreq_interactive.c:745:6: warning: operation on 'ret' may be
undefined [-Wsequence-point]

It was introduced by commit cf0fad4.

Since sprintf(...) just return 1 (one character) in this case, ret
should not changed.
Just discarding the result of sprintf(...) leads to the result that
the committer of cf0fad4 wants.

Change-Id: Ifed1cef6d6a31c3ed23dad03a567b3b9eddf3a57
Signed-off-by: Chih-Wei Huang <cwhuang@android-x86.org>
Signed-off-by: Dave Daynard <nardholio@gmail.com>
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>
cpufreq: interactive: allow arbitrary speed / delay mappings

Accept a string of delays and speeds at which to apply the delay before
raising each step above hispeed. For example, "80000 1300000:200000
1500000:40000" means that the delay at or above 1GHz, until 1.3GHz is 80 msecs,
the delay until 1.5GHz is 200 msecs and the delay at or above 1.5GHz is 40
msecs when hispeed_freq is 1GHz.

[toddpoynor@google.com: add documentation]
Change-Id: Ifeebede8b1acbdd0a53e5c6916bccbf764dc854f
Signed-off-by: Minsung Kim <ms925.kim@samsung.com>

Conflicts:
	drivers/cpufreq/cpufreq_interactive.c