{"push_id":1228504948,"size":23,"distinct_size":23,"ref":"refs/heads/upstream-mm","head":"62709151bd541e00b7197f71d48d1d0c58721545","before":"5efe40660a8821296d6d39d64209431a6963bd80","commits":[{"sha":"d6db33e1c6f5a624a9eba0dc13caaf5464272af0","author":{"name":"Will Drewry","email":"201f27a2239e31941e54ec7e924e90590437b393@chromium.org"},"message":"sk_run_filter: add BPF_S_ANC_SECCOMP_LD_W\n\nIntroduces a new BPF ancillary instruction that all LD calls will be\nmapped through when skb_run_filter() is being used for seccomp BPF.  The\nrewriting will be done using a secondary chk_filter function that is run\nafter skb_chk_filter.\n\nThe code change is guarded by CONFIG_SECCOMP_FILTER which is added,\nalong with the seccomp_bpf_load() function later in this series.\n\nThis is based on http://lkml.org/lkml/2012/3/2/141\n\nSuggested-by: Indan Zupancic <indan@nul.nu>\nSigned-off-by: Will Drewry <wad@chromium.org>\nAcked-by: Eric Dumazet <eric.dumazet@gmail.com>\nAcked-by: Eric Paris <eparis@redhat.com>\n\nv18: rebase\n...\nv15: include seccomp.h explicitly for when seccomp_bpf_load exists.\nv14: First cut using a single additional instruction\n... v13: made bpf functions generic.","distinct":true,"url":"https://api.github.com/repos/Epirex/Samsung_STE_Kernel/commits/d6db33e1c6f5a624a9eba0dc13caaf5464272af0"},{"sha":"bf594365c830260974464597879fa1ccaf938b37","author":{"name":"Will Drewry","email":"201f27a2239e31941e54ec7e924e90590437b393@chromium.org"},"message":"net/compat.c,linux/filter.h: share compat_sock_fprog\n\nAny other users of bpf_*_filter that take a struct sock_fprog from\nuserspace will need to be able to also accept a compat_sock_fprog\nif the arch supports compat calls.  This change allows the existing\ncompat_sock_fprog be shared.\n\nSigned-off-by: Will Drewry <wad@chromium.org>\nAcked-by: Serge Hallyn <serge.hallyn@canonical.com>\nAcked-by: Eric Dumazet <eric.dumazet@gmail.com>\nAcked-by: Eric Paris <eparis@redhat.com>\n\nv18: tasered by the apostrophe police\nv14: rebase/nochanges\nv13: rebase on to 88ebdda6159ffc15699f204c33feb3e431bf9bdc\nv12: rebase on to linux-next\nv11: introduction","distinct":true,"url":"https://api.github.com/repos/Epirex/Samsung_STE_Kernel/commits/bf594365c830260974464597879fa1ccaf938b37"},{"sha":"69b7596320cc4002cdec7d1c992d5a173dcda96e","author":{"name":"Epirex","email":"825b26852de8e99e55e51b75e98302669f3665d1@gmail.com"},"message":"Revert \"net/compat.c,linux/filter.h: share compat_sock_fprog\"\n\nThis reverts commit bf594365c830260974464597879fa1ccaf938b37.","distinct":true,"url":"https://api.github.com/repos/Epirex/Samsung_STE_Kernel/commits/69b7596320cc4002cdec7d1c992d5a173dcda96e"},{"sha":"6b8c17717006369f2aa5c2880213368db31d5465","author":{"name":"Epirex","email":"825b26852de8e99e55e51b75e98302669f3665d1@gmail.com"},"message":"Revert \"sk_run_filter: add BPF_S_ANC_SECCOMP_LD_W\"\n\nThis reverts commit d6db33e1c6f5a624a9eba0dc13caaf5464272af0.","distinct":true,"url":"https://api.github.com/repos/Epirex/Samsung_STE_Kernel/commits/6b8c17717006369f2aa5c2880213368db31d5465"},{"sha":"9e153dcbde85c797bbad88f1264dbb47dd90e6fe","author":{"name":"Ruchi Kandoi","email":"1d1bb2ca737b8740d7a99166510e781fa0bc7c0b@google.com"},"message":"nf: Remove compilation error caused by e254d2c28c880da28626af6d53b7add5f7d6afee\n\nSigned-off-by: Ruchi Kandoi <kandoiruchi@google.com>","distinct":true,"url":"https://api.github.com/repos/Epirex/Samsung_STE_Kernel/commits/9e153dcbde85c797bbad88f1264dbb47dd90e6fe"},{"sha":"2f33bd74d886ad42b1593950dbd8c3b259d580de","author":{"name":"Srivatsa Vaddagiri","email":"4ebad9f61da157750c36beb638e9bb3384814e5d@codeaurora.org"},"message":"cpufreq: Retain only online cpus in managed_policy->cpus\n\ncpufreq's handling of cpu online event can incorrectly initialize\nmanaged_policy->cpus to include offline cpus. This causes cpufreq\ngovernors to include offline cpus in their idle time computation, which\ncauses frequency to shoot up beyond normal levels (on systems where 2 or\nmore cpus need to be synchronized wrt frequency change).\n\nThis frequency shootup was not seen prior to commit 21111be8 which\nchanged idle time accounting for offline cpus. Prior to commit 21111be8,\nidle time statistics for offline cpus would include their offline time\nas well. Post commit 21111be8, offline time is not included in a cpu's\nidle time statistics.\n\nAs a result, ondemand (or other cpufreq) governors would see unchanged\nidle time for offline cpus, causing them to interpret those (offline)\ncpus as 100% busy, which is wrong.\n\nThis patch fixes the issue by modifying cpufreq's hotplug handling to\nretain only online cpus in managed_policy->cpus field. cpufreq governors\nwould then skip such offline cpus from idle time calculations.\n\nChange-Id: Id2eba8c0ec3367609369b2e42a4e1386ff2e7ab5\nSigned-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/Epirex/Samsung_STE_Kernel/commits/2f33bd74d886ad42b1593950dbd8c3b259d580de"},{"sha":"3e361909eaa39476ebe65a59cfd36172ad99d19e","author":{"name":"Deepak Katragadda","email":"f0fb60e2ab9438f8145fbad79cc32d4b759f0d0c@codeaurora.org"},"message":"msm: cpufreq: Only apply driver limits for scaling_min/max_freq writes\n\nWhen new values are written to scaling_min/max_freq sysfs files, the\ncurrent code applies all the limits imposed by various ADJUST and\nINCOMPATIBLE notifiers handlers before storing them.\n\nWhen the ADJUST and/or INCOMPATIBLE notifiers change their limits\nfrequently, this behavior makes it almost impossible for a\nuser/userspace process to store the scaling_min/max_freq limits\nthat go beyond the instantaneous limits imposed by the notifiers.\nSince these sysfs nodes are typically meant to set limits that need\nto be enforced for the foreseeable future, this is not a very user\nfriendly behavior.\n\nSo, change the behavior to only apply limits that are enforced by\nthe cpufreq driver. Typically, these are just the absolute limits\nof the HW and don't change very often.\n\nChange-Id: I1ccfaa2d1ee4ea595f882485d359dbdb407a0176\nSigned-off-by: Deepak Katragadda <dkatraga@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/Epirex/Samsung_STE_Kernel/commits/3e361909eaa39476ebe65a59cfd36172ad99d19e"},{"sha":"99c60a05bbb4a43b113284ae77cd57f34bfea300","author":{"name":"Ruchi Kandoi","email":"1d1bb2ca737b8740d7a99166510e781fa0bc7c0b@google.com"},"message":"suspend: Return error when pending wakeup source is found.\n\nIf a wakeup source is found to be pending in the last stage of suspend\nafter syscore suspend then the device doesn't suspend but the error is\nnot propogated which causes an error in the accounting for the number\nof suspend aborts and successful suspends.\n\nChange-Id: Ib63b4ead755127eaf03e3b303aab3c782ad02ed1\nSigned-off-by: Ruchi Kandoi <kandoiruchi@google.com>","distinct":true,"url":"https://api.github.com/repos/Epirex/Samsung_STE_Kernel/commits/99c60a05bbb4a43b113284ae77cd57f34bfea300"},{"sha":"32cf4ca1be75bdd50dd5ef55bc852551a0572180","author":{"name":"Laura Abbott","email":"8553df7474583031a579ce7388bd843e3b158549@codeaurora.org"},"message":"mm: Add notifier framework for showing memory\n\nThere are many drivers in the kernel which can hold on\nto lots of memory. It can be useful to dump out all those\ndrivers at key points in the kernel. Introduct a notifier\nframework for dumping this information. When the notifiers\nare called, drivers can dump out the state of any memory\nthey may be using.\n\nChange-Id: Ifb2946964bf5d072552dd56d8d6dfdd794af6d84\nSigned-off-by: Laura Abbott <lauraa@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/Epirex/Samsung_STE_Kernel/commits/32cf4ca1be75bdd50dd5ef55bc852551a0572180"},{"sha":"b3049d68aee4fe0e91bcd6a4936af0a64c41637d","author":{"name":"Martijn Coenen","email":"af3eddcbb421ceabee93fcfeaefd7af1c6299549@google.com"},"message":"UPSTREAM: memcg: Only free spare array when readers are done\n\nA spare array holding mem cgroup threshold events is kept around\nto make sure we can always safely deregister an event and have an\narray to store the new set of events in.\n\nIn the scenario where we're going from 1 to 0 registered events, the\npointer to the primary array containing 1 event is copied to the spare\nslot, and then the spare slot is freed because no events are left.\nHowever, it is freed before calling synchronize_rcu(), which means\nreaders may still be accessing threshold->primary after it is freed.\n\nFixed by only freeing after synchronize_rcu().\n\nChange-Id: Id324c5c15cc6aaa684c6e84c1049f723c6c6d984\nSigned-off-by: Martijn Coenen <maco@google.com>","distinct":true,"url":"https://api.github.com/repos/Epirex/Samsung_STE_Kernel/commits/b3049d68aee4fe0e91bcd6a4936af0a64c41637d"},{"sha":"dfd4432d97976c9880c614e99f9f722d23f5461c","author":{"name":"Vinayak Menon","email":"c6e79b2757471d38dfbeaf17f987a81f42208aac@codeaurora.org"},"message":"mm: vmpressure: allow in-kernel clients to subscribe for events\n\nCurrently, vmpressure is tied to memcg and its events are\navailable only to userspace clients. This patch removes\nthe dependency on CONFIG_MEMCG and adds a mechanism for\nin-kernel clients to subscribe for vmpressure events (in\nfact raw vmpressure values are delivered instead of vmpressure\nlevels, to provide clients more flexibility to take actions\non custom pressure levels which are not currently defined\nby vmpressure module).\n\nChange-Id: I38010f166546e8d7f12f5f355b5dbfd6ba04d587\nSigned-off-by: Vinayak Menon <vinmenon@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/Epirex/Samsung_STE_Kernel/commits/dfd4432d97976c9880c614e99f9f722d23f5461c"},{"sha":"958a3cfb88d6bdc04ab8d803c58eacdd6cb2b3f7","author":{"name":"Vinayak Menon","email":"c6e79b2757471d38dfbeaf17f987a81f42208aac@codeaurora.org"},"message":"mm: vmpressure: scale pressure based on reclaim context\n\nThe existing calculation of vmpressure takes into account only\nthe ratio of reclaimed to scanned pages, but not the time spent\nor the difficulty in reclaiming those pages. For e.g. when there\nare quite a number of file pages in the system, an allocation\nrequest can be satisfied by reclaiming the file pages alone. If\nsuch a reclaim is succesful, the vmpressure value will remain low\nirrespective of the time spent by the reclaim code to free up the\nfile pages. With a feature like lowmemorykiller, killing a task\ncan be faster than reclaiming the file pages alone. So if the\nvmpressure values reflect the reclaim difficulty level, clients\ncan make a decision based on that, for e.g. to kill a task early.\n\nThis patch monitors the number of pages scanned in the direct\nreclaim path and scales the vmpressure level according to that.\n\nSigned-off-by: Vinayak Menon <vinmenon@codeaurora.org>\nChange-Id: I6e643d29a9a1aa0814309253a8b690ad86ec0b13","distinct":true,"url":"https://api.github.com/repos/Epirex/Samsung_STE_Kernel/commits/958a3cfb88d6bdc04ab8d803c58eacdd6cb2b3f7"},{"sha":"83a282a3920dbd953c069b74e09048a2b2725e65","author":{"name":"Vinayak Menon","email":"c6e79b2757471d38dfbeaf17f987a81f42208aac@codeaurora.org"},"message":"mm: vmpressure: account allocstalls only on higher pressures\n\nAt present any vmpressure value is scaled up if the pages are\nreclaimed through direct reclaim. This can result in false\nvmpressure values. Consider a case where a device is booted up\nand most of the memory is occuppied by file pages. kswapd will\nmake sure that high watermark is maintained. Now when a sudden\nhuge allocation request comes in, the system will definitely\nhave to get into direct reclaims. The vmpressures can be very low,\nbut because of allocstall accounting logic even these low values\nwill be scaled to values nearing 100. This can resulting in\nunnecessary LMK kills for example.\n\nChange-Id: Idd7c6724264ac89f1f68f2e9d70a32390ffca3e5\nSigned-off-by: Vinayak Menon <vinmenon@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/Epirex/Samsung_STE_Kernel/commits/83a282a3920dbd953c069b74e09048a2b2725e65"},{"sha":"fa387f22c064891b350225c8d441bc74f3e599ae","author":{"name":"Arne Coucheron","email":"38fb404b8987fe904a78d312fdfcc4e7530471f0@gmail.com"},"message":"lmk: Sync with hammerhead\n\nChange-Id: Ie14eaa3a9af82a3c8e2b5c0f00dc847817334d93","distinct":true,"url":"https://api.github.com/repos/Epirex/Samsung_STE_Kernel/commits/fa387f22c064891b350225c8d441bc74f3e599ae"},{"sha":"e6397f1d421c0429965b8073f871a0111d7b3643","author":{"name":"Laura Abbott","email":"8553df7474583031a579ce7388bd843e3b158549@codeaurora.org"},"message":"lowmemorykiller: Dump out slab state information\n\nLeaks from the slab allocator are a very common cause of\nout of memory issues and excessive lowmemorykiller killing.\nDump out the slab statistics as well to help with debugging.\n\nChange-Id: Ia5e4eeb66092c76f2b761321c88fa75c4138927c\nSigned-off-by: Laura Abbott <lauraa@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/Epirex/Samsung_STE_Kernel/commits/e6397f1d421c0429965b8073f871a0111d7b3643"},{"sha":"a0dab60e9c9ec6a12c608d5aec2b78d1dd1d1b05","author":{"name":"Laura Abbott","email":"8553df7474583031a579ce7388bd843e3b158549@codeaurora.org"},"message":"lowmemorykiller: Run the lowmemory notifier when killing\n\nWhen the lowmemory killer starts killing processes, it's useful to\nbe able to see the state of other memory in the system. Call the\nlowmemory notifier to get other clients to dump out their state.\n\nChange-Id: Ie3b1d47149f0108b42b7961fd47a8cc5efe2c590\nSigned-off-by: Laura Abbott <lauraa@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/Epirex/Samsung_STE_Kernel/commits/a0dab60e9c9ec6a12c608d5aec2b78d1dd1d1b05"},{"sha":"04d18c75e9331479764853364c8aed1a35c42c3a","author":{"name":"Susheel Khiani","email":"5aa6d1b9ef056f0957607a4b0807dabe07fa9b70@codeaurora.org"},"message":"lowmemorykiller: Do proper NULL checks\n\nPointer other_free is getting dereferenced without\nperforming proper NULL checks which may cause issue.\nDo proper NULL checks at all points before dereferencing\nit.\n\nChange-Id: I88515703d64730e42598ab16136dcce4c18b099c\nSigned-off-by: Susheel Khiani <skhiani@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/Epirex/Samsung_STE_Kernel/commits/04d18c75e9331479764853364c8aed1a35c42c3a"},{"sha":"45099878a859a574f5a9f8da8087fb985777ee3e","author":{"name":"Liam Mark","email":"db460ca79fa3459eb33cde4b2632331670821bd4@codeaurora.org"},"message":"lowmemorykiller: Don't count swap cache pages twice\n\nThe lowmem_shrink function discounts all the swap cache pages from\nthe file cache count. The zone aware code also discounts all file\ncache pages from a certain zone.  This results in some swap cache\npages being discounted twice, which can result in the low memory\nkiller being unnecessarily aggressive.\n\nFix the low memory killer to only discount the swap cache pages\nonce.\n\nChange-Id: I650bbfbf0fbbabd01d82bdb3502b57ff59c3e14f\nSigned-off-by: Liam Mark <lmark@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/Epirex/Samsung_STE_Kernel/commits/45099878a859a574f5a9f8da8087fb985777ee3e"},{"sha":"85c6090ef018bd5f093190ba00a13fdd9e548fa1","author":{"name":"Vinayak Menon","email":"c6e79b2757471d38dfbeaf17f987a81f42208aac@codeaurora.org"},"message":"lowmemorykiller: adapt to vmpressure\n\nThere were issues reported, where page cache thrashing was\nobserved because of LMK not killing tasks when required,\nresulting in sluggishness and higher app launch latency.\nLMK does not kill a task for the following reasons.\n1. The free and file pages are above the LMK thresholds\n2. LMK tries to pick task with an adj level corresponding\nto current thresholds, but fails to do so because of the\nabsence of tasks in that level.\nBut sometimes it is better to kill a lower adj task, than thrashing.\nAnd there are cases where the number of file pages are huge, though\nwe dont thrash, the reclaim process becomes time consuming, since\nLMK triggers will be delayed because of higher number of file\npages. Even in such cases, when reclaim path finds it difficult\nto reclaim pages, it is better to trigger lmk to free up some memory\nfaster.\n\nThe basic idea here is to make LMK more aggressive dynamically\nwhen such a thrashing scenario is detected.\n\nTo detect thrashing, this patch uses vmpressure events.\nThe values of vmpressure upon which an action has to be taken,\nwas derived empirically.\n\nThis patch also adds tracepoints to validate this feature,\nalmk_shrink and almk_vmpressure.\n\nTwo knobs are available for the user to tune adaptive lmk\nbehaviour.\n\n/sys/module/lowmemorykiller/parameters/adaptive_lmk - Write\n1 to enable the feature, 0 to disable. By default disabled.\n\n/sys/module/lowmemorykiller/parameters/vmpressure_file_min -\nThis parameter controls the behaviour of LMK when vmpressure\nis in the range of 90-94. Adaptive lmk triggers based on number file\npages wrt vmpressure_file_min, when vmpressure is in the range of\n90-94. Usually this is a pseudo minfree value, higher than the\nhighest configured value in minfree array.\n\nChange-Id: I1a08160c35d3e33bdfd1d2c789c288fc07d0f0d3\nSigned-off-by: Vinayak Menon <vinmenon@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/Epirex/Samsung_STE_Kernel/commits/85c6090ef018bd5f093190ba00a13fdd9e548fa1"},{"sha":"ad79b1d11e6e787ed88233f6ba632f24534c8327","author":{"name":"Vinayak Menon","email":"c6e79b2757471d38dfbeaf17f987a81f42208aac@codeaurora.org"},"message":"lowmemorykiller: use for_each_thread instead of buggy while_each_thread\n\nCouple of cases were reported few months ago, where the cpu was blocked\non the following call stack for /seconds/ after which the watchdog fires.\n\ntest_task_flag(p = 0xE14ABF00, ?)\nlowmem_shrink(?, sc = 0xD7A03C04)\nshrink_slab(shrink = 0xD7A03C04, nr_pages_scanned = 0, lru_pages = 120)\ntry_to_free_pages(zonelist = 0xC1116440, ?, ?, ?)\n__alloc_pages_nodemask(?, order = 0, ?, nodemask = 0x0)\n__do_page_cache_readahead(mapping = 0xEB819364, filp = 0xCC16DC00, offset =\nra_submit(?, ?, ?)\nfilemap_fault(vma = 0xC105D240, vmf = 0xD7A03DC8)\n\nThere weren't any dumps to analyse the case, but this can be a possible\nreason. while_each_thread is known to be buggy and can result in the\nfunction looping forever if the task exits, even when protected with\nrcu_read_lock. Use for_each_thread instead.\n\nMore details on the problems with while_each_thread can be found\nat https://lkml.org/lkml/2013/12/2/320\n\nChange-Id: I5eb6e4b463f81142a2a7824db389201357432ec7\nSigned-off-by: Vinayak Menon <vinmenon@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/Epirex/Samsung_STE_Kernel/commits/ad79b1d11e6e787ed88233f6ba632f24534c8327"}]}
{"actor":{"display_login":"Epirex"}}