GitHub PushEvent at 2014-12-23 02:56:15
Repository: Finnys_Kernel_MAKO-Lollipop
Actor: 19cam92
Payload: {"shas":[["3e96e6768a38b58ac83f55e0d368e6a6687376d4","596727c8a0ea4db3ba2ceceedccbacd3d7b371b8@suse.cz","writeback: Fix occasional slow sync(1)\n\nIn case when system contains no dirty pages, wakeup_flusher_threads()\nwill submit WB_SYNC_NONE writeback for 0 pages so wb_writeback() exits\nimmediately without doing anything. Thus sync(1) will write all the\ndirty inodes from a WB_SYNC_ALL writeback pass which is slow.\n\nFix the problem by using get_nr_dirty_pages() in\nwakeup_flusher_threads() instead of calculating number of dirty pages\nmanually. That function also takes number of dirty inodes into account.\n\nCC: stable@vger.kernel.org\nReported-by: Paul Taysom <taysom@chromium.org>\nSigned-off-by: Jan Kara <jack@suse.cz>\nSigned-off-by: Cristoforo Cataldo <cristoforo.cataldo@gmail.com>\nSigned-off-by: Francisco Franco <franciscofranco.1990@gmail.com>","Jan Kara",true],["27c83a7b84975ba743f5d9cf7483035fac27fb71","9edab3d8932dbb8f20eb55cd8199c20e7fb56c12@oracle.com","binfmt_elf.c: use get_random_int() to fix entropy depleting\n\nChanges:\n--------\nv4->v3:\n- s/random_stack_user()/get_atrandom_bytes()/\n- Move this function to ahead of its use to avoid the predeclaration.\n\nv3->v2:\n- Tweak code comments of random_stack_user().\n- Remove redundant bits mask and shift upon the random variable.\n\nv2->v1:\n- Fix random copy to check up buffer length that are not 4-byte multiples.\n\nv3 can be found at:\nhttp://www.spinics.net/lists/linux-fsdevel/msg59597.html\nv2 can be found at:\nhttp://www.spinics.net/lists/linux-fsdevel/msg59418.html\nv1 can be found at:\nhttp://www.spinics.net/lists/linux-fsdevel/msg59128.html\n\nThanks,\n-Jeff\n\nEntropy is quickly depleted under normal operations like ls(1), cat(1),\netc...  between 2.6.30 to current mainline, for instance:\n\n$ cat /proc/sys/kernel/random/entropy_avail\n3428\n$ cat /proc/sys/kernel/random/entropy_avail\n2911\n$cat /proc/sys/kernel/random/entropy_avail\n2620\n\nWe observed this problem has been occurring since 2.6.30 with\nfs/binfmt_elf.c: create_elf_tables()->get_random_bytes(), introduced by\nf06295b44c296c8f (\"ELF: implement AT_RANDOM for glibc PRNG seeding\").\n\n/*\n * Generate 16 random bytes for userspace PRNG seeding.\n */\nget_random_bytes(k_rand_bytes, sizeof(k_rand_bytes));\n\nThe patch introduces a wrapper around get_random_int() which has lower\noverhead than calling get_random_bytes() directly.\n\nWith this patch applied:\n$ cat /proc/sys/kernel/random/entropy_avail\n2731\n$ cat /proc/sys/kernel/random/entropy_avail\n2802\n$ cat /proc/sys/kernel/random/entropy_avail\n2878\n\nAnalyzed by John Sobecki.\n\nSigned-off-by: Jie Liu <jeff.liu@oracle.com>\nCc: Andrew Morton <akpm@linux-foundation.org>\nCc: Al Viro <viro@zeniv.linux.org.uk>\nCc: Andreas Dilger <aedilger@gmail.com>\nCc: Alan Cox <alan@linux.intel.com>\nCc: Arnd Bergmann <arnn@arndb.de>\nCc: John Sobecki <john.sobecki@oracle.com>\nCc: James Morris <james.l.morris@oracle.com>\nCc: Jakub Jelinek <jakub@redhat.com>\nCc: Ted Ts'o <tytso@mit.edu>\nCc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nCc: Kees Cook <keescook@chromium.org>\nCc: Ulrich Drepper <drepper@redhat.com>\nSigned-off-by: Francisco Franco <franciscofranco.1990@gmail.com>","Jeff Liu",true],["3d0f6220d87726630ed52fe1935732a3c8c84560","ff2255678f98b74f3d00c9625c56237df87579fc@codeaurora.org","cpufreq: Use dedicated high-priority workqueues\n\nIn the process of scaling CPU frequencies, cpufreq and the APIS is\ncalls may hold resources that will prevent threads critical for\nsystem stability from running.\n\nSpecifically, thermal-mitigation software may need to respond\nquickly to high-temperature conditions and throttle the CPU speed\nin an effort to cool down. If the system is already in the middle\nof a CPU frequency switch being executed on behalf of a cpufreq\ngovernor, thermal mitigation will be blocked until the scaling\naction has completed. If the system is under heave load of medium\nor high-priority threads, this may take a long while and the system\nmay potentially surpass thermal limits in the meantime.\n\nResolve this by using high priority workqueues for all ondemand\nand conservative governor scaling operations.  This will allow them\nto complete promptly and release their hold on resources necessary\nfor maintaining system stability.\n\nChange-Id: I2f56052c131442838036cf4cdd8059f7c09bb805\nSigned-off-by: Matt Wagantall <mattw@codeaurora.org>\nSigned-off-by: Ajay Dudani <adudani@codeaurora.org>","Ajay Dudani",true]],"size":3,"ref":"refs/heads/lollipop","head":"3d0f6220d87726630ed52fe1935732a3c8c84560"}