{"push_id":643928933,"size":11,"distinct_size":11,"ref":"refs/heads/cm-12.1-msm8960dt-fork","head":"678f586d4df3b2ff7321e7414dbc0703ab3a8bc1","before":"09325d549e3c7302bb3dc339b1bb1be793768280","commits":[{"sha":"aa1843ecd95c533fa5bb479593cd661d7b4b451a","author":{"email":"0eff0dffba4abe152915d4d50cc3822cee56e1cb@telus.net","name":"CWGSM3VO"},"message":"msm: kgsl: Don't halt the GPU, try to recover first\n\nWe don't want to halt the GPU when trying to recover in\nproduction devices. Remove the bit mask that would do that.\n\nChange-Id: I0c1fcc70005fa8c5da2065dc2f09a9edf08dcd51\nSigned-off-by: Carter Cooper <ccooper@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/CWGSM3V0/android_kernel_motorola_msm8960dt-common/commits/aa1843ecd95c533fa5bb479593cd661d7b4b451a"},{"sha":"41dd71a1235ba98c76286b0014185d3bacb211b5","author":{"email":"0eff0dffba4abe152915d4d50cc3822cee56e1cb@telus.net","name":"CWGSM3VO"},"message":"msm: kgsl: Mark mmapped objects with VM_DONTCOPY\n\nAdd VM_DONTCOPY to the default set of mmap flags to keep VM objects\nfrom being copied on fork() and causing issues.  KGSL file descriptors\ncopied to a child are not expected to be usable.\n\nChange-Id: Ic0dedbad85c07118a931ccb9f7a6fd0507da3e5a\nSigned-off-by: Jordan Crouse <jcrouse@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/CWGSM3V0/android_kernel_motorola_msm8960dt-common/commits/41dd71a1235ba98c76286b0014185d3bacb211b5"},{"sha":"0636fb1ce33edf0a24f9c7153cbd9be69e02d036","author":{"email":"0eff0dffba4abe152915d4d50cc3822cee56e1cb@telus.net","name":"CWGSM3VO"},"message":"input: do not set sync flag for timestamp events\n\nsensor sends input events along with timestamp to userspace.\n\nIf timestamp is sent with sync flag true, input sub system\nnot sending the events to userspace if there is no chnage in\nsensor data which is resulting in missing events at userspace.\nThis is increasing the jitter between input events.\n\nTo avoid this, send time stamp with sync flag false to send the\nevents at regular intervals without any event drop.\n\nChange-Id: I701853d51b5ec015377281e103fa2f8d94ea936c\nSigned-off-by: Kiran Raparthy <krapar@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/CWGSM3V0/android_kernel_motorola_msm8960dt-common/commits/0636fb1ce33edf0a24f9c7153cbd9be69e02d036"},{"sha":"e5c8b6d7e10cbf9dcc7ec7c7ecfbd6c08e679b78","author":{"email":"0eff0dffba4abe152915d4d50cc3822cee56e1cb@telus.net","name":"CWGSM3VO"},"message":"iommu: msm: Handle unmapping of PTE properly\n\nThe unmap api is currently not handling unmapping of page table\nentries (PTE) properly. The generic function that calls the msm\nunmap API expects the unmap call to unmap as much as possible\nand then return the amount that was unmapped.\nIn addition the unmap function does not support an arbitrary input\nlength. However, the function that calls the msm unmap function\nassumes that this is supported.\n\nBoth these issues can cause mappings to not be unmapped which will\ncause subsequent mappings to fail because the mapping already exists.\n\nChange-Id: I638d5c38673abe297a701de9b7209c962564e1f1\nSigned-off-by: Olav Haugan <ohaugan@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/CWGSM3V0/android_kernel_motorola_msm8960dt-common/commits/e5c8b6d7e10cbf9dcc7ec7c7ecfbd6c08e679b78"},{"sha":"5d3e8ba04bd33250bf8453e7498a8bdba579bf0d","author":{"email":"0eff0dffba4abe152915d4d50cc3822cee56e1cb@telus.net","name":"CWGSM3VO"},"message":"lowmemorykiller: Account for highmem during kswapd reclaim\n\nCurrenlty most memory reclaim is done through kswapd.\nSince kswapd uses a gfp mask of GFP_KERNEL, and because\nthe lowmemorykiller is zone aware, the lowmemorykiller will\nignore highmem most of the time.\nThis results in the lowmemorykiller being overly aggressive.\n\nThe fix to this issue is to allow the lowmemorykiller to\ncount highmem when being called by the kswapd if the lowmem\nwatermarks are satisfied.\n\nChange-Id: I938644584f374763d10d429d835e74daa4854a38\nSigned-off-by: Liam Mark <lmark@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/CWGSM3V0/android_kernel_motorola_msm8960dt-common/commits/5d3e8ba04bd33250bf8453e7498a8bdba579bf0d"},{"sha":"c01ad0ebd4e5e4eb9c41e30341c9975f16b94a38","author":{"email":"0eff0dffba4abe152915d4d50cc3822cee56e1cb@telus.net","name":"CWGSM3VO"},"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>","distinct":true,"url":"https://api.github.com/repos/CWGSM3V0/android_kernel_motorola_msm8960dt-common/commits/c01ad0ebd4e5e4eb9c41e30341c9975f16b94a38"},{"sha":"a95c00713c2422bed89903848f009e544c5246ec","author":{"email":"65d484aa1efdaf0ae258f87a04ed8ec8685cba3e@samsung.com","name":"Namjae Jeon"},"message":"writeback: fix writeback cache thrashing\n\nConsider Process A: huge I/O on sda\n        doing heavy write operation - dirty memory becomes more\n        than dirty_background_ratio\n        on HDD - flusher thread flush-8:0\n\nConsider Process B: small I/O on sdb\n        doing while [1]; read 1024K + rewrite 1024K + sleep 2sec\n        on Flash device - flusher thread flush-8:16\n\nAs Process A is a heavy dirtier, dirty memory becomes more\nthan dirty_background_thresh. Due to this, below check becomes\ntrue(checking global_page_state in over_bground_thresh)\nfor all bdi devices(even for very small dirtied bdi - sdb):\n\nIn this case, even small cached data on 'sdb' is forced to flush\nand writeback cache thrashing happens.\n\nWhen we added debug prints inside above 'if' condition and ran\nabove Process A(heavy dirtier on bdi with flush-8:0) and\nProcess B(1024K frequent read/rewrite on bdi with flush-8:16)\nwe got below prints:\n\n[Test setup: ARM dual core CPU, 512 MB RAM]\n\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  56064 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  56704 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 84720 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 94720 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   384 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   960 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =    64 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92160 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   256 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   768 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =    64 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   256 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   320 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =     0 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92032 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 91968 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   192 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =  1024 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =    64 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   192 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   576 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =     0 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 84352 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   192 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   512 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =     0 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92608 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92544 KB\n\nAs mentioned in above log, when global dirty memory > global background_thresh\nsmall cached data is also forced to flush by flush-8:16.\nIf removing global background_thresh checking code, we can reduce cache\nthrashing of frequently used small data.\nAnd It will be great if we can reserve a portion of writeback cache using\nmin_ratio.\n\nAfter applying patch:\n$ echo 5 > /sys/block/sdb/bdi/min_ratio\n$ cat /sys/block/sdb/bdi/min_ratio\n5\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  56064 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  56704 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  84160 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  96960 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  94080 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  93120 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  93120 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  91520 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  89600 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  93696 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  93696 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  72960 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  90624 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  90624 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  90688 KB\n\nAs mentioned in the above logs, once cache is reserved for Process B,\nand patch is applied there is less writeback cache thrashing on sdb\nby frequent forced writeback by flush-8:16 in over_bground_thresh.\n\nAfter all, small cached data will be flushed by periodic writeback\nonce every dirty_writeback_interval.\n\nChange-Id: I678b30a5a28ed99bed0e782e38926ba4626b86ee\nSuggested-by: Wanpeng Li <liwanp@linux.vnet.ibm.com>\nSigned-off-by: Namjae Jeon <namjae.jeon@samsung.com>\nSigned-off-by: Vivek Trivedi <t.vivek@samsung.com>","distinct":true,"url":"https://api.github.com/repos/CWGSM3V0/android_kernel_motorola_msm8960dt-common/commits/a95c00713c2422bed89903848f009e544c5246ec"},{"sha":"aeff7922be5b2fae2c62816a8795948c160b7ac9","author":{"email":"0eff0dffba4abe152915d4d50cc3822cee56e1cb@telus.net","name":"CWGSM3VO"},"message":"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\nChange-Id: I458027ae08d9a5a93202a7b97ace1f8da7a18a07\nCC: stable@vger.kernel.org\nReported-by: Paul Taysom <taysom@chromium.org>\nSigned-off-by: Jan Kara <jack@suse.cz>","distinct":true,"url":"https://api.github.com/repos/CWGSM3V0/android_kernel_motorola_msm8960dt-common/commits/aeff7922be5b2fae2c62816a8795948c160b7ac9"},{"sha":"2bd9d5f76ad2abb07e673f99fcd5ce8a04c989d2","author":{"email":"0eff0dffba4abe152915d4d50cc3822cee56e1cb@telus.net","name":"CWGSM3VO"},"message":"writeback: fix race that cause writeback hung\n\nThere is a race between mark inode dirty and writeback thread, see the\nfollowing scenario.  In this case, writeback thread will not run though\nthere is dirty_io.\n\n__mark_inode_dirty()\n        bdi_writeback_workfn()\n\t...\n        ...\n\tspin_lock(&inode->i_lock);\n\t...\n\tif (bdi_cap_writeback_dirty(bdi)) {\n\t<<< assume wb has dirty_io, so wakeup_bdi is false.\n\t<<< the following inode_dirty also have wakeup_bdi false.\n\t    if (!wb_has_dirty_io(&bdi->wb))\n\t\t    wakeup_bdi = true;\n\t}\n\tspin_unlock(&inode->i_lock);\n        <<< assume last dirty_io is removed here.\n        pages_written = wb_do_writeback(wb);\n        ...\n        <<< work_list empty and wb has no dirty_io,\n        <<< delayed_work will not be queued.\n        if (!list_empty(&bdi->work_list) ||\n            (wb_has_dirty_io(wb) && dirty_writeback_interval))\n            queue_delayed_work(bdi_wq, &wb->dwork,\n            msecs_to_jiffies(dirty_writeback_interval * 10));\n\tspin_lock(&bdi->wb.list_lock);\n\tinode->dirtied_when = jiffies;\n\t<<< new dirty_io is added.\n\tlist_move(&inode->i_wb_list, &bdi->wb.b_dirty);\n\tspin_unlock(&bdi->wb.list_lock);\n\t<<< though there is dirty_io, but wakeup_bdi is false,\n\t<<< so writeback thread will not be waked up and\n\t<<< the new dirty_io will not be flushed.\n\tif (wakeup_bdi)\n\t    bdi_wakeup_thread_delayed(bdi);\n\nWriteback will run until there is a new flush work queued.  This may cause\na lot of dirty pages stay in memory for a long time.\n\nSigned-off-by: Junxiao Bi <junxiao.bi@oracle.com>\nReviewed-by: Jan Kara <jack@suse.cz>\nCc: Fengguang Wu <fengguang.wu@intel.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Francisco Franco <franciscofranco.1990@gmail.com>\n\nChange-Id: I973fcba5381881a003a035ffff48f64348660079","distinct":true,"url":"https://api.github.com/repos/CWGSM3V0/android_kernel_motorola_msm8960dt-common/commits/2bd9d5f76ad2abb07e673f99fcd5ce8a04c989d2"},{"sha":"19650145c0e4fb646e89a7091ca3cdbef835c79e","author":{"email":"0eff0dffba4abe152915d4d50cc3822cee56e1cb@telus.net","name":"CWGSM3VO"},"message":"ext4: speed up truncate/unlink by not using bforget() unless needed\n\nDo not iterate over data blocks scanning for bh's to forget as they're\nnever exist. This improves time taken by unlink / truncate syscall.\nTested by continuously truncating file that is being written by dd.\nAnother test is rm -rf of linux tree while tar unpacks it. With\nordered data mode condition unlikely(!tbh) was always met in\next4_free_blocks. With journal data mode tbh was found only few times,\nso optimisation is also possible.\n\nUnlinking fallocated 60G file after doing sync && echo 3 >\n/proc/sys/vm/drop_caches && time rm --help\n\nX86 before (linux 3.6-rc4):\nreal    0m2.710s\nuser    0m0.000s\nsys     0m1.530s\n\nX86 after:\nreal    0m0.644s\nuser    0m0.003s\nsys     0m0.060s\n\nMIPS before (linux 2.6.37):\nreal    0m 4.93s\nuser    0m 0.00s\nsys     0m 4.61s\n\nMIPS after:\nreal    0m 0.16s\nuser    0m 0.00s\nsys     0m 0.06s\n\nSigned-off-by: \"Theodore Ts'o\" <tytso@mit.edu>\nSigned-off-by: Andrey Sidorov <qrxd43@motorola.com>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>\n\nChange-Id: Ie78a945cb82b3892eaf88701f2dc3b7726104fb5","distinct":true,"url":"https://api.github.com/repos/CWGSM3V0/android_kernel_motorola_msm8960dt-common/commits/19650145c0e4fb646e89a7091ca3cdbef835c79e"},{"sha":"678f586d4df3b2ff7321e7414dbc0703ab3a8bc1","author":{"email":"0eff0dffba4abe152915d4d50cc3822cee56e1cb@telus.net","name":"CWGSM3VO"},"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","distinct":true,"url":"https://api.github.com/repos/CWGSM3V0/android_kernel_motorola_msm8960dt-common/commits/678f586d4df3b2ff7321e7414dbc0703ab3a8bc1"}]}