{"push_id":790773258,"size":40,"distinct_size":40,"ref":"refs/heads/lollipop-mr1-m3-unified","head":"01d3cd6b4c7c2e814c0b4c89bfada2449c7360d8","before":"d57467e4876adc6ab9043795bc93fa40a65b29c3","commits":[{"sha":"554688ff04e4e6d90f16852ad1e114fa6af00145","author":{"email":"10f5d60ce5fa6fe3c789dd71c5d6567abd91f3fa@google.com","name":"Tahsin Erdogan"},"message":"block: Make CFQ default to IOPS mode on SSDs\n\nCFQ idling causes reduced IOPS throughput on non-rotational disks.\nSince disk head seeking is not applicable to SSDs, it doesn't really\nhelp performance by anticipating future near-by IO requests.\n\nBy turning off idling (and switching to IOPS mode), we allow other\nprocesses to dispatch IO requests down to the driver and so increase IO\nthroughput.\n\nFollowing FIO benchmark results were taken on a cloud SSD offering with\nidling on and off:\n\nIdling     iops    avg-lat(ms)    stddev            bw\n------------------------------------------------------\n    On     7054    90.107         38.697     28217KB/s\n   Off    29255    21.836         11.730    117022KB/s\n\nfio --name=temp --size=100G --time_based --ioengine=libaio \\\n    --randrepeat=0 --direct=1 --invalidate=1 --verify=0 \\\n    --verify_fatal=0 --rw=randread --blocksize=4k --group_reporting=1 \\\n    --filename=/dev/sdb --runtime=10 --iodepth=64 --numjobs=10\n\nAnd the following is from a local SSD run:\n\nIdling     iops    avg-lat(ms)    stddev            bw\n------------------------------------------------------\n    On    19320    33.043         14.068     77281KB/s\n   Off    21626    29.465         12.662     86507KB/s\n\nfio --name=temp --size=5G --time_based --ioengine=libaio \\\n    --randrepeat=0 --direct=1 --invalidate=1 --verify=0 \\\n    --verify_fatal=0 --rw=randread --blocksize=4k --group_reporting=1 \\\n    --filename=/fio_data --runtime=10 --iodepth=64 --numjobs=10\n\nReviewed-by: Nauman Rafique <nauman@google.com>\nSigned-off-by: Tahsin Erdogan <tahsin@google.com>\nSigned-off-by: Jens Axboe <axboe@fb.com>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Riddlah/hells-Core-N6/commits/554688ff04e4e6d90f16852ad1e114fa6af00145"},{"sha":"cdbc33f76964c142eba789ffa04d64a27f96c1b0","author":{"email":"cd8c6775e60d6f67a6984377324e5290df3d5358@fb.com","name":"Jens Axboe"},"message":"cfq-iosched: fix the setting of IOPS mode on SSDs\n\nA previous commit wanted to make CFQ default to IOPS mode on\nnon-rotational storage, however it did so when the queue was\ninitialized and the non-rotational flag is only set later on\nin the probe.\n\nAdd an elevator hook that gets called off the add_disk() path,\nat that point we know that feature probing has finished, and\nwe can reliably check for the various flags that drivers can\nset.\n\nFixes: 41c0126b (\"block: Make CFQ default to IOPS mode on SSDs\")\nTested-by: Romain Francoise <romain@orebokech.com>\nSigned-off-by: Jens Axboe <axboe@fb.com>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Riddlah/hells-Core-N6/commits/cdbc33f76964c142eba789ffa04d64a27f96c1b0"},{"sha":"6af900966c0a3b4a375a2875e84036fccc5722d2","author":{"email":"bb05168246ed1a6b66d0e7b1ffb0c5e3707764ca@codeaurora.org","name":"Junjie Wu"},"message":"cpufreq: Check current frequency in device driver\n\n__cpufreq_driver_target() checks if policy->cur is same as target_freq\nwithout holding any lock. This function is used by governor to\ndirectly set CPU frequency. Governor calling this function can't hold\nany CPUfreq framework locks due to deadlock possibility.\n\nHowever, this results in a race condition where one thread could see\na stale policy->cur while another thread is changing CPU frequency.\n\nThread A: Governor calls __cpufreq_driver_target(), starts increasing\nfrequency but hasn't sent out CPUFREQ_POSTCHANGE notification yet.\nThread B: Some other driver (could be thermal mitigation) starts\nlimiting frequency using cpufreq_update_policy(). Every limits are\napplied to policy->min/max and final policy->max happens to be same as\npolicy->cur. __cpufreq_driver_target() simply returns 0.\nThread A: Governor finish scaling and now policy->cur violates\npolicy->max and could last forever until next CPU frequency scaling\nhappens.\n\nShifting the responsibility of checking policy->cur and target_freq\nto CPUfreq device driver would resolve the race as long as the device\ndriver holds a common mutex.\n\nSigned-off-by: Junjie Wu <junjiew@codeaurora.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Riddlah/hells-Core-N6/commits/6af900966c0a3b4a375a2875e84036fccc5722d2"},{"sha":"e2239f18182d43af34bb720169fa769f26d474c5","author":{"email":"e98e52dd3c6c9ef83e2bc9c8a1300c68656fbdca@codeaurora.org","name":"Hanumath Prasad"},"message":"cpufreq: interactive:call __cpufreq_driver_target() for cur frequency\n\nThere is a race window as explained below when governor tries to change\nthe cpu frequency and some other thread (say thermal mitigation) try to\nchange the policy limits simultaneously.\n\nspeedchange task (ThreadA)\t\t\tThread B(say Thermal)\n\ncpufreq_interactive_speedchange_task()\n\t|\n__cpufreq_driver_target()\n\t|\nset_cpu_freq()\n\t|\n\t\t\t\t\t\tcpufreq_update_policy()\n\t\t\t\t\t\t\t|\n\t\t\t\t\t\tmodified policy_max\n\t\t\t\t\t\t\t|\n\t\t\t\t\t\tcheck policy->curr against\n\t\t\t\t\t\tnew policy limits,return\n\t\t\t\t\t\twithout calling\n\t\t\t\t\t\t__cpufreq_driver_target as\n\t\t\t\t\t\tpolicy->curr(which is not\n\t\t\t\t\t\tupdated by ThreadA) is still\n\t\t\t\t\t\twithin the new policy limits.\n\n\t|\nsent CPUFREQ_POSTCHANGE notification\n\t|\nupdated policy->cur which happens to be higher than policy->max\n\nThis results the current frequency being higher than the policy->max and\nviolating the policy limits. This causes thermal impact and in turn high\npower consumption. So Fix this by calling __cpufreq_driver_target() always\nwith current frequency and leave it to __cpufreq_driver_target() to\nguarantee there is no race condition when multiple threads are changing\nfrequencies.\n\nSigned-off-by: Hanumath Prasad <hpprasad@codeaurora.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Riddlah/hells-Core-N6/commits/e2239f18182d43af34bb720169fa769f26d474c5"},{"sha":"ffccaacbf9fde03185c038f95257f6665655e755","author":{"email":"d79fadde9de82c838211e8a952123da40fe360c0@motorola.com","name":"Lianwei Wang"},"message":"cpufreq: set policy with user_policy data\n\nWhen we update/set cpufreq policy, we should set the new\npolicy with user_policy data, and the cpufreq notifier\nwill limit the min/max freq accordingly.\n\nThis is the right process to update the cpufreq policy.\n\nBut we miss it in store_scaling_governor func, which cause\nthe governor set failed if the policy.max is less than\nuser_policy.min.\n\nSigned-off-by: Lianwei Wang <a22439@motorola.com>\nReviewed-on: http://gerrit.mot.com/746797\nSLTApproved: Slta Waiver <sltawvr@motorola.com>\nSME-Granted: SME Approvals Granted\nTested-by: Jira Key <jirakey@motorola.com>\nReviewed-by: Ke Lu <a2435c@motorola.com>\nReviewed-by: Hong-Mei Li <a21834@motorola.com>\nReviewed-by: Zhi-Ming Yuan <a14194@motorola.com>\nSubmit-Approved: Jira Key <jirakey@motorola.com>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Riddlah/hells-Core-N6/commits/ffccaacbf9fde03185c038f95257f6665655e755"},{"sha":"3aab93a6534dfd79a4aa90fbd4d773301ee28c08","author":{"email":"178828d847a7966bf01ab61d225f258b7a82df35@codeaurora.org","name":"Rohit Vaswani"},"message":"arm: smp: Update the topology masks before calling CPU_STARTING notifiers\n\nCurrently, the CPU_STARTING notifiers would observe an incorrect sibling\nmask since the notifier chain is called before the topology masks are\nupdated for the new cpu.\nUpdate the topology masks before calling the notifier chain to fix this\nproblem.\n\nSigned-off-by: Rohit Vaswani <rvaswani@codeaurora.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Riddlah/hells-Core-N6/commits/3aab93a6534dfd79a4aa90fbd4d773301ee28c08"},{"sha":"88cd4fc650eba8f1ba36385bf40ffe2285f6f7b0","author":{"email":"d77b46f71ad07d1c66a004715c9110750816d270@motorola.com","name":"Jason Hrycay"},"message":"lowmemorykiller: Check tgid with rcu lock held\n\nWhen checking if the current task shares the same task group ID of the\ntask which is signalled for MEMDIE, ensure we do so within the rcu lock\nto avoid potential race condition of the memory pointed to by tsk\ngetting free'd and/or reusued and we end up with a false evaluation of\ncurrent.tgid matching, thus killing a task that maybe should not be\nkilled.\n\nSigned-off-by: Jason Hrycay <jason.hrycay@motorola.com>\nReviewed-on: http://gerrit.mot.com/735795\nSLTApproved: Slta Waiver <sltawvr@motorola.com>\nSME-Granted: SME Approvals Granted\nTested-by: Jira Key <jirakey@motorola.com>\nReviewed-by: Hong-Mei Li <a21834@motorola.com>\nReviewed-by: Christopher Fries <cfries@motorola.com>\nSubmit-Approved: Jira Key <jirakey@motorola.com>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Riddlah/hells-Core-N6/commits/88cd4fc650eba8f1ba36385bf40ffe2285f6f7b0"},{"sha":"f7eb2f96329a02781698731b71a3bdf8156b11d6","author":{"email":"9d52442787978fc5e49ad9634b00ef00eedcb73d@motorola.com","name":"Andrew Tzakis"},"message":"drivers/staging: lmk: Add Anon\n\nAdd global anonymous memory state to LMK logging\n\nSigned-off-by: Andrew Tzakis <atzakis@motorola.com>\nReviewed-on: http://gerrit.mot.com/712393\nSLTApproved: Slta Waiver <sltawvr@motorola.com>\nTested-by: Jira Key <jirakey@motorola.com>\nReviewed-by: Christopher Fries <cfries@motorola.com>\nSubmit-Approved: Jira Key <jirakey@motorola.com>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Riddlah/hells-Core-N6/commits/f7eb2f96329a02781698731b71a3bdf8156b11d6"},{"sha":"57733f0d78b948343c05122ece55c1f039597bc0","author":{"email":"00cdc6fa627ebc82497840cfa79e238eb1a6f9be@gmx.ch","name":"hellsgod"},"message":"msm: thermal: Higher temp threshold to 70°C","distinct":true,"url":"https://api.github.com/repos/Riddlah/hells-Core-N6/commits/57733f0d78b948343c05122ece55c1f039597bc0"},{"sha":"6a5ee66398ed8c9f57a906b9bbcb6be297ab11fa","author":{"email":"00cdc6fa627ebc82497840cfa79e238eb1a6f9be@gmx.ch","name":"hellsgod"},"message":"build: b11-t3","distinct":true,"url":"https://api.github.com/repos/Riddlah/hells-Core-N6/commits/6a5ee66398ed8c9f57a906b9bbcb6be297ab11fa"},{"sha":"8d60d1770b72b73790863ae65105e0145777e11a","author":{"email":"4aa5652442886f3c4e77d3a743dc27e129c1613f@hp.com","name":"Davidlohr Bueso"},"message":"futexes: Increase hash table size for better performance\n\nCurrently, the futex global hash table suffers from its fixed,\nsmallish (for today's standards) size of 256 entries, as well as\nits lack of NUMA awareness. Large systems, using many futexes,\ncan be prone to high amounts of collisions; where these futexes\nhash to the same bucket and lead to extra contention on the same\nhb->lock. Furthermore, cacheline bouncing is a reality when we\nhave multiple hb->locks residing on the same cacheline and\ndifferent futexes hash to adjacent buckets.\n\nThis patch keeps the current static size of 16 entries for small\nsystems, or otherwise, 256 * ncpus (or larger as we need to\nround the number to a power of 2). Note that this number of CPUs\naccounts for all CPUs that can ever be available in the system,\ntaking into consideration things like hotpluging. While we do\nimpose extra overhead at bootup by making the hash table larger,\nthis is a one time thing, and does not shadow the benefits of\nthis patch.\n\nFurthermore, as suggested by tglx, by cache aligning the hash\nbuckets we can avoid access across cacheline boundaries and also\navoid massive cache line bouncing if multiple cpus are hammering\naway at different hash buckets which happen to reside in the\nsame cache line.\n\nAlso, similar to other core kernel components (pid, dcache,\ntcp), by using alloc_large_system_hash() we benefit from its\nNUMA awareness and thus the table is distributed among the nodes\ninstead of in a single one.\n\nFor a custom microbenchmark that pounds on the uaddr hashing --\nmaking the wait path fail at futex_wait_setup() returning\n-EWOULDBLOCK for large amounts of futexes, we can see the\nfollowing benefits on a 80-core, 8-socket 1Tb server:\n\n +---------+--------------------+------------------------+-----------------------+-------------------------------+\n | threads | baseline (ops/sec) | aligned-only (ops/sec) | large table (ops/sec) | large table+aligned (ops/sec) |\n +---------+--------------------+------------------------+-----------------------+-------------------------------+\n |     512 |              32426 | 50531  (+55.8%)        | 255274  (+687.2%)     | 292553  (+802.2%)             |\n |     256 |              65360 | 99588  (+52.3%)        | 443563  (+578.6%)     | 508088  (+677.3%)             |\n |     128 |             125635 | 200075 (+59.2%)        | 742613  (+491.1%)     | 835452  (+564.9%)             |\n |      80 |             193559 | 323425 (+67.1%)        | 1028147 (+431.1%)     | 1130304 (+483.9%)             |\n |      64 |             247667 | 443740 (+79.1%)        | 997300  (+302.6%)     | 1145494 (+362.5%)             |\n |      32 |             628412 | 721401 (+14.7%)        | 965996  (+53.7%)      | 1122115 (+78.5%)              |\n +---------+--------------------+------------------------+-----------------------+-------------------------------+\n\nReviewed-by: Darren Hart <dvhart@linux.intel.com>\nReviewed-by: Peter Zijlstra <peterz@infradead.org>\nReviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>\nReviewed-by: Waiman Long <Waiman.Long@hp.com>\nReviewed-and-tested-by: Jason Low <jason.low2@hp.com>\nReviewed-by: Thomas Gleixner <tglx@linutronix.de>\nSigned-off-by: Davidlohr Bueso <davidlohr@hp.com>\nCc: Mike Galbraith <efault@gmx.de>\nCc: Jeff Mahoney <jeffm@suse.com>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Scott Norton <scott.norton@hp.com>\nCc: Tom Vaden <tom.vaden@hp.com>\nCc: Aswin Chandramouleeswaran <aswin@hp.com>\nLink: http://lkml.kernel.org/r/1389569486-25487-3-git-send-email-davidlohr@hp.com\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: Paul Reioux <reioux@gmail.com>\n\nModified for Nexus 9\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>\nSigned-off-by: engstk <eng.stk@sapo.pt>\n\nConflicts:\n\tkernel/futex.c\n\nConflicts:\n\tkernel/futex.c\n\nConflicts:\n\tkernel/futex.c\n\nSigned-off-by: engstk <eng.stk@sapo.pt>","distinct":true,"url":"https://api.github.com/repos/Riddlah/hells-Core-N6/commits/8d60d1770b72b73790863ae65105e0145777e11a"},{"sha":"c2aa3a5b9e5af8496a3d4a537910438b6c90c7c6","author":{"email":"5db23874f34e45d59c69d81cd72d048d558566d7@gmail.com","name":"anarkia1976"},"message":"PM: Enable asynchronous noirq resume threads to save the resuming time\n\nSubject\t[PATCH] PM: Enable asynchronous noirq resume threads to save the resuming time\nFrom\tChuansheng Liu <>\nDate\tTue, 14 Jan 2014 15:18:08 +0800\n\nCurrently, the dpm_resume_noirq() is done synchronously, and for PCI devices\npci_pm_resume_noirq():\n\npci_pm_resume_noirq()\n pci_pm_default_resume_early()\n  pci_power_up()\n   pci_raw_set_power_state()\nWhich set the device from D3hot to D0 mostly, for every device, there will\nbe one 10ms(pci_pm_d3_delay) to wait.\n\nHence normally dpm_resume_noirq() will cost > 100ms, which is bigger for mobile\nplatform.\nHere implementing it with asynchronous way which will reduce much.\n\nFor example below, The 80% time is saved.\nWith synchronous way:\n[ 1411.272218] PM: noirq resume of devices complete after 92.223 msecs\nWith asynchronous way:\n[  110.616735] PM: noirq resume of devices complete after 10.544 msecs\n\nSigned-off-by: Liu, Chuansheng <chuansheng.liu@intel.com>","distinct":true,"url":"https://api.github.com/repos/Riddlah/hells-Core-N6/commits/c2aa3a5b9e5af8496a3d4a537910438b6c90c7c6"},{"sha":"94b5ce1ca09813a8986a1bb00ee460d75d3df6b9","author":{"email":"99f39d96f0d0b011d351b608fe7e2870596fa4a9@gmail.com","name":"Pranith Kumar"},"message":"rcu: Check both root and current rcu_node when setting up future grace period\n\nThe rcu_start_future_gp() function checks the current rcu_node's ->gpnum\nand ->completed twice, once without ACCESS_ONCE() and once with it.\nWhich is pointless because we hold that rcu_node's ->lock at that point.\nThe intent was to check the current rcu_node structure and the root\nrcu_node structure, the latter locklessly with ACCESS_ONCE().  This\ncommit therefore makes that change.\n\nThe reason that it is safe to locklessly check the root rcu_nodes's\n->gpnum and ->completed fields is that we hold the current rcu_node's\n->lock, which constrains the root rcu_node's ability to change its\n->gpnum and ->completed fields.  Of course, if there is a single rcu_node\nstructure, then rnp_root==rnp, and holding the lock prevents all changes.\nIf there is more than one rcu_node structure, then the code updates the\nfields in the following order:\n\n1.\tIncrement rnp_root->gpnum to start new grace period.\n2.\tIncrement rnp->gpnum to initialize the current rcu_node,\n\tcontinuing initialization for the new grace period.\n3.\tIncrement rnp_root->completed to end the current grace period.\n4.\tIncrement rnp->completed to continue cleaning up after the\n\told grace period.\n\nSo there are four possible combinations of relative values of these\nfour fields:\n\nN   N   N   N:  RCU idle, new grace period must be initiated.\n\t\tAlthough rnp_root->gpnum might be incremented immediately\n\t\tafter we check, that will just result in unnecessary work.\n\t\tThe grace period already started, and we try to start it.\n\nN+1 N   N   N:  RCU grace period just started.  No further change is\n\t\tpossible because we hold rnp->lock, so the checks of\n\t\trnp_root->gpnum and rnp_root->completed are stable.\n\t\tWe know that our request for a future grace period will\n\t\tbe seen during grace-period cleanup.\n\nN+1 N   N+1 N:  RCU grace period is ongoing.  Because rnp->gpnum is\n\t\tdifferent than rnp->completed, we won't even look at\n\t\trnp_root->gpnum and rnp_root->completed, so the possible\n\t\tconcurrent change to rnp_root->completed does not matter.\n\t\tWe know that our request for a future grace period will\n\t\tbe seen during grace-period cleanup, which cannot pass\n\t\tthis rcu_node because we hold its ->lock.\n\nN+1 N+1 N+1 N:  RCU grace period has ended, but not yet been cleaned up.\n\t\tBecause rnp->gpnum is different than rnp->completed, we\n\t\twon't look at rnp_root->gpnum and rnp_root->completed, so\n\t\tthe possible concurrent change to rnp_root->completed does\n\t\tnot matter.  We know that our request for a future grace\n\t\tperiod will be seen during grace-period cleanup, which\n\t\tcannot pass this rcu_node because we hold its ->lock.\n\nTherefore, despite initial appearances, the lockless check is safe.\n\nSigned-off-by: Pranith Kumar <bobby.prani@gmail.com>\n[ paulmck: Update comment to say why the lockless check is safe. ]\nSigned-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>\nGit-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git\nGit-commit: 48bd8e9b82a750b983823f391c67e70553757afa\nSigned-off-by: Kishan Kumar <kishank@codeaurora.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Riddlah/hells-Core-N6/commits/94b5ce1ca09813a8986a1bb00ee460d75d3df6b9"},{"sha":"e5a4394368e88ea9e2c90bfb974377c7e32682d6","author":{"email":"2c98d18550b6e94ee93faf6d92fa2bedb58842c9@codeaurora.org","name":"Patrick Daly"},"message":"rcu: Fix missing task information during rcu-preempt stall\n\nThe first item list_for_each_entry_continue(alist) iterates over is\nalist->next, rather than alist itself. Consequently,\nrcu_print_detail_task_stall_rnp() skips the task referenced by gp_tasks.\n\nUse gp_tasks->prev as the argument to list_for_each_entry_continue()\ninstead.\n\nChange-Id: Iaa2be14139d0f6c1a1ed25817f0e5737b3e74753\nSigned-off-by: Patrick Daly <pdaly@codeaurora.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Riddlah/hells-Core-N6/commits/e5a4394368e88ea9e2c90bfb974377c7e32682d6"},{"sha":"a5be49378720a5e637f20769bfc3ae093c64cb99","author":{"email":"1e0ce936bb9b355d257bf5790d2513c3f28be22b@linux.vnet.ibm.com","name":"Paul E. McKenney"},"message":"rcu: Avoid redundant grace-period kthread wakeups\n\nWhen setting up an in-the-future \"advanced\" grace period, the code needs\nto wake up the relevant grace-period kthread, which it currently does\nunconditionally.  However, this results in needless wakeups in the case\nwhere the advanced grace period is being set up by the grace-period\nkthread itself, which is a non-uncommon situation.  This commit therefore\nchecks to see if the running thread is the grace-period kthread, and\navoids doing the irq_work_queue()-mediated wakeup in that case.\n\nSigned-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>\nReviewed-by: Josh Triplett <josh@joshtriplett.org>\nGit-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git\nGit-commit: 1eafd31c640d6799c63136246a59d608bed93c74\n[kishank@codeaurora.org resolve trivial conflicts]\nSigned-off-by: Kishan Kumar <kishank@codeaurora.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>\n\nChange-Id: I1fdcf6664fdc7dce188488f05f33931e3614c853","distinct":true,"url":"https://api.github.com/repos/Riddlah/hells-Core-N6/commits/a5be49378720a5e637f20769bfc3ae093c64cb99"},{"sha":"67508d2bf05bdac4910d718c5d9be1e8d7c197da","author":{"email":"1e0ce936bb9b355d257bf5790d2513c3f28be22b@linux.vnet.ibm.com","name":"Paul E. McKenney"},"message":"rcu: Prevent spurious-wakeup DoS attack on rcu_gp_kthread()\n\nSpurious wakeups in the force-quiescent-state loop in rcu_gp_kthread()\ncause the timeout to be recalculated, which would prevent rcu_gp_fqs()\nfrom ever being called.  This would in turn would prevent the grace period\nfrom ever ending for as long as there was at least one CPU in an extended\nquiescent state that had not yet passed through a quiescent state.\n\nThis commit therefore avoids recalculating the timeout unless the\nprevious pass's call to wait_event_interruptible_timeout() actually\ndid time out, thus preventing the above scenario.\n\nSigned-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>\nGit-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git\nGit-commit: 88d6df612cc3c99f56cc18461fcc531c3a145544\n[kishank@codeaurora.org resolve trivial conflicts]\nSigned-off-by: Kishan Kumar <kishank@codeaurora.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>\n\nChange-Id: I43f22a80d4334ea5a7105a6da6f929239df76a11","distinct":true,"url":"https://api.github.com/repos/Riddlah/hells-Core-N6/commits/67508d2bf05bdac4910d718c5d9be1e8d7c197da"},{"sha":"b378d684b5344571b3c8a69dfdeafb3a041bdbf0","author":{"email":"1e0ce936bb9b355d257bf5790d2513c3f28be22b@linux.vnet.ibm.com","name":"Paul E. McKenney"},"message":"rcu: Throttle rcu_try_advance_all_cbs() execution\n\nThe rcu_try_advance_all_cbs() function is invoked on each attempted\nentry to and every exit from idle.  If this function determines that\nthere are callbacks ready to invoke, the caller will invoke the RCU\ncore, which in turn will result in a pair of context switches.  If a\nCPU enters and exits idle extremely frequently, this can result in\nan excessive number of context switches and high CPU overhead.\n\nThis commit therefore causes rcu_try_advance_all_cbs() to throttle\nitself, refusing to do work more than once per jiffy.\n\nReported-by: Tibor Billes <tbilles@gmx.com>\nSigned-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>\nTested-by: Tibor Billes <tbilles@gmx.com>\nReviewed-by: Josh Triplett <josh@joshtriplett.org>\nGit-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git\nGit-commit: c229828ca6bc62d6c654f64b1d1b8a9ebd8a56f3\n[kishank@codeaurora.org resolve trivial conflicts]\nSigned-off-by: Kishan Kumar <kishank@codeaurora.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>\n\nChange-Id: I994ee4ace082863b5e2943be5616ea83d5d345fb","distinct":true,"url":"https://api.github.com/repos/Riddlah/hells-Core-N6/commits/b378d684b5344571b3c8a69dfdeafb3a041bdbf0"},{"sha":"3607c18ecae5d1d15f5d2d1bfbf7348e67007dff","author":{"email":"1e0ce936bb9b355d257bf5790d2513c3f28be22b@linux.vnet.ibm.com","name":"Paul E. McKenney"},"message":"rcu: Protect ->gp_flags accesses with ACCESS_ONCE()\n\nA number of ->gp_flags accesses don't have ACCESS_ONCE(), but all of\nthe can race against other loads or stores.  This commit therefore\napplies ACCESS_ONCE() to the unprotected ->gp_flags accesses.\n\nReported-by: Alexey Roytman <alexey.roytman@oracle.com>\nSigned-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>\nReviewed-by: Josh Triplett <josh@joshtriplett.org>\nGit-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git\nGit-commit: 91dc95427a0d30ac2c58d6e943c7f40a3f25d908\n[kishank@codeaurora.org resolve trivial conflicts]\nSigned-off-by: Kishan Kumar <kishank@codeaurora.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>\n\nChange-Id: I2ed581b545fb9c93468658fa621e71c091ec250b","distinct":true,"url":"https://api.github.com/repos/Riddlah/hells-Core-N6/commits/3607c18ecae5d1d15f5d2d1bfbf7348e67007dff"},{"sha":"b349ecd440b04db403eeaa37b0c4d4dc02f0f85c","author":{"email":"1e0ce936bb9b355d257bf5790d2513c3f28be22b@linux.vnet.ibm.com","name":"Paul E. McKenney"},"message":"rcu: Update cpu_needs_another_gp() for futures from non-NOCB CPUs\n\nIn the old days, the only source of requests for future grace periods\nwas NOCB CPUs.  This has changed: CPUs routinely post requests for\nfuture grace periods in order to promote power efficiency and reduce\nOS jitter with minimal impact on grace-period latency.  This commit\ntherefore updates cpu_needs_another_gp() to invoke rcu_future_needs_gp()\ninstead of rcu_nocb_needs_gp().  The latter is no longer used, so is\nnow removed.  This commit also adds tracing for the irq_work_queue()\nwakeup case.\n\nChange-Id: Ifafd85017d358804b0b7a757ef68c1aebf435a99\nSigned-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>\nReviewed-by: Josh Triplett <josh@joshtriplett.org>\nGit-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git\nGit-commit: 365187fbc04fd55766bf6a94e37e558505bf480a\nSigned-off-by: Kishan Kumar <kishank@codeaurora.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Riddlah/hells-Core-N6/commits/b349ecd440b04db403eeaa37b0c4d4dc02f0f85c"},{"sha":"1aef84aba12311febf8d8711a3677d8d775b9055","author":{"email":"45d857216ef082c1ddfd5d3991b4f3d23f51761f@arcor.de","name":"myfluxi"},"message":"arm: irq: Tone down kernel logging\n\nChange-Id: Ie31190bd65d1379de41e1ca2573aa65e785de1b6","distinct":true,"url":"https://api.github.com/repos/Riddlah/hells-Core-N6/commits/1aef84aba12311febf8d8711a3677d8d775b9055"}]}