Avoid to create duplicate filename for misc devices.

There has two bugs.
1. For example, the 'psaux' device will use '1' as minor number to
register misc device, but misc deriver doesn't set the '1' as used.
It's the root casue for duplicate filename.
2. From warning message, minor number '1' is the one of duplicate
fileanme, it meanes the number of dynamic minor is not enough.

The symptom of creating duplicate filename:
------------[ cut here ]------------
     WARNING: at fs/sysfs/dir.c:508 sysfs_add_one+0x7c/0x9c()
     sysfs: cannot create duplicate filename '/dev/char/10:1'
[<c00148b8>] (unwind_backtrace+0x0/0x11c) from
[<c007f828>] (warn_slowpath_common+0x48/0x60)
[<c007f898>] (warn_slowpath_fmt+0x2c/0x3c)
[<c018696c>] (sysfs_add_one+0x7c/0x9c)
[<c01874b4>] (sysfs_do_create_link+0x10c/0x1f8)
[<c03bd6c0>] (device_add+0x1ac/0x5e4)
[<c03be24c>] (device_create_vargs+0x8c/0xd0)
[<c03be2ac>] (device_create+0x1c/0x24)
[<c037c7a4>] (misc_register+0xb4/0x118)
[<c0e30c1c>] (init_log+0x10/0x4c)
[<c0e009d8>] (do_one_initcall+0x90/0x160)
[<c0e00b94>] (kernel_init+0xec/0x1a8)
[<c000f468>] (kernel_thread_exit+0x0/0x8)
---[ end trace da227214a82491b9 ]---

BUG 8889112

Change-Id: I186a945a56fc831f59e19509365a0ae8a481bb2d
Signed-off-by: singhome_lee <singhome_lee@asus.com>
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
d945cb9cce20ac7143c2de8d88b187f62db99bdc (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

Change-Id: I7f5d6d28ff8bcfea9d1cdf9e628d4c5e32d2afe8
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>
tty: hold lock across tty buffer finding and buffer filling

tty_buffer_request_room is well protected, but while after it returns,
 it releases the port->lock. tty->buf.tail might be modified
by either irq handler or other threads. The patch adds more protection
by holding the lock across tty buffer finding and buffer filling.

Signed-off-by: Alek Du <alek.du@intel.com>
Signed-off-by: Xiaobing Tu <xiaobing.tu@intel.com>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CRs-Fixed: 387308
Signed-off-by: Vamsi Krishna <vskrishn@codeaurora.org>
(cherry picked from commit 09236b0fbea5268bce3568d974654f8d9ddb83ec)

Change-Id: If383e12d6e65cfde1e2df2e65df8c3a4c30385ed
Signed-off-by: Sridhar Gujje <sgujje@codeaurora.org>
fat: fix build warning

This fixes a compile warning (unititialized variable) in
the fat filesystem code.

Change-Id: I08d881b6174ebde3ca5708219f5fdef0852847f9
Signed-off-by: Jonas Aberg <jonas.aberg@stericsson.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
netfilter: xt_LOG: don't use xchg() for simple assignment

At least on ia64 the (bogus) use of xchg() here results in the compiler
warning about an unused expression result. As only an assignment is
intended here, convert it to such.

Change-Id: I8082f4014d39b209cd61173a30fa5bb8d8bc43b3
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
sched/nohz: Correctly initialize 'next_balance' in 'nohz' idle balancer

The 'next_balance' field of 'nohz' idle balancer must be initialized
to jiffies. Since jiffies is initialized to negative 300 seconds the
'nohz' idle balancer does not run for the first 300s (5mins) after
bootup. If no new processes are spawed or no idle cycles happen, the
load on the cpus will remain unbalanced for that duration.

Signed-off-by: Diwakar Tundlam <dtundlam@nvidia.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1DD7BFEDD3147247B1355BEFEFE4665237994F30EF@HQMAIL04.nvidia.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>

[xqi@codeaurora.org merge into different file location in 3.0]
Change-Id: I42c41210babb0881150d28d11c2d3fce24fe3a9f
Signed-off-by: Xin Qi <xqi@codeaurora.org>
sched/nohz: Fix logic in nohz_kick_needed

Update the logic so that as long as rq->nr_running is greater than 1,
nohz_kick will be needed, regardless of whether the current CPU has
successfully competed for the first or second cpu spot

Previous logic has the corner case that if current CPU has r_running more than
1, and two other CPUs alreay hold first and econd cpu spot, but they don't
meeting kicking criterial (first cpu has nr_running 1, and second cpu doesn't
have any load), then nohz_kick will not be set correctly.

Change-Id: I30790f22df0a2e90899daa44c67757284dcca25d
Signed-off-by: Xin Qi <xqi@codeaurora.org>
sched/nohz: Fix logic in run_rebalance_domains

If triggered by nohz_balancer_kick, idle_at_tick is not updated
accordingly.  Update myself at this moment right before it is used

Change-Id: I20dd4314159e70f955ffe482160c8867c65c261e
Signed-off-by: Xin Qi <xqi@codeaurora.org>
sched/nohz: Fix logic in trigger_load_balance

Whether we need to kick nohz doesn't depend on current rq->next_balance,
meaning it doesn't depend on the check of previous if condition.

Change-Id: I566011d6341fa7a9a700c834f77e129043eaba11
Signed-off-by: Xin Qi <xqi@codeaurora.org>
panic: Fix a possible deadlock in panic()

panic_lock is meant to ensure that panic processing takes
place only on one cpu; if any of the other cpus encounter
a panic, they will spin waiting to be shut down.

However, this causes a regression in this scenario:

1. Cpu 0 encounters a panic and acquires the panic_lock
   and proceeds with the panic processing.
2. There is an interrupt on cpu 0 that also encounters
   an error condition and invokes panic.
3. This second invocation fails to acquire the panic_lock
   and enters the infinite while loop in panic_smp_self_stop.

Thus all panic processing is stopped, and the cpu is stuck
for eternity in the while(1) inside panic_smp_self_stop.

To address this, disable local interrupts with
local_irq_disable before acquiring the panic_lock. This will
prevent interrupt handlers from executing during the panic
processing, thus avoiding this particular problem.

Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org>
(cherry picked from commit dd58afef43357f265e803c317bbaa91f8c440663)

Change-Id: I5f7ebcf2a028df265a57922b6c959e686a82026a
Signed-off-by: Swetha Basineni <sbasin@codeaurora.org>
sched: Fix select_fallback_rq() vs cpu_active/cpu_online

Commit 5fbd036b55 ("sched: Cleanup cpu_active madness"), which was
supposed to finally sort the cpu_active mess, instead uncovered more.

Since CPU_STARTING is ran before setting the cpu online, there's a
(small) window where the cpu has active,!online.

If during this time there's a wakeup of a task that used to reside on
that cpu select_task_rq() will use select_fallback_rq() to compute an
alternative cpu to run on since we find !online.

select_fallback_rq() however will compute the new cpu against
cpu_active, this means that it can return the same cpu it started out
with, the !online one, since that cpu is in fact marked active.

This results in us trying to scheduling a task on an offline cpu and
triggering a WARN in the IPI code.

The solution proposed by Chuansheng Liu of setting cpu_active in
set_cpu_online() is buggy, firstly not all archs actually use
set_cpu_online(), secondly, not all archs call set_cpu_online() with
IRQs disabled, this means we would introduce either the same race or
the race from fd8a7de17 ("x86: cpu-hotplug: Prevent softirq wakeup on
wrong CPU") -- albeit much narrower.

[ By setting online first and active later we have a window of
  online,!active, fresh and bound kthreads have task_cpu() of 0 and
  since cpu0 isn't in tsk_cpus_allowed() we end up in
  select_fallback_rq() which excludes !active, resulting in a reset
  of ->cpus_allowed and the thread running all over the place. ]

The solution is to re-work select_fallback_rq() to require active
_and_ online. This makes the active,!online case work as expected,
OTOH archs running CPU_STARTING after setting online are now
vulnerable to the issue from fd8a7de17 -- these are alpha and
blackfin.

Reported-by: Chuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: linux-alpha@vger.kernel.org
Link: http://lkml.kernel.org/n/tip-hubqk1i10o4dpvlm06gq7v6j@git.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>

Conflicts:

	kernel/sched/core.c

Change-Id: Ib22f61c28494bcccc40f9f7fa3812c72e5528203
bdi: use deferable timer for sync_supers task

sync_supers task currently wakes up periodically for superblock
writeback. This hurts power on battery driven devices. This patch
turns this housekeeping timer into a deferable timer so that it
does not fire when system is really idle.

CRs-Fixed: 353700
Signed-off-by: Yong Wang <yong.y.wang@intel.com>
Signed-off-by: Xia Wu <xia.wu@intel.com>
Signed-off-by: Krishna Vanka <kvanka@codeaurora.org>
(cherry picked from commit f398f30d1f34632d3c96758b5b19e65b056af072)

Change-Id: I6ec6310d66c0d014adf0f41e75cd4c48c233f83d
Signed-off-by: Sridhar Gujje <sgujje@codeaurora.org>
cpufreq: Backport from samsung msm8660

Change-Id: Ief257a9eefa2518d56e5a07baf749b58b389e308
msm: display: Backport from samsung msm8660

Change-Id: I5bd8a644e396c0060bb80e90355dbc92c9d13949
msm: kgsl: Backport from samsung msm8660

Change-Id: Ib4be6324b2917c3eac463dc57d2e88cac5e4c96d
ASoc: msm: Backport from samsung msm8660

Change-Id: Ia01a8225b3cd40844c41d50fef2f5a35d35005c8
lowmemorykiller: Backport from samsung msm8660

Change-Id: Ia59d11e2b89448045bfa103de3d364e624d9179d
gpu: ion: Add dummy msm_ion header file

The msm specific parts of ion.h are being moved into a new header
file. For now, add a dummy header file to get clients transitioned
over.

Change-Id: Iac039678e1c3f15d87e67aa667f7e9883ca16669
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
kernel: Includes initial Pantech structure

Change-Id: I1107198ae54d0cdec68b56930444062007734046
msm: Makefile: Mod to replace original source with our own model.

This modification allows to replace some files in the kernel with our own model.
And add modifications without "interfering" in the original source.

Based on Samsung's kernel msm8660.

Change-Id: I2a7031e23512223246bce4aeb0352a3f39ef7bb7