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: Ie0b03989fa8cfd6ffe40d1f770044fe7447dda05
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.4: output_lock is a member of struct tty_struct]

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
fs/super.c: sync ro remount after blocking writers

Move sync_filesystem() after sb_prepare_remount_readonly().  If writers
sneak in anywhere from sync_filesystem() to sb_prepare_remount_readonly()
it can cause inodes to be dirtied and writeback to occur well after
sys_mount() has completely successfully.

This was spotted by corrupted ubifs filesystems on reboot, but appears
that it can cause issues with any filesystem using writeback.

CRs-Fixed: 627559
Change-Id: Ib417b59d39210aab2de4e5ae48b18129e8bc3e26
Cc: Artem Bityutskiy <dedekind1@gmail.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
CC: Richard Weinberger <richard@nod.at>
Co-authored-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Andrew Ruder <andrew.ruder@elecsyscorp.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Git-commit: 807612db2f9940b9fa6deaef054eb16d51bd3e00
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mako_hotplug: clean up a little bit.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
cpufreq: interactive: Move definition of cpufreq_gov_interactive downwards

This moves definition of cpufreq_gov_interactive towards the bottom of file, so
that we don't have to add prototype of cpufreq_governor_interactive() in the
beginning of file.

Change-Id: I04bd1004954eb36502c5cd7e35d3d7274cddaf95
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Git-commit: e50d640cacfe61e69f1b4fa92fa0174c688e919c
Git-Repo: https://android.googlesource.com/kernel/common.git
[junjiew@codeaurora.org: Resolve merge conflicts]
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
cpufreq: interactive: fix compiling warnings

The gcc warns like:

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

It was introduced by commit cf0fad49d17cb8273ce555dd5b7afab67d7923bf.

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 cf0fad49d17cb8273ce555dd5b7afab67d7923bf wants.

Change-Id: Ifed1cef6d6a31c3ed23dad03a567b3b9eddf3a57
Signed-off-by: Chih-Wei Huang <cwhuang@android-x86.org>
Git-commit: 0715d10b9e6c04327adb189e13ecd6a3c2df48ce
Git-Repo: https://android.googlesource.com/kernel/common.git
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
cpufreq: interactive: prevent the target_freq to be boosted on thread migration if the source and target cpu are the same. Also don't set the floor_freq and time on thread migration, as we don't want it to go through the min_sample_time code routine, because that's used for more sustained hispeed_freq boosts.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mako_hotplug: we should care about very high load spikes so when the load
is 100% the core that is next in line is onlined, no questions asked.
It won't go through the 1s minimum time for a core to be online before
hotplug though.

hackbench -p -T:
Before: 1.816sec
After: 0.917sec

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mako_hotplug: code revision

  * clean it up to remove clutter on the main function
  * move all the hard-work to the cpu_revive and cpu_smash wrappers
for code clarity
  * for load spikes instead of relying on a single sample on 100% load
the counter needs to be >= 2 to avoid spurious online calls

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mako_hotplug: set earlier early_suspend level

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
sched: Remove get_online_cpus() usage

Remove get_online_cpus() usage from the scheduler; there's 4 sites that
use it:

 - sched_init_smp(); where its completely superfluous since we're in
   'early' boot and there simply cannot be any hotplugging.

 - sched_getaffinity(); we already take a raw spinlock to protect the
   task cpus_allowed mask, this disables preemption and therefore
   also stabilizes cpu_online_mask as that's modified using
   stop_machine. However switch to active mask for symmetry with
   sched_setaffinity()/set_cpus_allowed_ptr(). We guarantee active
   mask stability by inserting sync_rcu/sched() into _cpu_down.

 - sched_setaffinity(); we don't appear to need get_online_cpus()
   either, there's two sites where hotplug appears relevant:
    * cpuset_cpus_allowed(); for the !cpuset case we use possible_mask,
      for the cpuset case we hold task_lock, which is a spinlock and
      thus for mainline disables preemption (might cause pain on RT).
    * set_cpus_allowed_ptr(); Holds all scheduler locks and thus has
      preemption properly disabled; also it already deals with hotplug
      races explicitly where it releases them.

 - migrate_swap(); we can make stop_two_cpus() do the heavy lifting for
   us with a little trickery. By adding a sync_sched/rcu() after the
   CPU_DOWN_PREPARE notifier we can provide preempt/rcu guarantees for
   cpu_active_mask. Use these to validate that both our cpus are active
   when queueing the stop work before we queue the stop_machine works
   for take_cpu_down().

CRs-fixed: 647141
Change-Id: Id41e66659574f716de0e7c29f477e56a86db9404
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Cc: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Rik van Riel <riel@redhat.com>
Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Link: http://lkml.kernel.org/r/20131011123820.GV3081@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Git-commit: 6acce3ef84520537f8a09a12c9ddbe814a584dd2
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
[kaushalk@codeaurora.org: get_online_cpus has only 3 sites of usage in
 kernel/sched/core.c of msm-3.10 so migrate_swap changes are not
 applicable here. stop_two_cpus related change is not applicable to
 msm-3.10, so skip it.]
Signed-off-by: Kaushal Kumar <kaushalk@codeaurora.org>

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
sched: Fix endless sync_sched/rcu() loop inside _cpu_down()

Commit 6acce3ef8:

	sched: Remove get_online_cpus() usage

tries to do sync_sched/rcu() inside _cpu_down() but triggers:

	INFO: task swapper/0:1 blocked for more than 120 seconds.
	...
	[<ffffffff811263dc>] synchronize_rcu+0x2c/0x30
	[<ffffffff81d1bd82>] _cpu_down+0x2b2/0x340
	...

It was caused by that in the rcu boost case we rely on smpboot thread to
finish the rcu callback, which has already been parked before sync in here
and leads to the endless sync_sched/rcu().

This patch exchanges the sequence of smpboot_park_threads() and
sync_sched/rcu() to fix the bug.

CRs-fixed: 647141
Change-Id: Ia8b325d7c3c778f428d9fb51271977c849df32ad
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Tested-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Michael Wang <wangyun@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/5282EDC0.6060003@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Git-commit: 106dd5afde3cd10db7e1370b6ddc77f0b2496a75
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Kaushal Kumar <kaushalk@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
sched: Remove extra put_online_cpus() inside sched_setaffinity()

Commit 6acce3ef8:

	sched: Remove get_online_cpus() usage

has left one extra put_online_cpus() inside sched_setaffinity(),
remove it to fix the WARN:

   ------------[ cut here ]------------
   WARNING: CPU: 0 PID: 3166 at kernel/cpu.c:84 put_online_cpus+0x43/0x70()
   ...
   [<ffffffff810c3fef>] put_online_cpus+0x43/0x70 [
   [<ffffffff810efd59>] sched_setaffinity+0x7d/0x1f9 [
   ...

CRs-fixed: 647141
Change-Id: I33f799f30a963db3e9459832832e9c786931c8c2
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Tested-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Michael Wang <wangyun@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/526DD0EE.1090309@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Git-commit: ac9ff7997b6f2b31949dcd2495ac671fd9ddc990
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Kaushal Kumar <kaushalk@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
msm: camera: fix null pointer
Prevent a Kernel panic that can be triggered after shooting an
HDR picture.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
msm: mdp: Free secure memory based on pipe config

When there is no secure pipe configured, we can unmap secure
memory instead of relying on unset with secure flag set from
userspace.

Bug: 11857675

Signed-off-by: Naseer Ahmed <naseer@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
seq_file: always update file->f_pos in seq_lseek()

This issue was first pointed out by Jiaxing Wang several months ago, but no
further comments:
https://lkml.org/lkml/2013/6/29/41

As we know pread() does not change f_pos, so after pread(), file->f_pos
and m->read_pos become different. And seq_lseek() does not update file->f_pos
if offset equals to m->read_pos, so after pread() and seq_lseek()(lseek to
m->read_pos), then a subsequent read may read from a wrong position, the
following program produces the problem:

    char str1[32] = { 0 };
    char str2[32] = { 0 };
    int poffset = 10;
    int count = 20;

    /*open any seq file*/
    int fd = open("/proc/modules", O_RDONLY);

    pread(fd, str1, count, poffset);
    printf("pread:%s\n", str1);

    /*seek to where m->read_pos is*/
    lseek(fd, poffset+count, SEEK_SET);

    /*supposed to read from poffset+count, but this read from position 0*/
    read(fd, str2, count);
    printf("read:%s\n", str2);

out put:
pread:
 ck_netbios_ns 12665
read:
 nf_conntrack_netbios

/proc/modules:
nf_conntrack_netbios_ns 12665 0 - Live 0xffffffffa038b000
nf_conntrack_broadcast 12589 1 nf_conntrack_netbios_ns, Live 0xffffffffa0386000

So we always update file->f_pos to offset in seq_lseek() to fix this issue.

cherry-picked from https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/fs/seq_file.c?id=05e16745c0c471bba313961b605b6da3b21a853d

Signed-off-by: Jiaxing Wang <hello.wjx@gmail.com>
Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Conflicts:
	fs/seq_file.c

Change-Id: If419b92498e2c3e08669a4342e9b9ebf99ad3768
Signed-off-by: Devin Kim <dojip.kim@lge.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
seq_file: always clear m->count when we free m->buf

Once we'd freed m->buf, m->count should become zero - we have no valid
contents reachable via m->buf.

cherry-picked from https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/fs/seq_file.c?id=801a76050bcf8d4e500eb8d048ff6265f37a61c8

Change-Id: I4c1d3e69db4ecf5362e2a5d05bfd7db754dc6dc6
Reported-by: Charley (Hao Chuan) Chu <charley.chu@broadcom.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Devin Kim <dojip.kim@lge.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
fs/dcache.c: Fix the too small buffer for dname

temp[64] is used for internal temporary buffer in dynamic_dname().
This is for dname. But It's too small. dname's size may be > 64.
In that case, it returns as -ENAMETOOLONG. So Increase the buffer size
to 256 for avoiding this issue.

The following was caused by the small buffer.
WARNING: at /kernel/mm/page_alloc.c:2470 __alloc_pages_nodemask+0x24c/0x938()
CPU: 2 PID: 505 Comm: android.bg Not tainted 3.10.0-g2f73780-00003-g2ff41d9-dirty #13
[<c010ba3c>] (unwind_backtrace+0x0/0x11c) from [<c0109cac>] (show_stack+0x10/0x14)
[<c0109cac>] (show_stack+0x10/0x14) from [<c01939a0>] (warn_slowpath_common+0x48/0x68)
[<c01939a0>] (warn_slowpath_common+0x48/0x68) from [<c0193a7c>] (warn_slowpath_null+0x18/0x20)
[<c0193a7c>] (warn_slowpath_null+0x18/0x20) from [<c0222454>] (__alloc_pages_nodemask+0x24c/0x938)
[<c0222454>] (__alloc_pages_nodemask+0x24c/0x938) from [<c0222b50>] (__get_free_pages+0x10/0x24)
[<c0222b50>] (__get_free_pages+0x10/0x24) from [<c024faf8>] (kmalloc_order_trace+0x24/0xf0)
[<c024faf8>] (kmalloc_order_trace+0x24/0xf0) from [<c024fe20>] (__kmalloc+0x30/0x244)
[<c024fe20>] (__kmalloc+0x30/0x244) from [<c02723c8>] (seq_read+0x270/0x464)
[<c02723c8>] (seq_read+0x270/0x464) from [<c0256a18>] (vfs_read+0xa4/0x134)
[<c0256a18>] (vfs_read+0xa4/0x134) from [<c0256de8>] (SyS_read+0x38/0x68)
[<c0256de8>] (SyS_read+0x38/0x68) from [<c0106140>] (ret_fast_syscall+0x0/0x30)

Change-Id: I74f5217ba3c4be73e91f33f900f1f0c26810cc05
Signed-off-by: Devin Kim <dojip.kim@lge.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
SELinux: include definition of new capabilities

The kernel has added CAP_WAKE_ALARM and CAP_EPOLLWAKEUP.  We need to
define these in SELinux so they can be mediated by policy.

Change-Id: I8a3e0db15ec5f4eb05d455a57e8446a8c2b484c2
Signed-off-by: Eric Paris <eparis@redhat.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
[sds: rename epollwakeup to block_suspend to match upstream merge]
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
(cherry picked from commit c6a020c889756568d0e2f3ab0c1f04ad9fcb320c)

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
tcp: add a sysctl to config the tcp_default_init_rwnd

The default initial rwnd is hardcoded to 10.

Now we allow it to be controlled via
  /proc/sys/net/ipv4/tcp_default_init_rwnd
which limits the values from 3 to 100

This is somewhat needed because ipv6 routes are
autoconfigured by the kernel.

See "An Argument for Increasing TCP's Initial Congestion Window"
in https://developers.google.com/speed/articles/tcp_initcwnd_paper.pdf

Change-Id: I386b2a9d62de0ebe05c1ebe1b4bd91b314af5c54
Signed-off-by: JP Abgrall <jpa@google.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
ping: prevent NULL pointer dereference on write to msg_name

A plain read() on a socket does set msg->msg_name to NULL. So check for
NULL pointer first.

[Backport of net-next cf970c002d270c36202bd5b9c2804d3097a52da0]

Bug: 12780426
Change-Id: Ida66892d359d2dfbb32803d8b0872bf8c0bb3865
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
(cherry picked from commit 9ad40c7df302ef477a3359dc02cc4b1834c948fc)
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>