{"push_id":2502161678,"size":6,"distinct_size":6,"ref":"refs/heads/8.1","head":"6155d17311d38c10c8a37bfaa41e23279f3dc759","before":"9a5459c3160f3df5a8313f69df171ba8f24f1b99","commits":[{"sha":"3c4fe4693ac6e911f98488ccf782dafe3b936a21","author":{"name":"root","email":"dc76e9f0c0006e8f919e0c515c66dbba3982f785@instance-1.c.thematic-gift-200703.internal"},"message":"Optimize fastpath_timer_check()","distinct":true,"url":"https://api.github.com/repos/mady51/unifiedOp3/commits/3c4fe4693ac6e911f98488ccf782dafe3b936a21"},{"sha":"cbb79a8fe521ac61e064e7d11c2cd2abaad7b92c","author":{"name":"Peter Zijlstra","email":"3fddac958924aef220f202ca567388ddab3f14a8@infradead.org"},"message":"UPSTREAM: sched/fair: Fix and optimize the fork() path\n\nThe task_fork_fair() callback already calls __set_task_cpu() and takes\nrq->lock.\n\nIf we move the sched_class::task_fork callback in sched_fork() under\nthe existing p->pi_lock, right after its set_task_cpu() call, we can\navoid doing two such calls and omit the IRQ disabling on the rq->lock.\n\nChange to __set_task_cpu() to skip the migration bits, this is a new\ntask, not a migration. Similarly, make wake_up_new_task() use\n__set_task_cpu() for the same reason, the task hasn't actually\nmigrated as it hasn't ever ran.\n\nThis cures the problem of calling migrate_task_rq_fair(), which does\nremove_entity_from_load_avg() on tasks that have never been added to\nthe load avg to begin with.\n\nThis bug would result in transiently messed up load_avg values, averaged\nout after a few dozen milliseconds. This is probably the reason why\nthis bug was not found for such a long time.\n\nReported-by: Vincent Guittot <vincent.guittot@linaro.org>\nSigned-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Mike Galbraith <efault@gmx.de>\nCc: Peter Zijlstra <peterz@infradead.org>\nCc: Thomas Gleixner <tglx@linutronix.de>\nCc: linux-kernel@vger.kernel.org\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\n(cherry picked from commit e210bffd39d01b649c94b820c28ff112673266dd)\nChange-Id: Icbddbaa6e8c1071859673d8685bc3f38955cf144\nSigned-off-by: Brendan Jackman <brendan.jackman@arm.com>\nSigned-off-by: Chris Redpath <chris.redpath@arm.com>\nSigned-off-by: ahmedradaideh <ahmed.radaideh@gmail.com>","distinct":true,"url":"https://api.github.com/repos/mady51/unifiedOp3/commits/cbb79a8fe521ac61e064e7d11c2cd2abaad7b92c"},{"sha":"82bc40ccd6ae58389464280b14fdb0f017b7fd25","author":{"name":"Kelly Rossmoyer","email":"2c5ce18f9c8215bb5b046dc5a160b82ef12550f6@google.com"},"message":"fs: Improve eventpoll logging to stop indicting timerfd\n\ntimerfd doesn't create any wakelocks; eventpoll can, and is creating the\nwakelocks we see called \"[timerfd]\".  eventpoll creates two kinds of\nwakelocks: a single top-level lock associated with the eventpoll fd\nitself, and one additional lock for each fd it is polling that needs\nsuch a lock (e.g. those using EPOLLWAKEUP).  Current code names the\nper-fd locks using the undecorated names of the fds' associated files\n(hence \"[timerfd]\"), and is naming the top-level lock after the PID of\nthe caller and the name of the file behind the first fd for which a\nper-fd lock is created.  To make things clearer, the top-level lock is\nnow named using the caller command name and an \"epollfd\" designation,\nwhile the per-fd locks are also named with the caller's command name (to\nassociate them with the top-level lock) and their respective fds' file\nnames.\n\nRevert \"Add kernel logging for when timerfd_read blocks\"\nThis reverts commit 47c748b7dbeb4ca690a0ce5e838c60ff59dae787.\n\nAdding logging to timerfd_read turns out to have been superfluous, since\nthe blocking that occurs in timerfd_read properly relinquishes the CPU\nwithout holding any wakelocks.  The logging also proved to be overly\n\"chatty\" due to frequency.\n\nBug: 63866355\nBug: 38042165\nTest: Ran on device and observed new wakelock naming in bugreport,\ndumpsys batterystats, /d/tracing/trace, and d/wakeup_reasons.\nSigned-off-by: Kelly Rossmoyer <krossmo@google.com>\n\nChange-Id: I4772c41a407afd17f87a6c15e01986c53ad0f9c0\nSigned-off-by: ahmedradaideh <ahmed.radaideh@gmail.com>","distinct":true,"url":"https://api.github.com/repos/mady51/unifiedOp3/commits/82bc40ccd6ae58389464280b14fdb0f017b7fd25"},{"sha":"addc85ee4b6bc92698f7cffdbbc289a79a227907","author":{"name":"root","email":"dc76e9f0c0006e8f919e0c515c66dbba3982f785@instance-1.c.thematic-gift-200703.internal"},"message":"disable CONFIG_WLAN_FEATURE_RX_WAKELOCK","distinct":true,"url":"https://api.github.com/repos/mady51/unifiedOp3/commits/addc85ee4b6bc92698f7cffdbbc289a79a227907"},{"sha":"418d7c144a11724c3b108732398fd3d4fbd99ba3","author":{"name":"Francisco Franco","email":"42480b5f4d505650064e5081b85d867a03559887@gmail.com"},"message":"oneplus: add some error wakelock cleanups\n\nSigned-off-by: Francisco Franco <franciscofranco.1990@gmail.com>\nSigned-off-by: ahmedradaideh <ahmed.radaideh@gmail.com>","distinct":true,"url":"https://api.github.com/repos/mady51/unifiedOp3/commits/418d7c144a11724c3b108732398fd3d4fbd99ba3"},{"sha":"6155d17311d38c10c8a37bfaa41e23279f3dc759","author":{"name":"Paul E. McKenney","email":"1e0ce936bb9b355d257bf5790d2513c3f28be22b@linux.vnet.ibm.com"},"message":"perf: Disable IRQs across RCU RS CS that acquires scheduler lock\n\nThe perf_lock_task_context() function disables preemption across its\nRCU read-side critical section because that critical section acquires\na scheduler lock.  If there was a preemption during that RCU read-side\ncritical section, the rcu_read_unlock() could attempt to acquire scheduler\nlocks, resulting in deadlock.\n\nHowever, recent optimizations to expedited grace periods mean that IPI\nhandlers that execute during preemptible RCU read-side critical sections\ncan now cause the subsequent rcu_read_unlock() to acquire scheduler locks.\nDisabling preemption does nothiing to prevent these IPI handlers from\nexecuting, so these optimizations introduced a deadlock.  In theory,\nthis deadlock could be avoided by pulling all wakeups and printk()s out\nfrom rnp->lock critical sections, but in practice this would re-introduce\nsome RCU CPU stall warning bugs.\n\nGiven that acquiring scheduler locks entails disabling interrupts, these\ndeadlocks can be avoided by disabling interrupts (instead of disabling\npreemption) across any RCU read-side critical that acquires scheduler\nlocks and holds them across the rcu_read_unlock().  This commit therefore\nmakes this change for perf_lock_task_context().\n\nChange-Id: Ia8111bf4ff77815c72ce1dfe4aebaa24862d6bd6\nReported-by: Dave Jones <davej@codemonkey.org.uk>\nReported-by: Peter Zijlstra <peterz@infradead.org>\nSigned-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>\nSigned-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>\nCc: Arnaldo Carvalho de Melo <acme@redhat.com>\nCc: Jiri Olsa <jolsa@redhat.com>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Stephane Eranian <eranian@gmail.com>\nCc: Thomas Gleixner <tglx@linutronix.de>\nLink: http://lkml.kernel.org/r/20151104134838.GR29027@linux.vnet.ibm.com\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: ahmedradaideh <ahmed.radaideh@gmail.com>","distinct":true,"url":"https://api.github.com/repos/mady51/unifiedOp3/commits/6155d17311d38c10c8a37bfaa41e23279f3dc759"}]}
{"actor":{"display_login":"mady51"}}