{"push_id":1436581917,"size":60,"distinct_size":60,"ref":"refs/heads/UD_kernel","head":"396092a85e8afdb887d9f71a180cf93c1146841b","before":"14f5917acfc86bf0d2b51de2989e4a48a339890e","commits":[{"sha":"e8b3fda617f1eab725723b3170d21c57ebd8929e","author":{"name":"Paul Moore","email":"54f65660711c038b3360dd7288dc12347ae58ba3@paul-moore.com"},"message":"BACKPORT: audit: consistently record PIDs with task_tgid_nr()\n\nUnfortunately we record PIDs in audit records using a variety of\nmethods despite the correct way being the use of task_tgid_nr().\nThis patch converts all of these callers, except for the case of\nAUDIT_SET in audit_receive_msg() (see the comment in the code).\n\nReported-by: Jeff Vander Stoep <jeffv@google.com>\nSigned-off-by: Paul Moore <paul@paul-moore.com>\n\nBug: 28952093\n\n(cherry picked from commit fa2bea2f5cca5b8d4a3e5520d2e8c0ede67ac108)\nSigned-off-by: Jeff Vander Stoep <jeffv@google.com>\nChange-Id: I36508a25c957f5108299e68a3b0f627c94eb27eb","distinct":true,"url":"https://api.github.com/repos/Ahmed-Hady/android_kernel_motorola_msm8916/commits/e8b3fda617f1eab725723b3170d21c57ebd8929e"},{"sha":"0036296ca9ad9319a0a54a2459bd6643981009b3","author":{"name":"EunTaik Lee","email":"d2233ab27ded9ee023d5c949fa5e901e18090c48@samsung.com"},"message":"UPSTREAM: staging/android/ion : fix a race condition in the ion driver\n\nThere is a use-after-free problem in the ion driver.\nThis is caused by a race condition in the ion_ioctl()\nfunction.\n\nA handle has ref count of 1 and two tasks on different\ncpus calls ION_IOC_FREE simultaneously.\n\ncpu 0                                   cpu 1\n-------------------------------------------------------\nion_handle_get_by_id()\n(ref == 2)\n                            ion_handle_get_by_id()\n                            (ref == 3)\n\nion_free()\n(ref == 2)\n\nion_handle_put()\n(ref == 1)\n\n                            ion_free()\n                            (ref == 0 so ion_handle_destroy() is\n                            called\n                            and the handle is freed.)\n\n                            ion_handle_put() is called and it\n                            decreases the slub's next free pointer\n\nThe problem is detected as an unaligned access in the\nspin lock functions since it uses load exclusive\n instruction. In some cases it corrupts the slub's\nfree pointer which causes a mis-aligned access to the\nnext free pointer.(kmalloc returns a pointer like\nffffc0745b4580aa). And it causes lots of other\nhard-to-debug problems.\n\nThis symptom is caused since the first member in the\nion_handle structure is the reference count and the\nion driver decrements the reference after it has been\nfreed.\n\nTo fix this problem client->lock mutex is extended\nto protect all the codes that uses the handle.\n\nSigned-off-by: Eun Taik Lee <eun.taik.lee@samsung.com>\nReviewed-by: Laura Abbott <labbott@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\n(cherry picked from commit 9590232bb4f4cc824f3425a6e1349afbe6d6d2b7)\nbug: 31568617\nChange-Id: I4ea2be0cad3305c4e196126a02e2ab7108ef0976","distinct":true,"url":"https://api.github.com/repos/Ahmed-Hady/android_kernel_motorola_msm8916/commits/0036296ca9ad9319a0a54a2459bd6643981009b3"},{"sha":"402195cb959cf03c6e01cfd720ee9ce35844ad69","author":{"name":"Kirill A. Shutemov","email":"e4d0c2966af3c70025b28e24a0f33104c6291010@linux.intel.com"},"message":"BACKPORT: mm: avoid setting up anonymous pages into file mapping\n\n(cherry picked from commit 6b7339f4c31ad69c8e9c0b2859276e22cf72176d)\n\nReading page fault handler code I've noticed that under right\ncircumstances kernel would map anonymous pages into file mappings: if\nthe VMA doesn't have vm_ops->fault() and the VMA wasn't fully populated\non ->mmap(), kernel would handle page fault to not populated pte with\ndo_anonymous_page().\n\nLet's change page fault handler to use do_anonymous_page() only on\nanonymous VMA (->vm_ops == NULL) and make sure that the VMA is not\nshared.\n\nFor file mappings without vm_ops->fault() or shred VMA without vm_ops,\npage fault on pte_none() entry would lead to SIGBUS.\n\nSigned-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>\nAcked-by: Oleg Nesterov <oleg@redhat.com>\nCc: Andrew Morton <akpm@linux-foundation.org>\nCc: Willy Tarreau <w@1wt.eu>\nCc: stable@vger.kernel.org\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nChange-Id: I451f90075ddf0c3592543e4fe30eed4c38348d49\nBug: 32460277","distinct":true,"url":"https://api.github.com/repos/Ahmed-Hady/android_kernel_motorola_msm8916/commits/402195cb959cf03c6e01cfd720ee9ce35844ad69"},{"sha":"648c5058628fc8823e64fe847849f78b4ae2797f","author":{"name":"Ahmed Hady","email":"df4d11f8051f3f0a721af25e691b4b79e7a5e3d6@gmail.com"},"message":"drivers: lmk: enable adaptive lmk by default\n by @CarlosArriagaCM","distinct":true,"url":"https://api.github.com/repos/Ahmed-Hady/android_kernel_motorola_msm8916/commits/648c5058628fc8823e64fe847849f78b4ae2797f"},{"sha":"85b86c12b28018c5d2d823fd4ff4f682c235a6cb","author":{"name":"Ahmed Hady","email":"df4d11f8051f3f0a721af25e691b4b79e7a5e3d6@gmail.com"},"message":"update Makefile & osprey_defconfig","distinct":true,"url":"https://api.github.com/repos/Ahmed-Hady/android_kernel_motorola_msm8916/commits/85b86c12b28018c5d2d823fd4ff4f682c235a6cb"},{"sha":"3343c18fc059e91129ecb4a833f7f1006d721b19","author":{"name":"Ahmed Hady","email":"df4d11f8051f3f0a721af25e691b4b79e7a5e3d6@gmail.com"},"message":"Clean files","distinct":true,"url":"https://api.github.com/repos/Ahmed-Hady/android_kernel_motorola_msm8916/commits/3343c18fc059e91129ecb4a833f7f1006d721b19"},{"sha":"b9fa100f79bb801211550c71b0437e35c7a8a569","author":{"name":"Talel Shenhar","email":"6f87d6a35f71247c15741dfc953993d1966dbb6e@codeaurora.org"},"message":"mmc: clk_scaling: add sysfs for avoiding scale down in write\n\nChange Ia7a578434d7db8983493788ab2d7f9383d703169 introduced\na degradation in performance.\nThat change tried to fix a problem for clock scaling\nduring write requests.\nDuring write request the invalid_state is always set due to\nCMD13 that is sent after each write.\nIn the attempt to fix that issue the change above added the\nability to scale down although invalid_state was set.\nThus, creating a favor for downscale over upscale.\nSome customers prefer performance over power.\nThis change introduces a sysfs entry that will allow the\ndriver to retain its old behavior which had better performance.\n\nIt can be controlled from new sysfs entry:\n\"scale_down_in_low_wr_load\" found under\n/sys/class/mmc_host/mmcX/clk_scaling/\nThe default value for it is \"0\". In case customers\nwant to gain performance over power they should set\nit to \"1\".\n\nChange-Id: I8fb1f430b6287526567521382486c2b11952aa73\nSigned-off-by: Talel Shenhar <tatias@codeaurora.org>\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Ahmed-Hady/android_kernel_motorola_msm8916/commits/b9fa100f79bb801211550c71b0437e35c7a8a569"},{"sha":"41645da0961496ab1a1d954f8b9a8d4202ef24ea","author":{"name":"flar2","email":"54baee86d9719f38bf07b54ac189c5126488f211@gmail.com"},"message":"mmc: clk_scaling: set scale_down_in_low_wr_load to 1 by default\n\nAs per Qualcomm:\nThe default value for it is \"0\". In case customers\nwant to gain performance over power they should set\nit to \"1\"\n\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Ahmed-Hady/android_kernel_motorola_msm8916/commits/41645da0961496ab1a1d954f8b9a8d4202ef24ea"},{"sha":"b68766c4aca7e1c0e83f8ce9c76a21ef7ced756d","author":{"name":"Ahmed Hady","email":"df4d11f8051f3f0a721af25e691b4b79e7a5e3d6@gmail.com"},"message":"Adding some CPU GOVS","distinct":true,"url":"https://api.github.com/repos/Ahmed-Hady/android_kernel_motorola_msm8916/commits/b68766c4aca7e1c0e83f8ce9c76a21ef7ced756d"},{"sha":"0ebbf4869c878f6c6ddfb6f9e14a0d5f5787083d","author":{"name":"desaishivam26","email":"4b98e33824e0884f9ac5e6d5d98c31f7a18e1b55@gmail.com"},"message":"block: add SIO scheduler","distinct":true,"url":"https://api.github.com/repos/Ahmed-Hady/android_kernel_motorola_msm8916/commits/0ebbf4869c878f6c6ddfb6f9e14a0d5f5787083d"},{"sha":"9410a73f383cc42c96692020f6fdfdb22e8c3acb","author":{"name":"franciscofranco","email":"0ac3193ff3d7b4e68ae404d59f776924e2be9ac9@gmail.com"},"message":"Added fsync on/off support.\n\nSigned-off-by: Francisco Franco <franciscofranco.1990@gmail.com>\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Ahmed-Hady/android_kernel_motorola_msm8916/commits/9410a73f383cc42c96692020f6fdfdb22e8c3acb"},{"sha":"32cfa962332faca007099c9b53aec166cd2f8bf2","author":{"name":"flar2","email":"54baee86d9719f38bf07b54ac189c5126488f211@gmail.com"},"message":"msm_performance: Make input boosting optional","distinct":true,"url":"https://api.github.com/repos/Ahmed-Hady/android_kernel_motorola_msm8916/commits/32cfa962332faca007099c9b53aec166cd2f8bf2"},{"sha":"97975411087a3e9d8e0a6c08b63d1cff2f91bf62","author":{"name":"myfluxi","email":"95ab61bb01957fc548ef82d227666a28af3268a6@arcor.de"},"message":"PM: devfreq: Use high priority workqueue\n\nIt does not make sense to run kgsl on high and devfreq on regular\npriority.\n\nChange-Id: Ie5e6c9353a4e1324a6a49278e5ad3638462f551c","distinct":true,"url":"https://api.github.com/repos/Ahmed-Hady/android_kernel_motorola_msm8916/commits/97975411087a3e9d8e0a6c08b63d1cff2f91bf62"},{"sha":"fe004d34e289e444d5d5b2f8a790d734baae951a","author":{"name":"Nikhilesh Reddy","email":"1e32cc90766364d327453cc38b968b137a000d78@codeaurora.org"},"message":"fs: Workaround the compiler's bad optimization\n\nWhen compiling the kernel with  the compiler\n\"aarch64-linux-android-gcc (GCC) 4.9.x-google 20140827 (prerelease)\"\nThe compiler seems to be optimizing a value out in the do_sync_write\nfunction and is incorrectly passing the pointer instead of the\ndereferenced value.\nForce the compiler to use the right value by passing the dereferenced\npointer instead of another variable that is assigned with the dereferenced\nvalue.\n\nChange-Id: I60505ffe39393f6323dcc7c6f912c74ea6aca6cd\nSigned-off-by: Nikhilesh Reddy <reddyn@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/Ahmed-Hady/android_kernel_motorola_msm8916/commits/fe004d34e289e444d5d5b2f8a790d734baae951a"},{"sha":"e65c00d84fcbcbe624be1f4eb37a33c781785c2f","author":{"name":"Peter Zijlstra","email":"4d3106856cce90e8f40acc5180f60ddda3a23b6e@infradead.org"},"message":"sched/idle: Avoid spurious wakeup IPIs\n\nBecause mwait_idle_with_hints() gets called from !idle context it must\ncall current_clr_polling(). This however means that resched_task() is\nvery likely to send an IPI even when we were polling:\n\n  CPU0\t\t\t\t\tCPU1\n\n  if (current_set_polling_and_test())\n    goto out;\n\n  __monitor(&ti->flags);\n  if (!need_resched())\n    __mwait(eax, ecx);\n\t\t\t\t\tset_tsk_need_resched(p);\n\t\t\t\t\tsmp_mb();\nout:\n  current_clr_polling();\n\t\t\t\t\tif (!tsk_is_polling(p))\n\t\t\t\t\t  smp_send_reschedule(cpu);\n\nSo while it is correct (extra IPIs aren't a problem, whereas a missed\nIPI would be) it is a performance problem (for some).\n\nAvoid this issue by using fetch_or() to atomically set NEED_RESCHED\nand test if POLLING_NRFLAG is set.\n\nSince a CPU stuck in mwait is unlikely to modify the flags word,\ncontention on the cmpxchg is unlikely and thus we should mostly\nsucceed in a single go.\n\nSigned-off-by: Peter Zijlstra <peterz@infradead.org>\nAcked-by: Nicolas Pitre <nico@linaro.org>\nCc: Andy Lutomirski <luto@amacapital.net>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nLink: http://lkml.kernel.org/n/tip-kf5suce6njh5xf5d3od13rr0@git.kernel.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/Ahmed-Hady/android_kernel_motorola_msm8916/commits/e65c00d84fcbcbe624be1f4eb37a33c781785c2f"},{"sha":"c699c5056a01e6f98a00e7b7a8eff79919fd41df","author":{"name":"Lai Jiangshan","email":"cf0e2d50a324441096e6c5342ad65c64cc64efaa@cn.fujitsu.com"},"message":"kthread_work: wake up worker only when the worker is idle\n\nIf the worker is already executing a work item when another is queued,\nwe can safely skip wakeup without worrying about stalling queue thus\navoiding waking up the busy worker spuriously.  Spurious wakeups\nshould be fine but still isn't nice and avoiding it is trivial here.\n\ntj: Updated description.\n\nSigned-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>\nSigned-off-by: Tejun Heo <tj@kernel.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Ahmed-Hady/android_kernel_motorola_msm8916/commits/c699c5056a01e6f98a00e7b7a8eff79919fd41df"},{"sha":"7c3155a84c0835754442dcb2b7093672403e4954","author":{"name":"Mel Gorman","email":"7e4a4144b35252848d9a801e3e6fca62e0cbe9e6@suse.de"},"message":"mm: slub: Default slub_max_order to 0\n\nTo avoid locking and per-cpu overhead, SLUB optimisically uses\nhigh-order allocations up to order-3 by default and falls back to\nlower allocations if they fail. While care is taken that the caller\nand kswapd take no unusual steps in response to this, there are\nfurther consequences like shrinkers who have to free more objects to\nrelease any memory. There is anecdotal evidence that significant time\nis being spent looping in shrinkers with insufficient progress being\nmade (https://lkml.org/lkml/2011/4/28/361) and keeping kswapd awake.\n\nSLUB is now the default allocator and some bug reports have been\npinned down to SLUB using high orders during operations like\ncopying large amounts of data. SLUBs use of high-orders benefits\napplications that are sized to memory appropriately but this does not\nnecessarily apply to large file servers or desktops.  This patch\ncauses SLUB to use order-0 pages like SLAB does by default.\nThere is further evidence that this keeps kswapd's usage lower\n(https://lkml.org/lkml/2011/5/10/383).\n\nSigned-off-by: Mel Gorman <mgorman@suse.de>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Ahmed-Hady/android_kernel_motorola_msm8916/commits/7c3155a84c0835754442dcb2b7093672403e4954"},{"sha":"75808b6571275d1265962119c73859d301ba0da3","author":{"name":"Linus Torvalds","email":"ead7104581934751970e9decb2db5deb20a9e407@linux-foundation.org"},"message":"mm: get rid of 'vmalloc_info' from /proc/meminfo\n\nIt turns out that at least some versions of glibc end up reading\n/proc/meminfo at every single startup, because glibc wants to know the\namount of memory the machine has.  And while that's arguably insane,\nit's just how things are.\n\nAnd it turns out that it's not all that expensive most of the time, but\nthe vmalloc information statistics (amount of virtual memory used in the\nvmalloc space, and the biggest remaining chunk) can be rather expensive\nto compute.\n\nThe 'get_vmalloc_info()' function actually showed up on my profiles as\n4% of the CPU usage of \"make test\" in the git source repository, because\nthe git tests are lots of very short-lived shell-scripts etc.\n\nIt turns out that apparently this same silly vmalloc info gathering\nshows up on the facebook servers too, according to Dave Jones.  So it's\nnot just \"make test\" for git.\n\nWe had two patches to just cache the information (one by me, one by\nIngo) to mitigate this issue, but the whole vmalloc information of of\nrather dubious value to begin with, and people who *actually* want to\nknow what the situation is wrt the vmalloc area should just look at the\nmuch more complete /proc/vmallocinfo instead.\n\nIn fact, according to my testing - and perhaps more importantly,\naccording to that big search engine in the sky: Google - there is\nnothing out there that actually cares about those two expensive fields:\nVmallocUsed and VmallocChunk.\n\nSo let's try to just remove them entirely.  Actually, this just removes\nthe computation and reports the numbers as zero for now, just to try to\nbe minimally intrusive.\n\nIf this breaks anything, we'll obviously have to re-introduce the code\nto compute this all and add the caching patches on top.  But if given\nthe option, I'd really prefer to just remove this bad idea entirely\nrather than add even more code to work around our historical mistake\nthat likely nobody really cares about.\n\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n\nConflicts:\n\n\tfs/proc/meminfo.c\n\tinclude/linux/vmalloc.h\n\tmm/vmalloc.c\n\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Ahmed-Hady/android_kernel_motorola_msm8916/commits/75808b6571275d1265962119c73859d301ba0da3"},{"sha":"fc89647265f3290f8b56d311bb1fca95c1891024","author":{"name":"Linus Torvalds","email":"ead7104581934751970e9decb2db5deb20a9e407@linux-foundation.org"},"message":"vfs: Fix pathological performance case for __alloc_fd()\n\nAl Viro points out that:\n> >     * [Linux-specific aside] our __alloc_fd() can degrade quite badly\n> > with some use patterns.  The cacheline pingpong in the bitmap is probably\n> > inevitable, unless we accept considerably heavier memory footprint,\n> > but we also have a case when alloc_fd() takes O(n) and it's _not_ hard\n> > to trigger - close(3);open(...); will have the next open() after that\n> > scanning the entire in-use bitmap.\n\nAnd Eric Dumazet has a somewhat realistic multithreaded microbenchmark\nthat opens and closes a lot of sockets with minimal work per socket.\n\nThis patch largely fixes it.  We keep a 2nd-level bitmap of the open\nfile bitmaps, showing which words are already full.  So then we can\ntraverse that second-level bitmap to efficiently skip already allocated\nfile descriptors.\n\nOn his benchmark, this improves performance by up to an order of\nmagnitude, by avoiding the excessive open file bitmap scanning.\n\nTested-and-acked-by: Eric Dumazet <edumazet@google.com>\nCc: Al Viro <viro@zeniv.linux.org.uk>\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/Ahmed-Hady/android_kernel_motorola_msm8916/commits/fc89647265f3290f8b56d311bb1fca95c1891024"},{"sha":"e678cb6f79e39ba36f39f29204190ed8edca7d00","author":{"name":"Linus Torvalds","email":"ead7104581934751970e9decb2db5deb20a9e407@linux-foundation.org"},"message":"vfs: conditionally clear close-on-exec flag\n\nWe clear the close-on-exec flag when opening and closing files, and the\nbit was almost always already clear before.  Avoid dirtying the\ncacheline if the clearning isn't necessary.  That avoids unnecessary\ncacheline dirtying and bouncing in multi-socket environments.\n\nEric Dumazet has a file descriptor benchmark that goes 4% faster from\nthis on his two-socket machine.  It's probably partly superlinear\nimprovement due to getting slightly less spinlock contention on the\nfile_lock spinlock due to less work in the critical section.\n\nTested-by: Eric Dumazet <eric.dumazet@gmail.com>\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/Ahmed-Hady/android_kernel_motorola_msm8916/commits/e678cb6f79e39ba36f39f29204190ed8edca7d00"}]}
{"actor":{"display_login":"Ahmed-Hady"}}