{"push_id":936585519,"size":31,"distinct_size":31,"ref":"refs/heads/cm-13.0","head":"11a85dc195204ea09ab71f82c113c4b65bfddd64","before":"0e4d532035c5fdb07c2f2015e09377a2c0cf2390","commits":[{"sha":"a9613f052f444786d030b638317274ff2fa05522","author":{"email":"e36519ed998e577ca4306dc3c35b89f0bef834f3@codeaurora.org","name":"Arun Kumar Neelakantam"},"message":"driver: soc: bam_dmux: Fix spinlock lock-up\n\nClient invoking the BAM DMUX function from callback notifier and\ncalling the callback notifier by acquiring channel spinlock triggers\nspinlock lock-up.\n\nRemove the notifier callback from the spinlock context.\n\nCRs-Fixed: 780192\nChange-Id: Ic01c4d605510a68624dd9a14c35927892f1721d1\nSigned-off-by: Arun Kumar Neelakantam <aneela@codeaurora.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/kabata1975/android_kernel_lge_hammerhead/commits/a9613f052f444786d030b638317274ff2fa05522"},{"sha":"fd18fcad5ce53f1112bf79eeb12cafa6b0c87af7","author":{"email":"45d857216ef082c1ddfd5d3991b4f3d23f51761f@arcor.de","name":"myfluxi"},"message":"arm: irq: Tone down kernel logging\n\nChange-Id: Ie31190bd65d1379de41e1ca2573aa65e785de1b6\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/kabata1975/android_kernel_lge_hammerhead/commits/fd18fcad5ce53f1112bf79eeb12cafa6b0c87af7"},{"sha":"293c8223ce7110e84af99de847788be88f2a238f","author":{"email":"a781eab460d0b8de6413720f3ae4346867408d60@codeaurora.org","name":"Alok Chauhan"},"message":"msm: msm_bus: Suspected fix for deadlock\n\nmutex is not released while checking for\nnull pdata which can lead to possible deadlock\ncondition.\n\nChange-Id: I1dc3efd725df5bb75c96434a81d9a8f3f868cd0a\nSigned-off-by: Alok Chauhan <alokc@codeaurora.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/kabata1975/android_kernel_lge_hammerhead/commits/293c8223ce7110e84af99de847788be88f2a238f"},{"sha":"28311fdc2cb7cbd9d905acd030d45422ef06d2e7","author":{"email":"c43481fc2362b08b051529352778e8900b7620d1@intel.com","name":"Chen Tingjie"},"message":"tty: fix memleak in alloc_pid\n\nThere is memleak in alloc_pid:\n------------------------------\nunreferenced object 0xd3453a80 (size 64):\n  comm \"adbd\", pid 1730, jiffies 66363 (age 6586.950s)\n  hex dump (first 32 bytes):\n    01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n    00 00 00 00 40 c2 f6 d5 00 d3 25 c1 59 28 00 00  ....@.....%.Y(..\n  backtrace:\n    [<c1a6f15c>] kmemleak_alloc+0x3c/0xa0\n    [<c1320546>] kmem_cache_alloc+0xc6/0x190\n    [<c125d51e>] alloc_pid+0x1e/0x400\n    [<c123d344>] copy_process.part.39+0xad4/0x1120\n    [<c123da59>] do_fork+0x99/0x330\n    [<c123dd58>] sys_fork+0x28/0x30\n    [<c1a89a08>] syscall_call+0x7/0xb\n    [<ffffffff>] 0xffffffff\n\nthe leak is due to unreleased pid->count, which execute in function:\nget_pid()(pid->count++) and put_pid()(pid->count--).\n\nThe race condition as following:\ntask[dumpsys]               task[adbd]\nin disassociate_ctty()      in tty_signal_session_leader()\n-----------------------     -------------------------\ntty = get_current_tty();\n// tty is not NULL\n...\nspin_lock_irq(&current->sighand->siglock);\nput_pid(current->signal->tty_old_pgrp);\ncurrent->signal->tty_old_pgrp = NULL;\nspin_unlock_irq(&current->sighand->siglock);\n\n                            spin_lock_irq(&p->sighand->siglock);\n                            ...\n                            p->signal->tty = NULL;\n                            ...\n                            spin_unlock_irq(&p->sighand->siglock);\n\ntty = get_current_tty();\n// tty NULL, goto else branch by accident.\nif (tty) {\n    ...\n    put_pid(tty_session);\n    put_pid(tty_pgrp);\n    ...\n} else {\n    print msg\n}\n\nin task[dumpsys], in disassociate_ctty(), tty is set NULL by task[adbd],\ntty_signal_session_leader(), then it goto else branch and lack of\nput_pid(), cause memleak.\n\nmove spin_unlock(sighand->siglock) after get_current_tty() can avoid\nthe race and fix the memleak.\n\nChange-Id: I6d141cb80b1296643c76d842eb9b12afad5760d5\nSigned-off-by: Zhang Jun <jun.zhang@intel.com>\nSigned-off-by: Chen Tingjie <tingjie.chen@intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nGit-commit: c70dbb1e79a1ac2802b4b7b6de7456b230fbbbeb\nGit-repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git\nSigned-off-by: Osvaldo Banuelos <osvaldob@codeaurora.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/kabata1975/android_kernel_lge_hammerhead/commits/28311fdc2cb7cbd9d905acd030d45422ef06d2e7"},{"sha":"82c78e444ed5132c628ae2b756f8956eef0dbfca","author":{"email":"45d857216ef082c1ddfd5d3991b4f3d23f51761f@arcor.de","name":"myfluxi"},"message":"msm: bam_dmux: Reduce debug logs to avoid watchdog bite\n\nChange-Id: Ib4d920e6f9f84f33991dae7d17129b41ba9cda28\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/kabata1975/android_kernel_lge_hammerhead/commits/82c78e444ed5132c628ae2b756f8956eef0dbfca"},{"sha":"e2c900d2071244c79949ff998ebdd9ec50363166","author":{"email":"8c1011c9d06fc72acd93645d683782ab9543044d@google.com","name":"Michael Halcrow"},"message":"eCryptfs: Remove buggy and unnecessary write in file name decode routine\n\nDmitry Chernenkov used KASAN to discover that eCryptfs writes past the\nend of the allocated buffer during encrypted filename decoding. This\nfix corrects the issue by getting rid of the unnecessary 0 write when\nthe current bit offset is 2.\n\nSigned-off-by: Michael Halcrow <mhalcrow@google.com>\nReported-by: Dmitry Chernenkov <dmitryc@google.com>\nSuggested-by: Kees Cook <keescook@chromium.org>\nCc: stable@vger.kernel.org # v2.6.29+: 51ca58d eCryptfs: Filename Encryption: Encoding and encryption functions\nSigned-off-by: Tyler Hicks <tyhicks@canonical.com>\n\nset topic to  CVE-2014-9683\nChange-Id: Idbed01a48c2f0fa49a140f89d2f1caca65cb7b8a\n\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/kabata1975/android_kernel_lge_hammerhead/commits/e2c900d2071244c79949ff998ebdd9ec50363166"},{"sha":"b5e82117609a4edda8a982ecf39098dfe33f36ca","author":{"email":"eec72676ad9a62f2727dfed6d270d98c0d02adec@linux.intel.com","name":"Kirill A. Shutemov"},"message":"mm: Fix NULL pointer dereference in madvise(MADV_WILLNEED) support\n\nSasha Levin found a NULL pointer dereference that is due to a missing\npage table lock, which in turn is due to the pmd entry in question being\na transparent huge-table entry.\n\nThe code - introduced in commit 1998cc048901 (\"mm: make\nmadvise(MADV_WILLNEED) support swap file prefetch\") - correctly checks\nfor this situation using pmd_none_or_trans_huge_or_clear_bad(), but it\nturns out that that function doesn't work correctly.\n\npmd_none_or_trans_huge_or_clear_bad() expected that pmd_bad() would\ntrigger if the transparent hugepage bit was set, but it doesn't do that\nif pmd_numa() is also set. Note that the NUMA bit only gets set on real\nNUMA machines, so people trying to reproduce this on most normal\ndevelopment systems would never actually trigger this.\n\nFix it by removing the very subtle (and subtly incorrect) expectation,\nand instead just checking pmd_trans_huge() explicitly.\n\nReported-by: Sasha Levin <sasha.levin@oracle.com>\nAcked-by: Andrea Arcangeli <aarcange@redhat.com>\n[ Additionally remove the now stale test for pmd_trans_huge() inside the\n  pmd_bad() case - Linus ]\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n\nChange-Id: I3f3763f236ef102de735297cd175cf514d40d28f\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/kabata1975/android_kernel_lge_hammerhead/commits/b5e82117609a4edda8a982ecf39098dfe33f36ca"},{"sha":"d87e72084f11553789bebec8bafdfef4a65f25ea","author":{"email":"e642b69ed2fc111e09ffdc37feb733a52253340d@oracle.com","name":"Sasha Levin"},"message":"vfs: read file_handle only once in handle_to_path\n\nWe used to read file_handle twice. Once to get the amount of extra bytes, and\nonce to fetch the entire structure.\n\nThis may be problematic since we do size verifications only after the first\nread, so if the number of extra bytes changes in userspace between the first\nand second calls, we'll have an incoherent view of file_handle.\n\nInstead, read the constant size once, and copy that over to the final\nstructure without having to re-read it again.\n\nChange-Id: Ib05e5129629e27d5a05953098c5bc470fae40d2a\nSigned-off-by: Sasha Levin <sasha.levin@oracle.com>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/kabata1975/android_kernel_lge_hammerhead/commits/d87e72084f11553789bebec8bafdfef4a65f25ea"},{"sha":"1bff7a9ee61dc6aad90b8213ce4455cd27744a2f","author":{"email":"e36519ed998e577ca4306dc3c35b89f0bef834f3@codeaurora.org","name":"Arun Kumar Neelakantam"},"message":"driver: soc: bam_dmux: Fix spinlock lock-up\n\nClient invoking the BAM DMUX function from callback notifier and\ncalling the callback notifier by acquiring channel spinlock triggers\nspinlock lock-up.\n\nRemove the notifier callback from the spinlock context.\n\nCRs-Fixed: 780192\nChange-Id: Ic01c4d605510a68624dd9a14c35927892f1721d1\nSigned-off-by: Arun Kumar Neelakantam <aneela@codeaurora.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/kabata1975/android_kernel_lge_hammerhead/commits/1bff7a9ee61dc6aad90b8213ce4455cd27744a2f"},{"sha":"8e854978ca17133956b55dcab57d65b4c8453b90","author":{"email":"4c9eb49378914b743bdd32292c04df29b820d73e@cn.fujitsu.com","name":"Lai Jiangshan"},"message":"smpboot: Add missing get_online_cpus() in smpboot_register_percpu_thread()\n\nThe following race exists in the smpboot percpu threads management:\n\nCPU0\t      \t   \t     CPU1\ncpu_up(2)\n  get_online_cpus();\n  smpboot_create_threads(2);\n\t\t\t     smpboot_register_percpu_thread();\n\t\t\t     for_each_online_cpu();\n\t\t\t       __smpboot_create_thread();\n  __cpu_up(2);\n\nThis results in a missing per cpu thread for the newly onlined cpu2 and\nin a NULL pointer dereference on a consecutive offline of that cpu.\n\nProctect smpboot_register_percpu_thread() with get_online_cpus() to\nprevent that.\n\n[ tglx: Massaged changelog and removed the change in\n        smpboot_unregister_percpu_thread() because that's an\n        optimization and therefor not stable material. ]\n\nSigned-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>\nCc: Thomas Gleixner <tglx@linutronix.de>\nCc: Rusty Russell <rusty@rustcorp.com.au>\nCc: Peter Zijlstra <peterz@infradead.org>\nCc: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>\nCc: David Rientjes <rientjes@google.com>\nCc: stable@vger.kernel.org\nLink: http://lkml.kernel.org/r/1406777421-12830-1-git-send-email-laijs@cn.fujitsu.com\nSigned-off-by: Thomas Gleixner <tglx@linutronix.de>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/kabata1975/android_kernel_lge_hammerhead/commits/8e854978ca17133956b55dcab57d65b4c8453b90"},{"sha":"b169f78d3532c0a6f8b03710df44da94c5aee322","author":{"email":"9aa0c5451ca4831c1a624707224dc3a3643d2fc2@motorola.com","name":"Bang Nguyen"},"message":"msm: mdss: Replace msleep() with usleep()\n\nReplace msleep() with usleep() in the display's voltage regulator\nenable/disable\n\nChange-Id: I6d151bc166a39698dc0cae90f6d46cfa7a8383fe\nSigned-off-by: Bang Nguyen <bnguyen1@motorola.com>","distinct":true,"url":"https://api.github.com/repos/kabata1975/android_kernel_lge_hammerhead/commits/b169f78d3532c0a6f8b03710df44da94c5aee322"},{"sha":"c1e8a769e6a0e6be6c1542aa165f7242cd7dbaea","author":{"email":"3fddac958924aef220f202ca567388ddab3f14a8@infradead.org","name":"Peter Zijlstra"},"message":"sched, smp: Correctly deal with nested sleeps\n\nsmp_hotplug_thread::{setup,unpark} functions can sleep too, so be\nconsistent and do the same for all callbacks.\n\n __might_sleep+0x74/0x80\n kmem_cache_alloc_trace+0x4e/0x1c0\n perf_event_alloc+0x55/0x450\n perf_event_create_kernel_counter+0x2f/0x100\n watchdog_nmi_enable+0x8d/0x160\n watchdog_enable+0x45/0x90\n smpboot_thread_fn+0xec/0x2b0\n kthread+0xe4/0x100\n ret_from_fork+0x7c/0xb0\n\nSigned-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>\nCc: tglx@linutronix.de\nCc: ilya.dryomov@inktank.com\nCc: umgwanakikbuti@gmail.com\nCc: oleg@redhat.com\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nLink: http://lkml.kernel.org/r/20140924082242.392279328@infradead.org\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/kabata1975/android_kernel_lge_hammerhead/commits/c1e8a769e6a0e6be6c1542aa165f7242cd7dbaea"},{"sha":"60eaebe9a6c8d4e1a1c13f0d69540b6deb953b92","author":{"email":"e642b69ed2fc111e09ffdc37feb733a52253340d@oracle.com","name":"Sasha Levin"},"message":"KEYS: close race between key lookup and freeing\n\nWhen a key is being garbage collected, it's key->user would get put before\nthe ->destroy() callback is called, where the key is removed from it's\nrespective tracking structures.\n\nThis leaves a key hanging in a semi-invalid state which leaves a window open\nfor a different task to try an access key->user. An example is\nfind_keyring_by_name() which would dereference key->user for a key that is\nin the process of being garbage collected (where key->user was freed but\n->destroy() wasn't called yet - so it's still present in the linked list).\n\nThis would cause either a panic, or corrupt memory.\n\nChange-Id: Ic74246dc2dcc593f04f71063e3301e7356d588b7\nSigned-off-by: Sasha Levin <sasha.levin@oracle.com>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/kabata1975/android_kernel_lge_hammerhead/commits/60eaebe9a6c8d4e1a1c13f0d69540b6deb953b92"},{"sha":"dccde34e9196834f255722c573a2f8fc2e272a62","author":{"email":"fac732170a1579defe9e057a895426984dcd2793@google.com","name":"Andrew Hunter"},"message":"jiffies: Fix timeval conversion to jiffies\n\ncommit d78c9300c51d6ceed9f6d078d4e9366f259de28c upstream.\n\ntimeval_to_jiffies tried to round a timeval up to an integral number\nof jiffies, but the logic for doing so was incorrect: intervals\ncorresponding to exactly N jiffies would become N+1. This manifested\nitself particularly repeatedly stopping/starting an itimer:\n\nsetitimer(ITIMER_PROF, &val, NULL);\nsetitimer(ITIMER_PROF, NULL, &val);\n\nwould add a full tick to val, _even if it was exactly representable in\nterms of jiffies_ (say, the result of a previous rounding.)  Doing\nthis repeatedly would cause unbounded growth in val.  So fix the math.\n\nHere's what was wrong with the conversion: we essentially computed\n(eliding seconds)\n\njiffies = usec  * (NSEC_PER_USEC/TICK_NSEC)\n\nby using scaling arithmetic, which took the best approximation of\nNSEC_PER_USEC/TICK_NSEC with denominator of 2^USEC_JIFFIE_SC =\nx/(2^USEC_JIFFIE_SC), and computed:\n\njiffies = (usec * x) >> USEC_JIFFIE_SC\n\nand rounded this calculation up in the intermediate form (since we\ncan't necessarily exactly represent TICK_NSEC in usec.) But the\nscaling arithmetic is a (very slight) *over*approximation of the true\nvalue; that is, instead of dividing by (1 usec/ 1 jiffie), we\neffectively divided by (1 usec/1 jiffie)-epsilon (rounding\ndown). This would normally be fine, but we want to round timeouts up,\nand we did so by adding 2^USEC_JIFFIE_SC - 1 before the shift; this\nwould be fine if our division was exact, but dividing this by the\nslightly smaller factor was equivalent to adding just _over_ 1 to the\nfinal result (instead of just _under_ 1, as desired.)\n\nIn particular, with HZ=1000, we consistently computed that 10000 usec\nwas 11 jiffies; the same was true for any exact multiple of\nTICK_NSEC.\n\nWe could possibly still round in the intermediate form, adding\nsomething less than 2^USEC_JIFFIE_SC - 1, but easier still is to\nconvert usec->nsec, round in nanoseconds, and then convert using\ntime*spec*_to_jiffies.  This adds one constant multiplication, and is\nnot observably slower in microbenchmarks on recent x86 hardware.\n\nTested: the following program:\n\nint main() {\n  struct itimerval zero = {{0, 0}, {0, 0}};\n  /* Initially set to 10 ms. */\n  struct itimerval initial = zero;\n  initial.it_interval.tv_usec = 10000;\n  setitimer(ITIMER_PROF, &initial, NULL);\n  /* Save and restore several times. */\n  for (size_t i = 0; i < 10; ++i) {\n    struct itimerval prev;\n    setitimer(ITIMER_PROF, &zero, &prev);\n    /* on old kernels, this goes up by TICK_USEC every iteration */\n    printf(\"previous value: %ld %ld %ld %ld\\n\",\n           prev.it_interval.tv_sec, prev.it_interval.tv_usec,\n           prev.it_value.tv_sec, prev.it_value.tv_usec);\n    setitimer(ITIMER_PROF, &prev, NULL);\n  }\n    return 0;\n}\n\nCc: Thomas Gleixner <tglx@linutronix.de>\nCc: Ingo Molnar <mingo@redhat.com>\nCc: Paul Turner <pjt@google.com>\nCc: Richard Cochran <richardcochran@gmail.com>\nCc: Prarit Bhargava <prarit@redhat.com>\nReviewed-by: Paul Turner <pjt@google.com>\nReported-by: Aaron Jacobs <jacobsa@google.com>\nSigned-off-by: Andrew Hunter <ahh@google.com>\n[jstultz: Tweaked to apply to 3.17-rc]\nSigned-off-by: John Stultz <john.stultz@linaro.org>\n[lizf: Backported to 3.4: adjust filename]\nSigned-off-by: Zefan Li <lizefan@huawei.com>\n\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>\n\nConflicts:\n\tkernel/time.c","distinct":true,"url":"https://api.github.com/repos/kabata1975/android_kernel_lge_hammerhead/commits/dccde34e9196834f255722c573a2f8fc2e272a62"},{"sha":"82c49178acd95870e60b7c729969483fcda63e3d","author":{"email":"22097694d54958bd3c75f6e60b2c5bd5c9ed5db4@yahoo.es","name":"kabata1975"},"message":"fix jiffies: Fix timeval conversion to jiffies","distinct":true,"url":"https://api.github.com/repos/kabata1975/android_kernel_lge_hammerhead/commits/82c49178acd95870e60b7c729969483fcda63e3d"},{"sha":"eff18c4c73d680b677624735d6fc8fa51a1f4592","author":{"email":"a21938f5d463ddf41aa718934c205ca2cce8ebbc@redhat.com","name":"Rik van Riel"},"message":"mm: remove swap token code\n\nThe swap token code no longer fits in with the current VM model.  It\ndoes not play well with cgroups or the better NUMA placement code in\ndevelopment, since we have only one swap token globally.\n\nIt also has the potential to mess with scalability of the system, by\nincreasing the number of non-reclaimable pages on the active and\ninactive anon LRU lists.\n\nLast but not least, the swap token code has been broken for a year\nwithout complaints, as reported by Konstantin Khlebnikov.  This suggests\nwe no longer have much use for it.\n\nThe days of sub-1G memory systems with heavy use of swap are over.  If\nwe ever need thrashing reducing code in the future, we will have to\nimplement something that does scale.\n\nSigned-off-by: Rik van Riel <riel@redhat.com>\nCc: Konstantin Khlebnikov <khlebnikov@openvz.org>\nAcked-by: Johannes Weiner <hannes@cmpxchg.org>\nCc: Mel Gorman <mel@csn.ul.ie>\nCc: Hugh Dickins <hughd@google.com>\nAcked-by: Bob Picco <bpicco@meloft.net>\nAcked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/kabata1975/android_kernel_lge_hammerhead/commits/eff18c4c73d680b677624735d6fc8fa51a1f4592"},{"sha":"151636446e8d08342f4ceb719ba97e02dec8e1f6","author":{"email":"39ea6a09710987173e32e37c86918024a0f441c1@suse.de","name":"Mel Gorman"},"message":"mm: vmscan: remove lumpy reclaim\n\nThis series removes lumpy reclaim and some stalling logic that was\nunintentionally being used by memory compaction.  The end result is that\nstalling on dirty pages during page reclaim now depends on\nwait_iff_congested().\n\nFour kernels were compared\n\n  3.3.0     vanilla\n  3.4.0-rc2 vanilla\n  3.4.0-rc2 lumpyremove-v2 is patch one from this series\n  3.4.0-rc2 nosync-v2r3 is the full series\n\nRemoving lumpy reclaim saves almost 900 bytes of text whereas the full\nseries removes 1200 bytes.\n\n     text     data      bss       dec     hex  filename\n  6740375  1927944  2260992  10929311  a6c49f  vmlinux-3.4.0-rc2-vanilla\n  6739479  1927944  2260992  10928415  a6c11f  vmlinux-3.4.0-rc2-lumpyremove-v2\n  6739159  1927944  2260992  10928095  a6bfdf  vmlinux-3.4.0-rc2-nosync-v2\n\nThere are behaviour changes in the series and so tests were run with\nmonitoring of ftrace events.  This disrupts results so the performance\nresults are distorted but the new behaviour should be clearer.\n\nfs-mark running in a threaded configuration showed little of interest as\nit did not push reclaim aggressively\n\n  FS-Mark Multi Threaded\n                          3.3.0-vanilla       rc2-vanilla       lumpyremove-v2r3       nosync-v2r3\n  Files/s  min           3.20 ( 0.00%)        3.20 ( 0.00%)        3.20 ( 0.00%)        3.20 ( 0.00%)\n  Files/s  mean          3.20 ( 0.00%)        3.20 ( 0.00%)        3.20 ( 0.00%)        3.20 ( 0.00%)\n  Files/s  stddev        0.00 ( 0.00%)        0.00 ( 0.00%)        0.00 ( 0.00%)        0.00 ( 0.00%)\n  Files/s  max           3.20 ( 0.00%)        3.20 ( 0.00%)        3.20 ( 0.00%)        3.20 ( 0.00%)\n  Overhead min      508667.00 ( 0.00%)   521350.00 (-2.49%)   544292.00 (-7.00%)   547168.00 (-7.57%)\n  Overhead mean     551185.00 ( 0.00%)   652690.73 (-18.42%)   991208.40 (-79.83%)   570130.53 (-3.44%)\n  Overhead stddev    18200.69 ( 0.00%)   331958.29 (-1723.88%)  1579579.43 (-8578.68%)     9576.81 (47.38%)\n  Overhead max      576775.00 ( 0.00%)  1846634.00 (-220.17%)  6901055.00 (-1096.49%)   585675.00 (-1.54%)\n  MMTests Statistics: duration\n  Sys Time Running Test (seconds)             309.90    300.95    307.33    298.95\n  User+Sys Time Running Test (seconds)        319.32    309.67    315.69    307.51\n  Total Elapsed Time (seconds)               1187.85   1193.09   1191.98   1193.73\n\n  MMTests Statistics: vmstat\n  Page Ins                                       80532       82212       81420       79480\n  Page Outs                                  111434984   111456240   111437376   111582628\n  Swap Ins                                           0           0           0           0\n  Swap Outs                                          0           0           0           0\n  Direct pages scanned                           44881       27889       27453       34843\n  Kswapd pages scanned                        25841428    25860774    25861233    25843212\n  Kswapd pages reclaimed                      25841393    25860741    25861199    25843179\n  Direct pages reclaimed                         44881       27889       27453       34843\n  Kswapd efficiency                                99%         99%         99%         99%\n  Kswapd velocity                            21754.791   21675.460   21696.029   21649.127\n  Direct efficiency                               100%        100%        100%        100%\n  Direct velocity                               37.783      23.375      23.031      29.188\n  Percentage direct scans                           0%          0%          0%          0%\n\nftrace showed that there was no stalling on writeback or pages submitted\nfor IO from reclaim context.\n\npostmark was similar and while it was more interesting, it also did not\npush reclaim heavily.\n\n  POSTMARK\n                                       3.3.0-vanilla       rc2-vanilla  lumpyremove-v2r3       nosync-v2r3\n  Transactions per second:               16.00 ( 0.00%)    20.00 (25.00%)    18.00 (12.50%)    17.00 ( 6.25%)\n  Data megabytes read per second:        18.80 ( 0.00%)    24.27 (29.10%)    22.26 (18.40%)    20.54 ( 9.26%)\n  Data megabytes written per second:     35.83 ( 0.00%)    46.25 (29.08%)    42.42 (18.39%)    39.14 ( 9.24%)\n  Files created alone per second:        28.00 ( 0.00%)    38.00 (35.71%)    34.00 (21.43%)    30.00 ( 7.14%)\n  Files create/transact per second:       8.00 ( 0.00%)    10.00 (25.00%)     9.00 (12.50%)     8.00 ( 0.00%)\n  Files deleted alone per second:       556.00 ( 0.00%)  1224.00 (120.14%)  3062.00 (450.72%)  6124.00 (1001.44%)\n  Files delete/transact per second:       8.00 ( 0.00%)    10.00 (25.00%)     9.00 (12.50%)     8.00 ( 0.00%)\n\n  MMTests Statistics: duration\n  Sys Time Running Test (seconds)             113.34    107.99    109.73    108.72\n  User+Sys Time Running Test (seconds)        145.51    139.81    143.32    143.55\n  Total Elapsed Time (seconds)               1159.16    899.23    980.17   1062.27\n\n  MMTests Statistics: vmstat\n  Page Ins                                    13710192    13729032    13727944    13760136\n  Page Outs                                   43071140    42987228    42733684    42931624\n  Swap Ins                                           0           0           0           0\n  Swap Outs                                          0           0           0           0\n  Direct pages scanned                               0           0           0           0\n  Kswapd pages scanned                         9941613     9937443     9939085     9929154\n  Kswapd pages reclaimed                       9940926     9936751     9938397     9928465\n  Direct pages reclaimed                             0           0           0           0\n  Kswapd efficiency                                99%         99%         99%         99%\n  Kswapd velocity                             8576.567   11051.058   10140.164    9347.109\n  Direct efficiency                               100%        100%        100%        100%\n  Direct velocity                                0.000       0.000       0.000       0.000\n\nIt looks like here that the full series regresses performance but as\nftrace showed no usage of wait_iff_congested() or sync reclaim I am\nassuming it's a disruption due to monitoring.  Other data such as memory\nusage, page IO, swap IO all looked similar.\n\nRunning a benchmark with a plain DD showed nothing very interesting.\nThe full series stalled in wait_iff_congested() slightly less but stall\ntimes on vanilla kernels were marginal.\n\nRunning a benchmark that hammered on file-backed mappings showed stalls\ndue to congestion but not in sync writebacks\n\n  MICRO\n                                       3.3.0-vanilla       rc2-vanilla  lumpyremove-v2r3       nosync-v2r3\n  MMTests Statistics: duration\n  Sys Time Running Test (seconds)             308.13    294.50    298.75    299.53\n  User+Sys Time Running Test (seconds)        330.45    316.28    318.93    320.79\n  Total Elapsed Time (seconds)               1814.90   1833.88   1821.14   1832.91\n\n  MMTests Statistics: vmstat\n  Page Ins                                      108712      120708       97224      110344\n  Page Outs                                  155514576   156017404   155813676   156193256\n  Swap Ins                                           0           0           0           0\n  Swap Outs                                          0           0           0           0\n  Direct pages scanned                         2599253     1550480     2512822     2414760\n  Kswapd pages scanned                        69742364    71150694    68839041    69692533\n  Kswapd pages reclaimed                      34824488    34773341    34796602    34799396\n  Direct pages reclaimed                         53693       94750       61792       75205\n  Kswapd efficiency                                49%         48%         50%         49%\n  Kswapd velocity                            38427.662   38797.901   37799.972   38022.889\n  Direct efficiency                                 2%          6%          2%          3%\n  Direct velocity                             1432.174     845.464    1379.807    1317.446\n  Percentage direct scans                           3%          2%          3%          3%\n  Page writes by reclaim                             0           0           0           0\n  Page writes file                                   0           0           0           0\n  Page writes anon                                   0           0           0           0\n  Page reclaim immediate                             0           0           0        1218\n  Page rescued immediate                             0           0           0           0\n  Slabs scanned                                  15360       16384       13312       16384\n  Direct inode steals                                0           0           0           0\n  Kswapd inode steals                             4340        4327        1630        4323\n\n  FTrace Reclaim Statistics: congestion_wait\n  Direct number congest     waited                 0          0          0          0\n  Direct time   congest     waited               0ms        0ms        0ms        0ms\n  Direct full   congest     waited                 0          0          0          0\n  Direct number conditional waited               900        870        754        789\n  Direct time   conditional waited               0ms        0ms        0ms       20ms\n  Direct full   conditional waited                 0          0          0          0\n  KSwapd number congest     waited              2106       2308       2116       1915\n  KSwapd time   congest     waited          139924ms   157832ms   125652ms   132516ms\n  KSwapd full   congest     waited              1346       1530       1202       1278\n  KSwapd number conditional waited             12922      16320      10943      14670\n  KSwapd time   conditional waited               0ms        0ms        0ms        0ms\n  KSwapd full   conditional waited                 0          0          0          0\n\nReclaim statistics are not radically changed.  The stall times in kswapd\nare massive but it is clear that it is due to calls to congestion_wait()\nand that is almost certainly the call in balance_pgdat().  Otherwise\nstalls due to dirty pages are non-existant.\n\nI ran a benchmark that stressed high-order allocation.  This is very\nartifical load but was used in the past to evaluate lumpy reclaim and\ncompaction.  Generally I look at allocation success rates and latency\nfigures.\n\n  STRESS-HIGHALLOC\n                   3.3.0-vanilla       rc2-vanilla  lumpyremove-v2r3       nosync-v2r3\n  Pass 1          81.00 ( 0.00%)    28.00 (-53.00%)    24.00 (-57.00%)    28.00 (-53.00%)\n  Pass 2          82.00 ( 0.00%)    39.00 (-43.00%)    38.00 (-44.00%)    43.00 (-39.00%)\n  while Rested    88.00 ( 0.00%)    87.00 (-1.00%)    88.00 ( 0.00%)    88.00 ( 0.00%)\n\n  MMTests Statistics: duration\n  Sys Time Running Test (seconds)             740.93    681.42    685.14    684.87\n  User+Sys Time Running Test (seconds)       2922.65   3269.52   3281.35   3279.44\n  Total Elapsed Time (seconds)               1161.73   1152.49   1159.55   1161.44\n\n  MMTests Statistics: vmstat\n  Page Ins                                     4486020     2807256     2855944     2876244\n  Page Outs                                    7261600     7973688     7975320     7986120\n  Swap Ins                                       31694           0           0           0\n  Swap Outs                                      98179           0           0           0\n  Direct pages scanned                           53494       57731       34406      113015\n  Kswapd pages scanned                         6271173     1287481     1278174     1219095\n  Kswapd pages reclaimed                       2029240     1281025     1260708     1201583\n  Direct pages reclaimed                          1468       14564       16649       92456\n  Kswapd efficiency                                32%         99%         98%         98%\n  Kswapd velocity                             5398.133    1117.130    1102.302    1049.641\n  Direct efficiency                                 2%         25%         48%         81%\n  Direct velocity                               46.047      50.092      29.672      97.306\n  Percentage direct scans                           0%          4%          2%          8%\n  Page writes by reclaim                       1616049           0           0           0\n  Page writes file                             1517870           0           0           0\n  Page writes anon                               98179           0           0           0\n  Page reclaim immediate                        103778       27339        9796       17831\n  Page rescued immediate                             0           0           0           0\n  Slabs scanned                                1096704      986112      980992      998400\n  Direct inode steals                              223      215040      216736      247881\n  Kswapd inode steals                           175331       61548       68444       63066\n  Kswapd skipped wait                            21991           0           1           0\n  THP fault alloc                                    1         135         125         134\n  THP collapse alloc                               393         311         228         236\n  THP splits                                        25          13           7           8\n  THP fault fallback                                 0           0           0           0\n  THP collapse fail                                  3           5           7           7\n  Compaction stalls                                865        1270        1422        1518\n  Compaction success                               370         401         353         383\n  Compaction failures                              495         869        1069        1135\n  Compaction pages moved                        870155     3828868     4036106     4423626\n  Compaction move failure                        26429       23865       29742       27514\n\nSuccess rates are completely hosed for 3.4-rc2 which is almost certainly\ndue to commit fe2c2a106663 (\"vmscan: reclaim at order 0 when compaction\nis enabled\").  I expected this would happen for kswapd and impair\nallocation success rates (https://lkml.org/lkml/2012/1/25/166) but I did\nnot anticipate this much a difference: 80% less scanning, 37% less\nreclaim by kswapd\n\nIn comparison, reclaim/compaction is not aggressive and gives up easily\nwhich is the intended behaviour.  hugetlbfs uses __GFP_REPEAT and would\nbe much more aggressive about reclaim/compaction than THP allocations\nare.  The stress test above is allocating like neither THP or hugetlbfs\nbut is much closer to THP.\n\nMainline is now impaired in terms of high order allocation under heavy\nload although I do not know to what degree as I did not test with\n__GFP_REPEAT.  Keep this in mind for bugs related to hugepage pool\nresizing, THP allocation and high order atomic allocation failures from\nnetwork devices.\n\nIn terms of congestion throttling, I see the following for this test\n\n  FTrace Reclaim Statistics: congestion_wait\n  Direct number congest     waited                 3          0          0          0\n  Direct time   congest     waited               0ms        0ms        0ms        0ms\n  Direct full   congest     waited                 0          0          0          0\n  Direct number conditional waited               957        512       1081       1075\n  Direct time   conditional waited               0ms        0ms        0ms        0ms\n  Direct full   conditional waited                 0          0          0          0\n  KSwapd number congest     waited                36          4          3          5\n  KSwapd time   congest     waited            3148ms      400ms      300ms      500ms\n  KSwapd full   congest     waited                30          4          3          5\n  KSwapd number conditional waited             88514        197        332        542\n  KSwapd time   conditional waited            4980ms        0ms        0ms        0ms\n  KSwapd full   conditional waited                49          0          0          0\n\nThe \"conditional waited\" times are the most interesting as this is\ndirectly impacted by the number of dirty pages encountered during scan.\nAs lumpy reclaim is no longer scanning contiguous ranges, it is finding\nfewer dirty pages.  This brings wait times from about 5 seconds to 0.\nkswapd itself is still calling congestion_wait() so it'll still stall but\nit's a lot less.\n\nIn terms of the type of IO we were doing, I see this\n\n  FTrace Reclaim Statistics: mm_vmscan_writepage\n  Direct writes anon  sync                         0          0          0          0\n  Direct writes anon  async                        0          0          0          0\n  Direct writes file  sync                         0          0          0          0\n  Direct writes file  async                        0          0          0          0\n  Direct writes mixed sync                         0          0          0          0\n  Direct writes mixed async                        0          0          0          0\n  KSwapd writes anon  sync                         0          0          0          0\n  KSwapd writes anon  async                    91682          0          0          0\n  KSwapd writes file  sync                         0          0          0          0\n  KSwapd writes file  async                   822629          0          0          0\n  KSwapd writes mixed sync                         0          0          0          0\n  KSwapd writes mixed async                        0          0          0          0\n\nIn 3.2, kswapd was doing a bunch of async writes of pages but\nreclaim/compaction was never reaching a point where it was doing sync\nIO.  This does not guarantee that reclaim/compaction was not calling\nwait_on_page_writeback() but I would consider it unlikely.  It indicates\nthat merging patches 2 and 3 to stop reclaim/compaction calling\nwait_on_page_writeback() should be safe.\n\nThis patch:\n\nLumpy reclaim had a purpose but in the mind of some, it was to kick the\nsystem so hard it trashed.  For others the purpose was to complicate\nvmscan.c.  Over time it was giving softer shoes and a nicer attitude but\nmemory compaction needs to step up and replace it so this patch sends\nlumpy reclaim to the farm.\n\nThe tracepoint format changes for isolating LRU pages with this patch\napplied.  Furthermore reclaim/compaction can no longer queue dirty pages\nin pageout() if the underlying BDI is congested.  Lumpy reclaim used\nthis logic and reclaim/compaction was using it in error.\n\nSigned-off-by: Mel Gorman <mgorman@suse.de>\nAcked-by: Rik van Riel <riel@redhat.com>\nAcked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>\nCc: Konstantin Khlebnikov <khlebnikov@openvz.org>\nCc: Hugh Dickins <hughd@google.com>\nCc: Ying Han <yinghan@google.com>\nCc: Andy Whitcroft <apw@shadowen.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/kabata1975/android_kernel_lge_hammerhead/commits/151636446e8d08342f4ceb719ba97e02dec8e1f6"},{"sha":"509f5e6727e6e43388f6ba10f099ee74727e891c","author":{"email":"39ea6a09710987173e32e37c86918024a0f441c1@suse.de","name":"Mel Gorman"},"message":"mm: vmscan: do not stall on writeback during memory compaction\n\nThis patch stops reclaim/compaction entering sync reclaim as this was\nonly intended for lumpy reclaim and an oversight.  Page migration has\nits own logic for stalling on writeback pages if necessary and memory\ncompaction is already using it.\n\nWaiting on page writeback is bad for a number of reasons but the primary\none is that waiting on writeback to a slow device like USB can take a\nconsiderable length of time.  Page reclaim instead uses\nwait_iff_congested() to throttle if too many dirty pages are being\nscanned.\n\nSigned-off-by: Mel Gorman <mgorman@suse.de>\nAcked-by: Rik van Riel <riel@redhat.com>\nAcked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>\nCc: Konstantin Khlebnikov <khlebnikov@openvz.org>\nCc: Hugh Dickins <hughd@google.com>\nCc: Ying Han <yinghan@google.com>\nCc: Andy Whitcroft <apw@shadowen.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/kabata1975/android_kernel_lge_hammerhead/commits/509f5e6727e6e43388f6ba10f099ee74727e891c"},{"sha":"2572d577e61ab7ce5abed9bf4b714a298c3decfe","author":{"email":"39ea6a09710987173e32e37c86918024a0f441c1@suse.de","name":"Mel Gorman"},"message":"mm: vmscan: remove reclaim_mode_t\n\nThere is little motiviation for reclaim_mode_t once RECLAIM_MODE_[A]SYNC\nand lumpy reclaim have been removed.  This patch gets rid of\nreclaim_mode_t as well and improves the documentation about what\nreclaim/compaction is and when it is triggered.\n\nSigned-off-by: Mel Gorman <mgorman@suse.de>\nAcked-by: Rik van Riel <riel@redhat.com>\nAcked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>\nCc: Konstantin Khlebnikov <khlebnikov@openvz.org>\nCc: Hugh Dickins <hughd@google.com>\nCc: Ying Han <yinghan@google.com>\nCc: Andy Whitcroft <apw@shadowen.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/kabata1975/android_kernel_lge_hammerhead/commits/2572d577e61ab7ce5abed9bf4b714a298c3decfe"},{"sha":"cada10368ba4aca34acb83557ceed9a01b440ade","author":{"email":"331be22c6b63ca3e0a03d408c2d906b1b02cd5f2@cmpxchg.org","name":"Johannes Weiner"},"message":"kernel: cgroup: push rcu read locking from css_is_ancestor() to callsite\n\nLibrary functions should not grab locks when the callsites can do it,\neven if the lock nests like the rcu read-side lock does.\n\nPush the rcu_read_lock() from css_is_ancestor() to its single user,\nmem_cgroup_same_or_subtree() in preparation for another user that may\nalready hold the rcu read-side lock.\n\nSigned-off-by: Johannes Weiner <hannes@cmpxchg.org>\nCc: Konstantin Khlebnikov <khlebnikov@openvz.org>\nAcked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>\nAcked-by: Michal Hocko <mhocko@suse.cz>\nAcked-by: Li Zefan <lizf@cn.fujitsu.com>\nCc: Li Zefan <lizf@cn.fujitsu.com>\nCc: Tejun Heo <tj@kernel.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/kabata1975/android_kernel_lge_hammerhead/commits/cada10368ba4aca34acb83557ceed9a01b440ade"}]}