UPSTREAM: ANDROID: binder: remove waitqueue when thread exits.

binder_poll() passes the thread->wait waitqueue that
can be slept on for work. When a thread that uses
epoll explicitly exits using BINDER_THREAD_EXIT,
the waitqueue is freed, but it is never removed
from the corresponding epoll data structure. When
the process subsequently exits, the epoll cleanup
code tries to access the waitlist, which results in
a use-after-free.

Prevent this by using POLLFREE when the thread exits.

(cherry picked from commit f5cb779ba16334b45ba8946d6bfa6d9834d1527f)

Change-Id: Ib34b1cbb8ab2192d78c3d9956b2f963a66ecad2e
Signed-off-by: Martijn Coenen <maco@android.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Cc: stable <stable@vger.kernel.org> # 4.14
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ANDROID: binder: Remove obsolete proc waitqueue.

It was no longer being used.

Change-Id: I7fc42b76f688a459ad990f59fbd7006b96bb91a6
Signed-off-by: Martijn Coenen <maco@android.com>

UPSTREAM: android: binder: fix type mismatch warning

Allowing binder to expose the 64-bit API on 32-bit kernels caused a
build warning:

drivers/android/binder.c: In function
'binder_transaction_buffer_release':
drivers/android/binder.c:2220:15: error: cast to pointer from integer of
different size [-Werror=int-to-pointer-cast]
    fd_array = (u32 *)(parent_buffer + fda->parent_offset);
               ^
drivers/android/binder.c: In function 'binder_translate_fd_array':
drivers/android/binder.c:2445:13: error: cast to pointer from integer of
different size [-Werror=int-to-pointer-cast]
  fd_array = (u32 *)(parent_buffer + fda->parent_offset);
             ^
drivers/android/binder.c: In function 'binder_fixup_parent':
drivers/android/binder.c:2511:18: error: cast to pointer from integer of
different size [-Werror=int-to-pointer-cast]

This adds extra type casts to avoid the warning.

However, there is another problem with the Kconfig option: turning
it on or off creates two incompatible ABI versions, a kernel that
has this enabled cannot run user space that was built without it
or vice versa. A better solution might be to leave the option hidden
until the binder code is fixed to deal with both ABI versions.

Fixes: e8d2ed7db7c3 ("Revert "staging: Fix build issues with new binder
API"")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 1c363eaece2752c5f8b1b874cb4ae435de06aa66)

Change-Id: Id09185a6f86905926699e92a2b30201b8a5e83e5

ANDROID: binder: clarify deferred thread work.

Rename the function to more accurately reflect what
it does, and add a comment explaining why we use it.

Change-Id: I8d011c017dfc6e24b5b54fc462578f8e153e5926
Signed-off-by: Martijn Coenen <maco@android.com>

ANDROID: binder: Add thread->process_todo flag.

This flag determines whether the thread should currently
process the work in the thread->todo worklist.

The prime usecase for this is improving the performance
of synchronous transactions: all synchronous transactions
post a BR_TRANSACTION_COMPLETE to the calling thread,
but there's no reason to return that command to userspace
right away - userspace anyway needs to wait for the reply.

Likewise, a synchronous transaction that contains a binder
object can cause a BC_ACQUIRE/BC_INCREFS to be returned to
userspace; since the caller must anyway hold a strong/weak
ref for the duration of the call, postponing these commands
until the reply comes in is not a problem.

Note that this flag is not used to determine whether a
thread can handle process work; a thread should never pick
up process work when thread work is still pending.

Before patch:
------------------------------------------------------------------
Benchmark                           Time           CPU Iterations
------------------------------------------------------------------
BM_sendVec_binderize/4          45959 ns      20288 ns      34351
BM_sendVec_binderize/8          45603 ns      20080 ns      34909
BM_sendVec_binderize/16         45528 ns      20113 ns      34863
BM_sendVec_binderize/32         45551 ns      20122 ns      34881
BM_sendVec_binderize/64         45701 ns      20183 ns      34864
BM_sendVec_binderize/128        45824 ns      20250 ns      34576
BM_sendVec_binderize/256        45695 ns      20171 ns      34759
BM_sendVec_binderize/512        45743 ns      20211 ns      34489
BM_sendVec_binderize/1024       46169 ns      20430 ns      34081

After patch:
------------------------------------------------------------------
Benchmark                           Time           CPU Iterations
------------------------------------------------------------------
BM_sendVec_binderize/4          42939 ns      17262 ns      40653
BM_sendVec_binderize/8          42823 ns      17243 ns      40671
BM_sendVec_binderize/16         42898 ns      17243 ns      40594
BM_sendVec_binderize/32         42838 ns      17267 ns      40527
BM_sendVec_binderize/64         42854 ns      17249 ns      40379
BM_sendVec_binderize/128        42881 ns      17288 ns      40427
BM_sendVec_binderize/256        42917 ns      17297 ns      40429
BM_sendVec_binderize/512        43184 ns      17395 ns      40411
BM_sendVec_binderize/1024       43119 ns      17357 ns      40432

Signed-off-by: Martijn Coenen <maco@android.com>
Change-Id: Ia70287066d62aba64e98ac44ff1214e37ca75693

FROMLIST: android: binder: Fix null ptr dereference in debug msg

(from https://patchwork.kernel.org/patch/9990323/)

Don't access next->data in kernel debug message when the
next buffer is null.

Bug: 36007193
Change-Id: Ib8240d7e9a7087a2256e88c0ae84b9df0f2d0224
Acked-by: Arve Hjønnevåg <arve@android.com>
Signed-off-by: Sherry Yang <sherryy@android.com>

ANDROID: binder: fix node sched policy calculation

We should use FLAT_BINDER_FLAG_SCHED_POLICY_MASK as
the mask to calculate sched policy.

Change-Id: Ic252fd7c68495830690130d792802c02f99fc8fc
Signed-off-by: Ganesh Mahendran <opensource.ganesh@gmail.com>

ANDROID: binder: init desired_prio.sched_policy before use it

In function binder_transaction_priority(), we access
desired_prio before initialzing it.

This patch fix this.

Change-Id: I9d14d50f9a128010476a65b52631630899a44633
Signed-off-by: Ganesh Mahendran <opensource.ganesh@gmail.com>

ANDROID: binder: fix transaction leak.

If a call to put_user() fails, we failed to
properly free a transaction and send a failed
reply (if necessary).

Bug: 63117588
Test: binderLibTest

Change-Id: Ia98db8cd82ce354a4cdc8811c969988d585c7e31
Signed-off-by: Martijn Coenen <maco@android.com>

ANDROID: binder: Add tracing for binder priority inheritance.

Bug: 34461621
Change-Id: I5ebb1c0c49fd42a89ee250a1d70221f767c82c7c
Signed-off-by: Martijn Coenen <maco@google.com>

FROMLIST: binder: fix use-after-free in binder_transaction()

(from https://patchwork.kernel.org/patch/9978801/)

User-space normally keeps the node alive when creating a transaction
since it has a reference to the target. The local strong ref keeps it
alive if the sending process dies before the target process processes
the transaction. If the source process is malicious or has a reference
counting bug, this can fail.

In this case, when we attempt to decrement the node in the failure
path, the node has already been freed.

This is fixed by taking a tmpref on the node while constructing
the transaction. To avoid re-acquiring the node lock and inner
proc lock to increment the proc's tmpref, a helper is used that
does the ref increments on both the node and proc.

Bug: 66899329
Change-Id: Iad40e1e0bccee88234900494fb52a510a37fe8d7
Signed-off-by: Todd Kjos <tkjos@google.com>

FROMLIST: binder: fix an ret value override

(from https://patchwork.kernel.org/patch/9939409/)

commit 372e3147df70 ("binder: guarantee txn complete / errors delivered
in-order") incorrectly defined a local ret value.  This ret value will
be invalid when out of the if block

Change-Id: If7bd963ac7e67d135aa949133263aac27bf15d1a
Signed-off-by: Xu YiPing <xuyiping@hislicon.com>
Signed-off-by: Todd Kjos <tkjos@google.com>

FROMLIST: binder: fix memory corruption in binder_transaction binder

(from https://patchwork.kernel.org/patch/9939405/)

commit 7a4408c6bd3e ("binder: make sure accesses to proc/thread are
safe") made a change to enqueue tcomplete to thread->todo before
enqueuing the transaction. However, in err_dead_proc_or_thread case,
the tcomplete is directly freed, without dequeued. It may cause the
thread->todo list to be corrupted.

So, dequeue it before freeing.

Bug: 65333488
Change-Id: Id063a4db18deaa634f4d44aa6ebca47bea32537a
Signed-off-by: Xu YiPing <xuyiping@hisilicon.com>
Signed-off-by: Todd Kjos <tkjos@google.com>

FROMLIST: android: binder: Move buffer out of area shared with user space

(from https://patchwork.kernel.org/patch/9928607/)

Binder driver allocates buffer meta data in a region that is mapped
in user space. These meta data contain pointers in the kernel.

This patch allocates buffer meta data on the kernel heap that is
not mapped in user space, and uses a pointer to refer to the data mapped.

Also move alloc->buffers initialization from mmap to init since it's
now used even when mmap failed or was not called.

Bug: 36007193
Change-Id: Id5136048bdb7b796f59de066de7ea7df410498f5
Signed-off-by: Sherry Yang <sherryy@android.com>

FROMLIST: android: binder: Add allocator selftest

(from https://patchwork.kernel.org/patch/9928609/)

binder_alloc_selftest tests that alloc_new_buf handles page allocation and
deallocation properly when allocate and free buffers. The test allocates 5
buffers of various sizes to cover all possible page alignment cases, and
frees the buffers using a list of exhaustive freeing order.

Test: boot the device with ANDROID_BINDER_IPC_SELFTEST config option
enabled. Allocator selftest passes.

Bug: 36007193
Change-Id: I2fe396232b7dfe4bbc50bdba99ca0de9be63cc37
Signed-off-by: Sherry Yang <sherryy@android.com>

FROMLIST: android: binder: Refactor prev and next buffer into a helper function

(from https://patchwork.kernel.org/patch/9928605/)

Use helper functions buffer_next and buffer_prev instead
of list_entry to get the next and previous buffers.

Bug: 36007193
Change-Id: I422dce84afde3d2138a6d976593b109a9cc49003
Signed-off-by: Sherry Yang <sherryy@android.com>

FROMLIST: binder: add more debug info when allocation fails.

(from https://patchwork.kernel.org/patch/9817797/)

Bug: 36088202
Test: tested manually
Change-Id: Ib526a9c375e6136669b72f341e0b54d896fd1cec
Signed-off-by: Martijn Coenen <maco@android.com>
Signed-off-by: Siqi Lin <siqilin@google.com>

gen_init_cpio: avoid NULL pointer dereference and rework env expanding

getenv() may return NULL if given environment variable does not exist
which leads to NULL dereference when calling strncat.

Besides that, the environment variable name was copied to a temporary
env_var buffer, but this copying can be avoided by simply using the input
string.

Lastly, the whole loop can be greatly simplified by using the snprintf
function instead of the playing with strncat.

 By the way, the current implementation allows a recursive variable
 expansion, as in:

   $ echo 'out ${A} out ' | A='a ${B} a' B=b /tmp/a
   out a b a out

 I'm assuming this is just a side effect and not a conscious decision
 (especially as this may lead to infinite loop), but I didn't want to
 change this behaviour without consulting.

 If the current behaviour is deamed incorrect, I'll be happy to send
 a patch without recursive processing.

Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Jesper Juhl <jj@codesealer.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Change-Id: I575a65c6261288ffe5c1166dc40271fbbc4d11cf

scripts: remove unused function in sortextable.c

Change-Id: Ifc81f354582e43d71cfe8a7f0ce4a5e50778bd81
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Acked-by: David Daney <david.daney@cavium.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>

kconfig: Avoid format overflow warning from GCC 8.1

In file included from scripts/kconfig/zconf.tab.c:2485:
scripts/kconfig/confdata.c: In function ‘conf_write’:
scripts/kconfig/confdata.c:773:22: warning: ‘%s’ directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
  sprintf(newname, "%s%s", dirname, basename);
                      ^~
scripts/kconfig/confdata.c:773:19: note: assuming directive output of 7 bytes
  sprintf(newname, "%s%s", dirname, basename);
                   ^~~~~~
scripts/kconfig/confdata.c:773:2: note: ‘sprintf’ output 1 or more bytes (assuming 4104) into a destination of size 4097
  sprintf(newname, "%s%s", dirname, basename);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
scripts/kconfig/confdata.c:776:23: warning: ‘.tmpconfig.’ directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
   sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid());
                       ^~~~~~~~~~~
scripts/kconfig/confdata.c:776:3: note: ‘sprintf’ output between 13 and 4119 bytes into a destination of size 4097
   sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid());
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Increase the size of tmpname and newname to make GCC happy.

Change-Id: Ie3a8689e3982734be63d15e1ad98416ab13d4b48
Cc: stable@vger.kernel.org
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

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

Change-Id: I50749f95f1e212ed8c913547bffed14f847b8929

Revert "Decon update max_win to 7"

* we only use 3 windows

This reverts commit 7f52706418f42c16f384496aecbf961c11299a4c.

minimal port of grsecurity's DENYUSB feature

universal7580: Enable CT target for iptables

netfilter: ebtables: fix erroneous reject of last rule

The last rule in the blob has next_entry offset that is same as total size.
This made "ebtables32 -A OUTPUT -d de:ad:be:ef:01:02" fail on 64 bit kernel.

Change-Id: Idaf15f1b3ad0aabdff3e995131a0fdd8bffb1e4a
Fixes: b71812168571fa ("netfilter: ebtables: CONFIG_COMPAT: don't trust userland offsets")
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Jan Altensen <info@stricted.net>

nf_conntrack: Null pointer check added prior deleting sip node

Prior to null pointer check, SIP node was deleted from the list
a null pointer check is added to confront the exception.

Bug: 111529827
Change-Id: Ia12fa468eed7d1a91fad96840fa27cb0e4e208a8
Acked-by: Rishav LNU <rna@qti.qualcomm.com>
Signed-off-by: Utkarsh Saxena <usaxena@codeaurora.org>
Signed-off-by: Jan Altensen <info@stricted.net>

netfilter: Changes to handle segmentation in SIP ALG

Linux Kernel SIP ALG did not handle Segmented TCP Packets
because of which SIP communication could not be established
for some clients. This change fixes that issue.

Change-Id: I8c77322f69cf4d9ad4c7b4971da924ffd585dea0
Signed-off-by: Ravinder Konka <rkonka@codeaurora.org>
Signed-off-by: Tyler Wear <twear@codeaurora.org>
Signed-off-by: Jan Altensen <info@stricted.net>

locking: Remove atomicy checks from {READ,WRITE}_ONCE

The fact that volatile allows for atomic load/stores is a special case
not a requirement for {READ,WRITE}_ONCE(). Their primary purpose is to
force the compiler to emit load/stores _once_.

Change-Id: I86e34ae44535576859d66411208e7c8a13c0ec3a
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Git-commit: 7bd3e239d6c6d1cad276e8f130b386df4234dcd7
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Trilok Soni <tsoni@codeaurora.org>

UPSTREAM: include/linux/mm.h: add PAGE_ALIGNED() helper

To test whether an address is aligned to PAGE_SIZE.

Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 0fa73b86ef0797ca4fde5334117ca0b330f08030)

Bug: 36007193
Change-Id: I7e912bb0dbd8c9737fb13c5b48acb54ee39dd5fc

path_openat(): fix double fput()

[ Upstream commit f15133df088ecadd141ea1907f2c96df67c729f0 ]

path_openat() jumps to the wrong place after do_tmpfile() - it has
already done path_cleanup() (as part of path_lookupat() called by
do_tmpfile()), so doing that again can lead to double fput().

Change-Id: Ia74c130ae5e379b512532c0feebea871b5f73668
Cc: stable@vger.kernel.org # v3.11+
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

allow build_open_flags() to return an error

Change-Id: I6e900fc3facf5a3febefe138fea7db493bc383d8
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

do_last(): fix missing checks for LAST_BIND case

/proc/self/cwd with O_CREAT should fail with EISDIR.  /proc/self/exe, OTOH,
should fail with ENOTDIR when opened with O_DIRECTORY.

Change-Id: I01c85a6a3894c6854c604f192f221175edc19867
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

uapi: Define __BITS_PER_LONG based on compiler target

* We may compile 32-bit ARM code against these kernel headers in many
  situations, so provide a compiler-defined method of obtaining the width
  of long.

Change-Id: Iac5e48200d70f1258ab3caca1a8f1eb6e8f7f2d3

fs: allow open(dir, O_TMPFILE|..., 0) with mode 0

The man page for open(2) indicates that when O_CREAT is specified, the
'mode' argument applies only to future accesses to the file:

Note that this mode applies only to future accesses of the newly
created file; the open() call that creates a read-only file
may well return a read/write file descriptor.

The man page for open(2) implies that 'mode' is treated identically by
O_CREAT and O_TMPFILE.

O_TMPFILE, however, behaves differently:

int fd = open("/tmp", O_TMPFILE | O_RDWR, 0);
assert(fd == -1);
assert(errno == EACCES);

int fd = open("/tmp", O_TMPFILE | O_RDWR, 0600);
assert(fd > 0);

For O_CREAT, do_last() sets acc_mode to MAY_OPEN only:

if (*opened & FILE_CREATED) {
/* Don't check for write permission, don't truncate */
open_flag &= ~O_TRUNC;
will_truncate = false;
acc_mode = MAY_OPEN;
path_to_nameidata(path, nd);
goto finish_open_created;
}

But for O_TMPFILE, do_tmpfile() passes the full op->acc_mode to
may_open().

This patch lines up the behavior of O_TMPFILE with O_CREAT. After the
inode is created, may_open() is called with acc_mode = MAY_OPEN, in
do_tmpfile().

A different, but related glibc bug revealed the discrepancy:
https://sourceware.org/bugzilla/show_bug.cgi?id=17523

The glibc lazily loads the 'mode' argument of open() and openat() using
va_arg() only if O_CREAT is present in 'flags' (to support both the 2
argument and the 3 argument forms of open; same idea for openat()).
However, the glibc ignores the 'mode' argument if O_TMPFILE is in
'flags'.

On x86_64, for open(), it magically works anyway, as 'mode' is in
RDX when entering open(), and is still in RDX on SYSCALL, which is where
the kernel looks for the 3rd argument of a syscall.

But openat() is not quite so lucky: 'mode' is in RCX when entering the
glibc wrapper for openat(), while the kernel looks for the 4th argument
of a syscall in R10. Indeed, the syscall calling convention differs from
the regular calling convention in this respect on x86_64. So the kernel
sees mode = 0 when trying to use glibc openat() with O_TMPFILE, and
fails with EACCES.

Change-Id: If41388897576291d3cfb0515fd71efb70bf2b3df
Signed-off-by: Eric Rannaud <e@nanocritical.com>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

fs: Fix file mode for O_TMPFILE

O_TMPFILE, like O_CREAT, should respect the requested mode and should
create regular files.

This fixes two bugs: O_TMPFILE required privilege (because the mode
ended up as 000) and it produced bogus inodes with no type.

Change-Id: I4d045c5b3a07e3d3114897c5f3d2448ab6c3a0a5
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

vfs: add missing check for __O_TMPFILE in fcntl_init()

As comment in include/uapi/asm-generic/fcntl.h described, when
introducing new O_* bits, we need to check its uniqueness in
fcntl_init().  But __O_TMPFILE bit is missing.  So fix it.

Change-Id: I372d41d2bc15b007595eaf763e200c4c06de177f
Signed-off-by: Zheng Liu <wenqing.lz@taobao.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

allow O_TMPFILE to work with O_WRONLY

Change-Id: If75a4f1b8f1ba485f6073be4058b59126cef034b
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Safer ABI for O_TMPFILE

[suggested by Rasmus Villemoes] make O_DIRECTORY | O_RDWR part of O_TMPFILE;
that will fail on old kernels in a lot more cases than what I came up with.
And make sure O_CREAT doesn't get there...

Change-Id: I4818563d79ca1abf9ea99f5ccea9317eb2f3b678
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

it's still short a few helpers, but infrastructure should be OK now...

Change-Id: I9e003fabb858fd901fd922cd891ca29966ccdf3a
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

net: core: add UID to flows, rules, and routes

- Define a new FIB rule attributes, FRA_UID_RANGE, to describe a
  range of UIDs.
- Define a RTA_UID attribute for per-UID route lookups and dumps.
- Support passing these attributes to and from userspace via
  rtnetlink. The value INVALID_UID indicates no UID was
  specified.
- Add a UID field to the flow structures.

[Backport of net-next 622ec2c9d52405973c9f1ca5116eb1c393adfc7d]

Bug: 16355602
Change-Id: I7e3ab388ed862c4b7e39dc8b0209d977cb1129ac
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Revert "net: core: Support UID-based routing."

This reverts commit 99a6ea48b591877d1cd6a51732c40a1d5321d961.

Revert "Handle 'sk' being NULL in UID-based routing."

This reverts commit 455b09d66a9ccfc572497ae88375ae343ff9ae66.

Change-Id: I1d95864d8b48ae3ca418cfd790cfd62c07f54f66

ipv4, fib: pass LOOPBACK_IFINDEX instead of 0 to flowi4_iif
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

As suggested by Julian:

Simply, flowi4_iif must not contain 0, it does not
look logical to ignore all ip rules with specified iif.

because in fib_rule_match() we do:

        if (rule->iifindex && (rule->iifindex != fl->flowi_iif))
                goto out;

flowi4_iif should be LOOPBACK_IFINDEX by default.

We need to move LOOPBACK_IFINDEX to include/net/flow.h:

1) It is mostly used by flowi_iif

2) Fix the following compile error if we use it in flow.h
by the patches latter:

In file included from include/linux/netfilter.h:277:0,
                 from include/net/netns/netfilter.h:5,
                 from include/net/net_namespace.h:21,
                 from include/linux/netdevice.h:43,
                 from include/linux/icmpv6.h:12,
                 from include/linux/ipv6.h:61,
                 from include/net/ipv6.h:16,
                 from include/linux/sunrpc/clnt.h:27,
                 from include/linux/nfs_fs.h:30,
                 from init/do_mounts.c:32:
include/net/flow.h: In function ‘flowi4_init_output’:
include/net/flow.h:84:32: error: ‘LOOPBACK_IFINDEX’ undeclared (first use in this function)

[Backport of net-next 6a662719c9868b3d6c7d26b3a085f0cd3cc15e64]

Change-Id: Ib7a0a08d78c03800488afa1b2c170cb70e34cfd9
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Julian Anastasov <ja@ssi.bg>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Cong Wang <cwang@twopensource.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>

defconfig: s5neolte: disable cpusets

defconfig: s5neolte: regenerate defconfig

nf: IDLETIMER: Adds the uid field in the msg

Message notifications contains an additional uid field. This field
represents the uid that was responsible for waking the radio. And hence
it is present only in notifications stating that the radio is now
active.

Change-Id: I18fc73eada512e370d7ab24fc9f890845037b729
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
Bug: 20264396

bcmdhd: Fix android version check

dma: dmaengine: Do not skip opening a 'busy' DMA channel as it crashes the kernel and doesn't seem to be necessary

sec_battery: update prev_safety_time to fix the non-charging issue when the device is not plugged in for 20+ hours

a5xelte: add initial defconfig

cpufreq: interactive: check speedchange_task pointer before waking it to avoid a kernel panic

trace: exynos-ss: fix mode permissions in calls to 'ptrace_may_access'

cpufreq: interactive: Rearm governor timer at max freq

Interactive governor doesn't rearm per-cpu timer if target_freq is
equal to policy->max. However, this does not have clear performance
benefits. Profiling doesn't show any difference in benchmarks, games
or other workloads, if timers are always rearmed.

At same time, there are a few issues caused by not rearming timer
at policy->max.

1) min_sample_time enforcement is inconsistent

For target frequency that is lower than policy->max, it will not
drop until min_sample_time has passed since last frequency evaluation
selected current frequency. However, for policy->max, it will
always drop immediately as long as CPU has been run for longer than
min_sample_time. This is because timer is not running and thus
floor_freq and floor_validate_time is not updated.

Example: assume min_sample_time is 59ms and timer_rate is 20ms.
Frequency X < Y. Let's say CPU would pick the following frequencies
before accounting for min_sample_time in each 20ms sampling window.
Y, Y, Y, Y, X, X, X, X, X
If Y is not policy->max, the final target_freq after considering
min_sample_time will be Y, Y, Y, Y, *Y, *Y, X, X, X
* marks the windows where frequency is prevented from dropping.
If Y is policy->max, the final target_freq will be
Y, Y, Y, Y, X, X, X, X, X

2) Rearm timer in IDLE_START does not work as intended

IDLE_START/END is sent in arch_cpu_idle_enter/exit(). However, next
wake up is decided in tick_nohz_idle_enter(), which traverses the
timer list before idle notification is sent out. Therefore, rearming
timer in idle notification won't take effect until CPU wakes up at
least once. In rare scenarios when a CPU goes to idle and sleeps for a
long time immediately after a heavy load stops, it may not wake up
to drop its frequency vote for a long time, defeating the purpose of
having a slack_timer.

3) Need to rearm timer for policy->max change

commit 535a553fc1c4b4c3627c73214ade6326615a7463
(cpufreq: interactive: restructure CPUFREQ_GOV_LIMITS) mentions the
problem of timer getting indefinitely pushed back due to frequency
changes in policy->min/max. However, it still cancels and rearms timer
if policy->max is increased, and same problem could still happen if
policy->max is frequently changing after the fix. The best solution is
to always rearm timer for each CPU even if it's running at
policy->max.

Rearming timers even if target_freq is policy->max solves these
problems cleanly. It also simplifies the design and code of interactive
governor.

Change-Id: I973853d2375ea6f697fa4cee04a89efe6b8bf735
Reviewed-by: Saravana Kannan <skannan@codeaurora.org>
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>

kernel: Fix massive cpufreq stats memory leaks

Every time _cpu_up() is called for a CPU, idle_thread_get() is called which
then re-initializes a CPU's idle thread that was already previously created
and cached in a global variable in smpboot.c. idle_thread_get() calls
init_idle() which then calls __sched_fork(). __sched_fork() is where
cpufreq_task_stats_init() is, and cpufreq_task_stats_init() allocates
512 bytes of memory to a pointer in the task struct.

Since idle_thread_get() reuses a task struct instance that was already
previously created, this means that every time it calls init_idle(),
cpufreq_task_stats_init() allocates 512 bytes again and overwrites the
existing 512-byte allocation that the idle thread already had.

This causes 512 bytes to be leaked every time a CPU is onlined. This is
significant when non-boot CPUs are enabled during resume from suspend; this
means that (NR_CPUS - 1) * 512 bytes are leaked every time the device exits
suspend (this turned out to be ~500 kiB leaked in 20 minutes with the
device left on a desk with the screen off).

In order to fix this, don't initialize cpufreq stats at all for the idle
threads. The cpufreq stats interface is intended to be used for tracking
userspace tasks, so we can safely remove it from the kernel's idle threads
without killing any functionality.

Change-Id: I12fe7611fc88eb7f6c39f8f7629ad27b6ec4722c
Signed-off-by: Sultan Alsawaf <sultanxda@gmail.com>

sched: Prevent recursion in io_schedule()

commit 9cff8adeaa34b5d2802f03f89803da57856b3b72 upstream.

io_schedule() calls blk_flush_plug() which, depending on the
contents of current->plug, can initiate arbitrary blk-io requests.

Note that this contrasts with blk_schedule_flush_plug() which requires
all non-trivial work to be handed off to a separate thread.

This makes it possible for io_schedule() to recurse, and initiating
block requests could possibly call mempool_alloc() which, in times of
memory pressure, uses io_schedule().

Apart from any stack usage issues, io_schedule() will not behave
correctly when called recursively as delayacct_blkio_start() does
not allow for repeated calls.

So:
 - use ->in_iowait to detect recursion.  Set it earlier, and restore
   it to the old value.
 - move the call to "raw_rq" after the call to blk_flush_plug().
   As this is some sort of per-cpu thing, we want some chance that
   we are on the right CPU
 - When io_schedule() is called recurively, use blk_schedule_flush_plug()
   which cannot further recurse.
 - as this makes io_schedule() a lot more complex and as io_schedule()
   must match io_schedule_timeout(), but all the changes in io_schedule_timeout()
   and make io_schedule a simple wrapper for that.

Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
[ Moved the now rudimentary io_schedule() into sched.h. ]
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Tony Battersby <tonyb@cybernetics.com>
Link: http://lkml.kernel.org/r/20150213162600.059fffb2@notabene.brown
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Change-Id: Ic32d78863e35db89c3e8f0b29dcf20cb563dc70f

cpufreq: interactive: Use wake_up_process_no_notif to wake up tasks

Scheduler could send a notification to governor each time a task wakes
up. If governor wakes up another task as a response to such a
notification, it could result in endless recursive notifications.

Use wake_up_process_no_notif to ensure scheduler won't send another
notification for speedchange task woken up by the governor.

Change-Id: I697affcbdf79e2ad0cfe843eb880d304960682f4
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>

sched: Provide a wake up API without sending freq notifications

Each time a task wakes up, scheduler evaluates its load and notifies
governor if the resulting frequency of destination CPU is larger than
a threshold. However, some governor wakes up a separate task that
handles frequency change, which again calls wake_up_process().

This is dangerous because if the task being woken up meets the
threshold and ends up being moved around, there is a potential for
endless recursive notifications.

Introduce a new API for waking up a task without triggering
frequency notification.

Change-Id: I24261af81b7dc410c7fb01eaa90920b8d66fbd2a
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>

arm64: rebuild configs to reflect CONFIG_UID_SYS_STATS change

cpufreq: interactive: use CPUFREQ_RELATION_C to choose closest frequency insted of lowest

cpufreq: interactive: don't skip waking up speedchange_task if target_freq > policy->cur

When __cpufreq_driver_target() in speedchange_task failed for some reason, the
policy->cur could be lower than the target_freq. The governor misses to change
the target_freq if the target_freq is equal to the next_freq at the next sample
time.

Added a check to prevent the CPU to stay at the speed that is lower than the
target_freq for long duration.

Change-Id: Ibfdcd193b8280390b8f8374a63218aa31267f310
Signed-off-by: Minsung Kim <ms925.kim@samsung.com>

cpufreq: Optimize cpufreq_frequency_table_verify()

cpufreq_frequency_table_verify() is rewritten here to make it more logical
and efficient.
 - merge multiple lines for variable declarations together.
 - quit early if any frequency between min/max is found.
 - don't call cpufreq_verify_within_limits() in case any valid freq is
   found as it is of no use.
 - rename the count variable as found and change its type to boolean.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Used commit: https://github.com/Noxxxious/Zero/commit/a04a517aa911804b26f5970e49d48d35e1a62b24

Introduce CPUFREQ_RELATION_C
It selects the frequency with the minimum euclidean distance to
target. In case of equal distance between 2 frequencies, it will
select the greater freq.

Created by Stratos Karafotis <stratosk@semaphore.gr>

Original commit: https://github.com/XileForce/Vindicator-S6/commit/4b113d38e8f62ea5810d2b4d134cc6f7a81198dd

cpufreq: Move get_cpu_idle_time() to cpufreq.c

Governors other than ondemand and conservative can also use get_cpu_idle_time()
and they aren't required to compile cpufreq_governor.c. So, move these
independent routines to cpufreq.c instead.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
This fixes compiling errors without Ondemand

Based on https://patchwork.kernel.org/patch/2582231/

cpufreq_stats: Fix stats leak during update policy

When the cpufreq policy is moved from one CPU to another, the percpu
stats_table is overwritten and leaked. Properly free the old stats table
and ensure its protected in the non-sysfs paths of update policy and
acct_update_power. The sysfs entries are removed in the cpufreq core
driver before migrating the policy. We introduce a new spinlock
specifically for these operations to avoid needed to convert all the
other spinlocks into the irq safe variants since acct_update_power is
typically called in ISR context.

[ported to apq8084-common by Corinna Vinschen <xda@vinschen.de>]

Change-Id: I95ff24c07834065cd0fd3c763a488a9843097a1d
Signed-off-by: Jason Hrycay <jason.hrycay@motorola.com>
Reviewed-on: https://gerrit.mot.com/921752
SLTApproved: Slta Waiver <sltawvr@motorola.com>
SME-Granted: SME Approvals Granted
Reviewed-by: Igor Kovalenko <igork@motorola.com>

ANDROID: cpufreq_stats: Fix task time in state locking

The task->time_in_state pointer is written to at task creation
and exiting, protection is needed for concurrent reads e.g. during
sysfs accesses.  Added spin lock such that the task's time_in_state
pointer used is set to either allocated memory or null.

Bug: 38463235
Test: Torture concurrent sysfs reads with short lived tasks
Signed-off-by: Andres Oportus <andresoportus@google.com>
Change-Id: Iaa6402bf50a33489506f2170e4dfabe535d79e15

ANDROID: cpufreq: stats: add uid removal for uid_time_in_state

Bug: 62295304
Bug: 34133340
Test: Boot and test uid removal by writing to remove_uid_range

Signed-off-by: Andres Oportus <andresoportus@google.com>
Change-Id: Ic51fc9480716a8aad88fb55549c2b69021038a11

Conflicts:
drivers/cpufreq/cpufreq_stats.c
include/linux/cpufreq.h
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>

uid_sys_stats: defer io stats calulation for dead tasks

Store sum of dead task io stats in uid_entry and defer uid io
calulation until next uid proc stat change or dumpsys.

Bug: 37754877
Change-Id: I970f010a4c841c5ca26d0efc7e027414c3c952e0
Signed-off-by: Jin Qian <jinqian@google.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>

uid_sys_stats: reduce update_io_stats overhead

Replaced read_lock with rcu_read_lock to reduce time that preemption
is disabled.

Added a function to update io stats for specific uid and moved
hash table lookup, user_namespace out of loops.

Bug: 37319300
Change-Id: I2b81b5cd3b6399b40d08c3c14b42cad044556970
Signed-off-by: Jin Qian <jinqian@google.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>

uid_sys_stats: change to use rt_mutex

We see this happens multiple times in heavy workload in systrace
and AMS stuck in uid_lock.

Running process:        Process 953
Running thread: android.ui
State:  Uninterruptible Sleep
Start:
1,025.628 ms
Duration:
27,955.949 ms
On CPU:
Running instead:        system_server
Args:
{kernel callsite when blocked:: "uid_procstat_write+0xb8/0x144"}

Changing to rt_mutex can mitigate the priority inversion

Bug: 34991231
Bug: 34193533
Test: on marlin
Change-Id: I28eb3971331cea60b1075740c792ab87d103262c
Signed-off-by: Wei Wang <wvw@google.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>

ANDROID: uid_sys_stats: account for fsync syscalls

Change-Id: Ie888d8a0f4ec7a27dea86dc4afba8e6fd4203488
Signed-off-by: Jin Qian <jinqian@google.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>

ANDROID: uid_sys_stats: fix negative write bytes.

A task can cancel writes made by other tasks. In rare cases,
cancelled_write_bytes is larger than write_bytes if the task
itself didn't make any write. This doesn't affect total size
but may cause confusion when looking at IO usage on individual
tasks.

Bug: 35851986
Change-Id: If6cb549aeef9e248e18d804293401bb2b91918ca
Signed-off-by: Jin Qian <jinqian@google.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>

ANDROID: uid_sys_stats: remove unnecessary code in procstat switch

No need to aggregate the switched uid separately since
update_io_stats_locked covers all uids.

Bug: 34198239
Change-Id: Ifed347264b910de02e3f3c8dec95d1a2dbde58c0
Signed-off-by: Jin Qian <jinqian@google.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>

ANDROID: uid_sys_stats: return full size when state is not changed.

Userspace keeps retrying when it sees nothing is written.

Bug: 34364961
Change-Id: Ie288c90c6a206fb863dcad010094fcd1373767aa
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>

ANDROID: uid_sys_stats: allow writing same state

Signed-off-by: Jin Qian <jinqian@google.com>
Bug: 34360629
Change-Id: Ia748351e07910b1febe54f0484ca1be58c4eb9c7
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>

ANDROID: uid_sys_stats: rename uid_cputime.c to uid_sys_stats.c

This module tracks cputime and io stats.

Signed-off-by: Jin Qian <jinqian@google.com>
Bug: 34198239
Change-Id: I9ee7d9e915431e0bb714b36b5a2282e1fdcc7342

Conflicts:
drivers/misc/Kconfig
drivers/misc/Makefile
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>

ANDROID: uid_cputime: add per-uid IO usage accounting

IO usages are accounted in foreground and background buckets.
For each uid, io usage is calculated in two steps.

delta = current total of all uid tasks - previus total
current bucket += delta

Bucket is determined by current uid stat. Userspace writes to
/proc/uid_procstat/set <uid> <stat> when uid stat is updated.

/proc/uid_io/stats shows IO usage in this format.
<uid> <foreground IO> <background IO>

Signed-off-by: Jin Qian <jinqian@google.com>
Bug: 34198239
Change-Id: I3369e59e063b1e5ee0dfe3804c711d93cb937c0c
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>

uid_cputime: Check for the range while removing range of UIDs.

Checking if the uid_entry->uid matches the uid intended to be removed will
prevent deleting unwanted uid_entry.
Type cast the key for the hashtable to the same size, as when they were
inserted. This will make sure that we can find the uid_entry we want.

Bug: 25195548
Change-Id: I567942123cfb20e4b61ad624da19ec4cc84642c1
Signed-off: Ruchi kandoi <kandoiruchi@google.com>

uid_cputime: fix cputime overflow

Converting cputime_t to usec caused overflow when the value is greater
than 1 hour. Use msec and convert to unsigned long long to support bigger
range.

Bug: 22461683

Change-Id: I853fe3e8e7dbf0d3e2cc5c6f9688a5a6e1f1fb3e
Signed-off-by: Jin Qian <jinqian@google.com>
Git-commit: 2abf710d2849737b6a435f371395481da628f746
Git-repo: https://android.googlesource.com/kernel/msm/
Signed-off-by: Nirmal Abraham <nabrah@codeaurora.org>

uid_cputime: Iterates over all the threads instead of processes.

Bug: 22833116
Change-Id: I775a18f61bd2f4df2bec23d01bd49421d0969f87
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
Git-commit: 35ef14095795ea331361034a1f7087bdf07f76f7
Git-repo: https://android.googlesource.com/kernel/msm/
Signed-off-by: Nirmal Abraham <nabrah@codeaurora.org>

uid_cputime: Avoids double accounting of process stime, utime and cpu_power in task exit.

This avoids the race where a particular process is terminating and we read the
show_uid_stats. At this time since the task_struct still exists and we will account
for the terminating process as one of the active task, where as the stats would have
been added in the task exit callback.

When the task is terminated, the cpu_power for that particular task is added to the
terminated tasks. It is possible that before the task releases all the resources, cpu
reschedules the task or a timer interrupt is fired. At this point we will try to add
the additional time to the process, which will cause the accounting to be skewed. This
avoids that race condition.

Bug: 22064385
Change-Id: Id2ae04b33fcd230eda9683a41b6019d4dd8f5d85
Signed-off-by: Jin Qian <jinqian@google.com>
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
Git-commit: 344377047daa5832ef798af697adee388e367d57
Git-repo: https://android.googlesource.com/kernel/msm/
Signed-off-by: Nirmal Abraham <nabrah@codeaurora.org>

uid_cputime: Extends the cputime functionality to report power per uid

/proc/uid_cputime/show_uid_stats shows a third field power for each of
the uids.It represents the power in the units (uAusec)

Bug: 21498425
Change-Id: I52fdc5e59647e9dc97561a26d56f462a2689ba9c
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
Git-commit: b8d3311e8d41c9109f9a4ba3c4d0f7e594539c68
Git-repo: https://android.googlesource.com/kernel/msm/
Signed-off-by: Nirmal Abraham <nabrah@codeaurora.org>

ANDROID: Fix cpufreq stats table creation

cpufreq stats does not correctly supports multiple cpus per profile.
For instance Marlin/Sailfish per cpu stats struct does not get created
for all cpus (only one per policy).  This change does not provide full
support for multiple cpus per profile but allows stats creation per
cpu to allow b/34133340 to be completed.

Bug: 38244231
Bug: 34133340
Test: Boot Sailfish

Signed-off-by: Andres Oportus <andresoportus@google.com>
Change-Id: I72ea548a199f57ed841618b08b9c41e99b493376

Conflicts:
drivers/cpufreq/cpufreq_stats.c
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>

ANDROID: cpufreq_stat: add per task/uid/freq stats

Adds per process nodes in /proc/PID/time_in_state showing per
frequency times and adds a global /proc/uid_time_in_state
showing per frequency per uid times.

Bug: 34133340
Bug: 38320164

Tests: boot sailfish and reading /proc/uid_time_in_state and
/proc/$$/time_in_state

Signed-off-by: Andres Oportus <andresoportus@google.com>
Change-Id: Ideb22b608b9a5e7bd2200a3a6df0f110b635f96a

uid_cputime: Avoids double accounting of process stime, utime and cpu…
…_power in task exit.

This avoids the race where a particular process is terminating and we
read the show_uid_stats. At this time since the task_struct still exists
and we will account for the terminating process as one of the active
task, where as the stats would have been added in the task exit
callback.

When the task is terminated, the cpu_power for that particular task is
added to the terminated tasks. It is possible that before the task releases all
the resources, cpu reschedules the task or a timer interrupt is fired. At this
point we will try to add the additional time to the process, which will cause
the accounting to be skewed. This avoids that race condition.

Bug: 22064385
Change-Id: Id2ae04b33fcd230eda9683a41b6019d4dd8f5d85
Signed-off-by: Jin Qian <jinqian@google.com>
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
Git-commit: 344377047daa5832ef798af697adee388e367d57
Git-repo: https://android.googlesource.com/kernel/msm/
Signed-off-by: Nirmal Abraham <nabrah@codeaurora.org>
Signed-off-by: Srinivasarao P <spathi@codeaurora.org>
Change-Id: I405733725d535b0a864088516bf52fa3638ee6aa

Used commit: https://github.com/omnirom/android_kernel_lge_msm8992/commit/e36bbc4edde59683e980c816fb4a432fbbe594bb

sched: cpufreq: Adds a field cpu_power in the task_struct

cpu_power has been added to keep track of amount of power each task is
consuming. cpu_power is updated whenever stime and utime are updated for
a task. power is computed by taking into account the frequency at which
the current core was running and the current for cpu actively
running at hat frequency.

Change-Id: Ic535941e7b339aab5cae9081a34049daeb44b248
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
Original commit: https://github.com/dianlujitao/CAF_kernel_msm-3.10/commit/85a6bd2bc4c903df43186e6f41209746aa6fdf05

cpufreq_stats: Adds the fucntionality to load current values for each frequency for all the cores.

The current values for the cpu cores needs to be added to the device
tree for this functionaly to work. It loads the current values for each
frequecy in uA for all the cores.

Change-Id: If03311aaeb3e4c09375dd0beb9ad4fbb254b5c08
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
Original commit: https://github.com/dianlujitao/CAF_kernel_msm-3.10/commit/8d12562a74922eac859dcec9c43d34d8fd1a9fd1

Fix memory leaks when updating stats table

The address for an element in the per-cpu cpufreq_stats_table variable
is overwritten in cpufreq_stats_update_policy_cpu(), but the memory
allocated at the address that gets overwritten is not freed beforehand.

Free the allocated memory beforehand to fix the memory leaks.

Signed-off-by: Sultanxda <sultanxda@gmail.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
Signed-off-by: Luca Grifo <lg@linux.com>
Signed-off-by: djb77 <dwayne.bakewell@gmail.com>
Used commit: https://github.com/Siddhant-Naik/TheFlash-Kernel-A5-A7-2017/commit/98bd2052dfc9757832c49b7a8c68157b8baea13f

cpufreq: interactive governor drops bits in time calculation

Keep time calculation in 64-bit throughout. If we have long times
between idle calculations this can result in deltas > 32 bits
which causes incorrect load percentage calculations and selecting
the wrong frequencies if we truncate here.

Change-Id: Iac1e5646d58485737538edbb9e7a6d2246b56023
Signed-off-by: Chris Redpath <chris.redpath@arm.com>
Signed-off-by: Alex Naidis <alex.naidis@linux.com>

CHROMIUM: cpufreq: interactive: calculate load before freq change

The update to cpu load for cpufreq rate changes was happening after the rate
change instead of before. This switches it to update the cpu load before the
cpufreq rate change so the old frequency is used for calculating the speed
adjusted cpu load. The old frequency was used for that active time, so it should
be used for calculating the speed adjusted cpu load.

BUG=chrome-os-partner:37673
TEST=power_LoadTest on Jerry
check we spend most of our time at the lower cpu frequencies

Change-Id: I2fff785561ad8aebd354ddd305e91d96c799a617
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/262925
Reviewed-by: Douglas Anderson <dianders@chromium.org>

cpufreq: Correct the data reported in all_time_in_state

Commit bd9474e059bbb2bb62f7e93894cfc3d3ba473fb2 (cpufreq_stats:
Adds the fucntionality to load current values for each frequency
for all the cores) introduced a change by which
'cpufreq_allstats_create' gets called at initialization (from
'cpufreq_stats_init' instead of 'cpufreq_stat_notifier_policy').
This causes 'cpufreq_allstate_create' to be called before the
freq_table is allocated from 'create_all_freq_table'. Due to
this, the data for cpu's which are online at boot are not
added to the 'all_freq_table' leading to the incorrect
reporting of data when the below sysfs command is run -
'cat sys/devices/system/cpu/cpufreq/all_time_in_state'.

Correct this behaviour by altering the cpufreq_stats init
sequence by which the memory for 'all_freq_table' is allocated
before the 'cpufreq_allstats_create' function is called.

Change-Id: I2232dacdc0deec4d1987c418e833fe28f74623fc
Signed-off-by: Nirmal Abraham <nabrah@codeaurora.org>

cpufreq: interactive: Ramp up directly if cpu_load exceeds 100

When governor is using regular busy time tracking, cpu_load will
never exceed 100 because busy time will never exceed elapsed time in
any one sampling window. The only exception is when frequency is
reduced in middle of a window (e.g. due to thermal throttling). In
this case, cpu_load is likely irrelevant since current frequency
governor has been voting is already higher than what target can run
at.

However, on a heterogeneous CPU system with scheduler input enabled
to track the load of migrated tasks, cpu_load could also exceed 100
when a task migrates from more capable CPU to slower CPU. When this
happens, governor already knows the exact frequency required to handle
this load. There is no need to progressively ramp up frequency in order
to assess the load's real demand. It's not desirable to starve such a
migrating task by forcing it through ramping up process on the slower
CPU.

Direclty jump beyond hispeed_freq and ignore above_hispeed_delay if
cpu_load exceeds 100.

Change-Id: Ib87057e4f00732fad943ab595a33e3059494ef15
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>

cpufreq: interactive: fix permanent locking on high CPU frequency

This removed improper Samsung's changes

CHROMIUM: cpufreq: interactive: validate above_hispeed_delay

We rely on the frequencies in above_hispeed_delay being in ascending
order.  Ensure that is the case for the values the user gives us.

BUG=chrome-os-partner:20830
TEST=Boot Pit; write invalid above_hispeed_delay value:
localhost ~ # echo "20000 1800000:20000 700000:0" > above_hispeed_delay
-bash: echo: write error: Invalid argument

Change-Id: Ifb431e58ad4b6b371152d7b09fcbefa127b0cbe2
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65742
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>

cpufreq: interactive: BUG_ON when tunables are NULL after init

When tunables are not available for events other than
CPUFREQ_GOV_POLICY_INIT in cpufreq_governor_interactive(), trigger a
panic instead of throwing a warning.

When the original warning happens, some race condition must have
occurred, and governor will be in a bad state even if it might still
run for a while. Panic directly so that it's easier to catch the
first race event.

Change-Id: I2dc1185cabfe72a63739452731fe242924d2cf45
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>

cpufreq: interactive: Don't set floor_validate_time during boost

Frequency selection algorithm guarantees its chosen frequency
is not lower than hispeed_freq as long as boost is enabled.

Setting floor_freq and floor_validate_time during boost could block
CPU frequency from going below hispeed_freq even after
boostpulse_duration expires, if min_sample_time is higher than
boostpulse_duration. This conflicts with the intention of commit
de091367ead15b6e95dd1d0743a18f0da5a07ee5
(cpufreq: interactive: specify duration of CPU speed boost pulse)
to allow CPU to ramp down immediately after boost expires. It also
makes boost behavior inconsistent since it depends on min_sample_time.

Avoid setting floor_freq and floor_validate_time when boost starts.

Change-Id: I12852998af46cfbfaf8661eb5e8d5301b6f631e7
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
Signed-off-by: Bálint Czobor <czoborbalint@gmail.com>

cpufreq: interactive: Use del_timer/add_timer_on to rearm timers

Replace mod_timer_pinned() with del_timer(), add_timer_on().
mod_timer_pinned() always adds timer onto current CPU. Interactive
governor expects each CPU's timers to be running on the same CPU.
If cpufreq_interactive_timer_resched() is called from another CPU,
the timer will be armed on the wrong CPU.

Replacing mod_timer_pinned() with del_timer() and add_timer_on()
guarantees timers are still run on the right CPU even if another
CPU reschedules the timer. This would provide more flexibility
for future changes.

Change-Id: I3a10be37632afc0ea4e0cc9c86323b9783b216b1
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>

net: core: To send ARP probe when neighbor state is NUD_STALE

Featurizing to send an ARP probe to the connected client when
the neighbor state moves to NUD_STALE. This triggers the
neighbor state to move back to NUD_REACHABLE if the ARP request
is resolved and prevents a RTM_DELNEIGH from being triggered

Change-Id: I27aba004a180dfbff5b1fcee2d04047c8523fb8a
Signed-off-by: Sridhar Ancha <sancha@codeaurora.org>

net: core: Send ARP probe and trigger RTM_NEWNEIGH

Send ARP probe and generate RTM_NEWNEIGH if the neighbor
state is not NUD_REACHABLE. Also featurize changes for
sending neighbor probe.

Change-Id: I633285b8e0cbcd49291d5e52136f11e20f2388bc
Signed-off-by: Ravinder Konka <rkonka@codeaurora.org>

neigh: Better handling of transition to NUD_PROBE state

[1] When entering NUD_PROBE state via neigh_update(), perhaps received
    from userspace, correctly (re)initialize the probes count to zero.

    This is useful for forcing revalidation of a neighbor (for example
    if the host is attempting to do DNA [IPv4 4436, IPv6 6059]).

[2] Notify listeners when a neighbor goes into NUD_PROBE state.

    By sending notifications on entry to NUD_PROBE state listeners get
    more timely warnings of imminent connectivity issues.

    The current notifications on entry to NUD_STALE have somewhat
    limited usefulness: NUD_STALE is a perfectly normal state, as is
    NUD_DELAY, whereas notifications on entry to NUD_FAILURE come after
    a neighbor reachability problem has been confirmed (typically after
    three probes).

Change-Id: I1d01d40ef3bc4753b0eaa79da2b27235425b1934
Signed-off-by: Erik Kline <ek@google.com>
Acked-By: Lorenzo Colitti <lorenzo@google.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Git-commit: e4a6d6ba5a9e9e1796bbe6efe4f20ce7072df667
Git-repo: https://android.googlesource.com/kernel/common.git
Signed-off-by: Ian Maund <imaund@codeaurora.org>

net: core: To send ARP probe when neighbor state is NUD_STALE

Send an ARP probe to the connected client when the neighbor
state moves to NUD_STALE. This triggers the neighbor state
to move back to NUD_REACHABLE if the ARP request is resolved
and prevents a RTM_DELNEIGH from being triggered

Change-Id: I4d17c8f24d47931524904d0db74fa812a4f235f6
Signed-off-by: Ravinder Konka <rkonka@codeaurora.org>
Signed-off-by: Skylar Chang <chiaweic@codeaurora.org>