xavi/android_kernel_m2note/kernel, branch lp-5.1

futex-prevent-requeue-pi-on-same-futex.patch futex: Forbid uaddr == u…

2016-09-28T13:16:00+00:00

…addr2 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() in line with futex_wait_requeue_pi() which performs the same check as per commit 6f7b0a2a5c0f ("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: I3d40911aca262eaefc3852327fa12bec416cd27d Reported-by: Pinkie Pie Signed-off-by: Will Drewry Signed-off-by: Kees Cook Cc: stable@vger.kernel.org Signed-off-by: Thomas Gleixner Reviewed-by: Darren Hart Signed-off-by: Linus Torvalds Signed-off-by: franciscofranco Signed-off-by: engstk

sched: remove migration notification from RT class

2016-09-28T13:15:21+00:00

Commit 88a7e37d265 (sched: provide per cpu-cgroup option to notify on migrations) added a notifier call when a task is moved to a different CPU. Unfortunately the two call sites in the RT sched class where this occurs happens with a runqueue lock held. This can result in a deadlock if the notifier call attempts to do something like wake up a task. Fortunately the benefit of 88a7e37d265 comes mainly from notifying on migration of non-RT tasks, so we can simply ignore the movements of RT tasks. CRs-Fixed: 491370 Change-Id: I8849d826bf1eeaf85a6f6ad872acb475247c5926 Signed-off-by: Steve Muckle Signed-off-by: W4TCH0UT Conflicts: kernel/sched/rt.c

sched: provide per cpu-cgroup option to notify on migrations

2016-09-28T13:15:20+00:00

On systems where CPUs may run asynchronously, task migrations between CPUs running at grossly different speeds can cause problems. This change provides a mechanism to notify a subsystem in the kernel if a task in a particular cgroup migrates to a different CPU. Other subsystems (such as cpufreq) may then register for this notifier to take appropriate action when such a task is migrated. The cgroup attribute to set for this behavior is "notify_on_migrate" . Change-Id: Ie1868249e53ef901b89c837fdc33b0ad0c0a4590 Signed-off-by: Steve Muckle Signed-off-by: W4TCH0UT Conflicts: kernel/sched/core.c kernel/sched/rt.c

sched: Reduce overestimating rq->avg_idle

2016-09-18T17:40:41+00:00

Date Thu, 29 Aug 2013 13:05:34 -0700 When updating avg_idle, if the delta exceeds some max value, then avg_idle gets set to the max, regardless of what the previous avg was. This can cause avg_idle to often be overestimated. This patch modifies the way we update avg_idle by always updating it with the function call to update_avg() first. Then, if avg_idle exceeds the max, we set it to the max. Signed-off-by: Jason Low Reviewed-by: Rik van Riel Signed-off-by: Paul Reioux Signed-off-by: engstk

sched: remove migration notification from RT class

2016-09-18T17:40:20+00:00

sched: provide per cpu-cgroup option to notify on migrations

2016-09-18T17:40:13+00:00

cgroup: make serial_nr_cursor available throughout cgroup.c

2016-09-18T10:46:49+00:00

The next patch will use it to determine if a cgroup is newly created while we're iterating the cgroup hierarchy. tj: Rephrased the comment on top of cgroup_serial_nr_cursor. Signed-off-by: Li Zefan Signed-off-by: Tejun Heo

cgroup: fix memory leak in cgroup_rm_cftypes()

2016-09-18T10:46:48+00:00

The memory allocated in cgroup_add_cftypes() should be freed. The effect of this bug is we leak a bit memory everytime we unload cfq-iosched module if blkio cgroup is enabled. Signed-off-by: Li Zefan Signed-off-by: Tejun Heo

cgroup: add cgroup->serial_nr and implement cgroup_next_sibling()

2016-09-18T10:46:47+00:00

Currently, there's no easy way to find out the next sibling cgroup unless it's known that the current cgroup is accessed from the parent's children list in a single RCU critical section. This in turn forces all iterators to require whole iteration to be enclosed in a single RCU critical section, which sometimes is too restrictive. This patch implements cgroup_next_sibling() which can reliably determine the next sibling regardless of the state of the current cgroup as long as it's accessible. It currently is impossible to determine the next sibling after dropping RCU read lock because the cgroup being iterated could be removed anytime and if RCU read lock is dropped, nothing guarantess its ->sibling.next pointer is accessible. A removed cgroup would continue to point to its next sibling for RCU accesses but stop receiving updates from the sibling. IOW, the next sibling could be removed and then complete its grace period while RCU read lock is dropped, making it unsafe to dereference ->sibling.next after dropping and re-acquiring RCU read lock. This can be solved by adding a way to traverse to the next sibling without dereferencing ->sibling.next. This patch adds a monotonically increasing cgroup serial number, cgroup->serial_nr, which guarantees that all cgroup->children lists are kept in increasing serial_nr order. A new function, cgroup_next_sibling(), is implemented, which, if CGRP_REMOVED is not set on the current cgroup, follows ->sibling.next; otherwise, traverses the parent's ->children list until it sees a sibling with higher ->serial_nr. This allows the function to always return the next sibling regardless of the state of the current cgroup without adding overhead in the fast path. Further patches will update the iterators to use cgroup_next_sibling() so that they allow dropping RCU read lock and blocking while iteration is in progress which in turn will be used to simplify controllers. v2: Typo fix as per Serge. Signed-off-by: Tejun Heo Acked-by: Serge E. Hallyn

cgroup: make cgroup_is_removed() static

2016-09-18T10:46:46+00:00

cgroup_is_removed() no longer has external users and it shouldn't grow any - controllers should deal with cgroup_subsys_state on/offline state instead of cgroup removal state. Make it static. While at it, make it return bool. Signed-off-by: Tejun Heo