{"push_id":881948951,"size":24,"distinct_size":24,"ref":"refs/heads/master","head":"a1808c00f0a4d7531e651d82cbadfdf71d2760e8","before":"2c0e895ac7e67fbb35f5c8ce260798973cbae6ac","commits":[{"sha":"94b187349c50e8d8bc89fad7d1136565b8eeae1b","author":{"email":"c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","name":"Paul Reioux"},"message":"mm/vmscan.c: swap: add per-partition lock for swapfile compatibility fix up\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>","distinct":true,"url":"https://api.github.com/repos/sattarvoybek/KK_kernel/commits/94b187349c50e8d8bc89fad7d1136565b8eeae1b"},{"sha":"02c0ef335ac00f5989654f5e528fcc40e8b8f7db","author":{"email":"c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","name":"Paul Reioux"},"message":"mm/page_io.c: kk mr2 source compatiblity fix up\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>","distinct":true,"url":"https://api.github.com/repos/sattarvoybek/KK_kernel/commits/02c0ef335ac00f5989654f5e528fcc40e8b8f7db"},{"sha":"2aed31e7af31e0cc38910d119874631c9601b7e9","author":{"email":"39ea6a09710987173e32e37c86918024a0f441c1@suse.de","name":"Mel Gorman"},"message":"mm: Clear page active before releasing pages\n\nActive pages should not be freed to the page allocator as it triggers\na bad page state warning. Fengguang Wu reported the following\nbug and bisected it to the patch \"mm: remove lru parameter from\n__lru_cache_add and lru_cache_add_lru\" which is currently in mmotm as\nmm-remove-lru-parameter-from-__lru_cache_add-and-lru_cache_add_lru.patch\n\n[   84.212960] BUG: Bad page state in process rm  pfn:0b0c9\n[   84.214682] page:ffff88000d646240 count:0 mapcount:0 mapping:          (null) index:0x0\n[   84.216883] page flags: 0x20000000004c(referenced|uptodate|active)\n[   84.218697] CPU: 1 PID: 283 Comm: rm Not tainted 3.10.0-rc4-04361-geeb9bfc #49\n[   84.220729]  ffff88000d646240 ffff88000d179bb8 ffffffff82562956 ffff88000d179bd8\n[   84.223242]  ffffffff811333f1 000020000000004c ffff88000d646240 ffff88000d179c28\n[   84.225387]  ffffffff811346a4 ffff880000270000 0000000000000000 0000000000000006\n[   84.227294] Call Trace:\n[   84.227867]  [<ffffffff82562956>] dump_stack+0x27/0x30\n[   84.229045]  [<ffffffff811333f1>] bad_page+0x130/0x158\n[   84.230261]  [<ffffffff811346a4>] free_pages_prepare+0x8b/0x1e3\n[   84.231765]  [<ffffffff8113542a>] free_hot_cold_page+0x28/0x1cf\n[   84.233171]  [<ffffffff82585830>] ? _raw_spin_unlock_irqrestore+0x6b/0xc6\n[   84.234822]  [<ffffffff81135b59>] free_hot_cold_page_list+0x30/0x5a\n[   84.236311]  [<ffffffff8113a4ed>] release_pages+0x251/0x267\n[   84.237653]  [<ffffffff8112a88d>] ? delete_from_page_cache+0x48/0x9e\n[   84.239142]  [<ffffffff8113ad93>] __pagevec_release+0x2b/0x3d\n[   84.240473]  [<ffffffff8113b45a>] truncate_inode_pages_range+0x1b0/0x7ce\n[   84.242032]  [<ffffffff810e76ab>] ? put_lock_stats.isra.20+0x1c/0x53\n[   84.243480]  [<ffffffff810e77f5>] ? lock_release_holdtime+0x113/0x11f\n[   84.244935]  [<ffffffff8113ba8c>] truncate_inode_pages+0x14/0x1d\n[   84.246337]  [<ffffffff8119b3ef>] evict+0x11f/0x232\n[   84.247501]  [<ffffffff8119c527>] iput+0x1a5/0x218\n[   84.248607]  [<ffffffff8118f015>] do_unlinkat+0x19b/0x25a\n[   84.249828]  [<ffffffff810ea993>] ? trace_hardirqs_on_caller+0x210/0x2ce\n[   84.251382]  [<ffffffff8144372e>] ? trace_hardirqs_on_thunk+0x3a/0x3f\n[   84.252879]  [<ffffffff8118f10d>] SyS_unlinkat+0x39/0x4c\n[   84.254174]  [<ffffffff825874d6>] system_call_fastpath+0x1a/0x1f\n[   84.255596] Disabling lock debugging due to kernel taint\nThe problem was that a page marked for activation was released via\npagevec. This patch clears the active bit before freeing in this case.\n\nSigned-off-by: Mel Gorman <mgorman@suse.de>\nReported-and-Tested-by: Fengguang Wu <fengguang.wu@intel.com>\nSigned-off-by: Paul Reioux <reioux@gmail.com>","distinct":true,"url":"https://api.github.com/repos/sattarvoybek/KK_kernel/commits/2aed31e7af31e0cc38910d119874631c9601b7e9"},{"sha":"1d4dab0a4c069f8ce5d3d14b0075517f49287fa7","author":{"email":"96b69fcd5eef28e1d6d34746a22b4c94eec21bb3@motorola.com","name":"Kevin Wells"},"message":"swap: mem_cgroup_count_swap_user is unlocking wrong spinlock\n\nThis function should be unlocking the spin lock obtained\nfrom swap_info_get. Instead, it is trying to unlock swap_lock\nwhich is static to swapfile.c.\n\nChange-Id: Ic6949edddf17439d878dca7fa33b0da6de23417a\nSigned-off-by: Kevin Wells <kwells@motorola.com>\nReviewed-on: http://gerrit.pcs.mot.com/601262\nSLTApproved: Slta Waiver <sltawvr@motorola.com>\nTested-by: Jira Key <jirakey@motorola.com>\nReviewed-by: Kevin L Wells <kewells@motorola.com>\nReviewed-by: Anil Patel <anilpatel@motorola.com>\nReviewed-by: Igor Kovalenko <igork@motorola.com>\nSubmit-Approved: Jira Key <jirakey@motorola.com>","distinct":true,"url":"https://api.github.com/repos/sattarvoybek/KK_kernel/commits/1d4dab0a4c069f8ce5d3d14b0075517f49287fa7"},{"sha":"ad86eaeb9a6e5a04d427eb4acf1e3cab7c467271","author":{"email":"fc510f1a5245533652d9a1d0409192cb7b09bc74@amazon.com","name":"Pradeep Sawlani"},"message":"ksm: check and skip page, if it is already scanned\n\nOn system like Android where most of the process are forked\nfrom parent w/o execve, KSM can scan same page multiple times\nin one scan cycle. There is no advantage in scanning same page\nmultiple times for merging. During testing with Android, it was\nobserved around 60% pages are skipped for each scan cycle.\n\nChange-Id: I0cf01802f0b4d61fcab92558beb9e1c660dc9a77\nLink: http://lkml.kernel.org/r/CAMrOTPgBtANS_ryRjan0-dTL97U7eRvtf3dCsss=Kn+Uk89fuA@mail.gmail.com\nSigned-off-by: Pradeep Sawlani <sawlani@amazon.com>\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>","distinct":true,"url":"https://api.github.com/repos/sattarvoybek/KK_kernel/commits/ad86eaeb9a6e5a04d427eb4acf1e3cab7c467271"},{"sha":"e981f7cbc7b76f5acf308116c20f03f54a47e7a1","author":{"email":"d8cd2994e15bc61ddb2b113030bda55eebc3a0fe@google.com","name":"David Rientjes"},"message":"mm, oom: normalize oom scores to oom_score_adj scale only for userspace\n\nThe oom_score_adj scale ranges from -1000 to 1000 and represents the\nproportion of memory available to the process at allocation time.  This\nmeans an oom_score_adj value of 300, for example, will bias a process as\nthough it was using an extra 30.0% of available memory and a value of\n-350 will discount 35.0% of available memory from its usage.\n\nThe oom killer badness heuristic also uses this scale to report the oom\nscore for each eligible process in determining the \"best\" process to\nkill.  Thus, it can only differentiate each process's memory usage by\n0.1% of system RAM.\n\nOn large systems, this can end up being a large amount of memory: 256MB\non 256GB systems, for example.\n\nThis can be fixed by having the badness heuristic to use the actual\nmemory usage in scoring threads and then normalizing it to the\noom_score_adj scale for userspace.  This results in better comparison\nbetween eligible threads for kill and no change from the userspace\nperspective.\n\nSuggested-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>\nTested-by: Dave Jones <davej@redhat.com>\nSigned-off-by: David Rientjes <rientjes@google.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/sattarvoybek/KK_kernel/commits/e981f7cbc7b76f5acf308116c20f03f54a47e7a1"},{"sha":"b4bb4004c6a1771b30586cac823241d4a38e6d67","author":{"email":"d8cd2994e15bc61ddb2b113030bda55eebc3a0fe@google.com","name":"David Rientjes"},"message":"mm, oom: fix badness score underflow\n\nIf the privileges given to root threads (3% of allowable memory) or a\nnegative value of /proc/pid/oom_score_adj happen to exceed the amount of\nrss of a thread, its badness score overflows as a result of commit\na7f638f999ff (\"mm, oom: normalize oom scores to oom_score_adj scale only\nfor userspace\").\n\nFix this by making the type signed and return 1, meaning the thread is\nstill eligible for kill, if the value is negative.\n\nReported-by: Dave Jones <davej@redhat.com>\nAcked-by: Oleg Nesterov <oleg@redhat.com>\nSigned-off-by: David Rientjes <rientjes@google.com>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/sattarvoybek/KK_kernel/commits/b4bb4004c6a1771b30586cac823241d4a38e6d67"},{"sha":"e16489482a827c44e3d603755219486674cac9a6","author":{"email":"d8cd2994e15bc61ddb2b113030bda55eebc3a0fe@google.com","name":"David Rientjes"},"message":"mm, oom: fix and cleanup oom score calculations\n\nThe divide in p->signal->oom_score_adj * totalpages / 1000 within\noom_badness() was causing an overflow of the signed long data type.\n\nThis adds both the root bias and p->signal->oom_score_adj before doing the\nnormalization which fixes the issue and also cleans up the calculation.\n\nTested-by: Dave Jones <davej@redhat.com>\nSigned-off-by: David Rientjes <rientjes@google.com>\nCc: KOSAKI Motohiro <kosaki.motohiro@gmail.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/sattarvoybek/KK_kernel/commits/e16489482a827c44e3d603755219486674cac9a6"},{"sha":"9d1eddd95864dd16250a9c3b43d35470b0b46bcb","author":{"email":"d8cd2994e15bc61ddb2b113030bda55eebc3a0fe@google.com","name":"David Rientjes"},"message":"mm, oom: do not schedule if current has been killed\n\nThe oom killer currently schedules away from current in an uninterruptible\nsleep if it does not have access to memory reserves.  It's possible that\ncurrent was killed because it shares memory with the oom killed thread or\nbecause it was killed by the user in the interim, however.\n\nThis patch only schedules away from current if it does not have a pending\nkill, i.e.  if it does not share memory with the oom killed thread.  It's\npossible that it will immediately retry its memory allocation and fail,\nbut it will immediately be given access to memory reserves if it calls the\noom killer again.\n\nThis prevents the delay of memory freeing when threads that share memory\nwith the oom killed thread get unnecessarily scheduled.\n\nSigned-off-by: David Rientjes <rientjes@google.com>\nCc: Oleg Nesterov <oleg@redhat.com>\nAcked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>\nAcked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/sattarvoybek/KK_kernel/commits/9d1eddd95864dd16250a9c3b43d35470b0b46bcb"},{"sha":"62f3971467264af010e8734787da7e15b6a800af","author":{"email":"d8cd2994e15bc61ddb2b113030bda55eebc3a0fe@google.com","name":"David Rientjes"},"message":"mm, oom: fix potential killing of thread that is disabled from oom killing\n\n/proc/sys/vm/oom_kill_allocating_task will immediately kill current when\nthe oom killer is called to avoid a potentially expensive tasklist scan\nfor large systems.\n\nCurrently, however, it is not checking current's oom_score_adj value which\nmay be OOM_SCORE_ADJ_MIN, meaning that it has been disabled from oom\nkilling.\n\nThis patch avoids killing current in such a condition and simply falls\nback to the tasklist scan since memory still needs to be freed.\n\nSigned-off-by: David Rientjes <rientjes@google.com>\nCc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>\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>","distinct":true,"url":"https://api.github.com/repos/sattarvoybek/KK_kernel/commits/62f3971467264af010e8734787da7e15b6a800af"},{"sha":"12040f8a9a1639366c26a86a0e8d3d7d64e7ffbd","author":{"email":"d8cd2994e15bc61ddb2b113030bda55eebc3a0fe@google.com","name":"David Rientjes"},"message":"mm, oom: introduce helper function to process threads during scan\n\nThis patch introduces a helper function to process each thread during the\niteration over the tasklist.  A new return type, enum oom_scan_t, is\ndefined to determine the future behavior of the iteration:\n\n - OOM_SCAN_OK: continue scanning the thread and find its badness,\n\n - OOM_SCAN_CONTINUE: do not consider this thread for oom kill, it's\n   ineligible,\n\n - OOM_SCAN_ABORT: abort the iteration and return, or\n\n - OOM_SCAN_SELECT: always select this thread with the highest badness\n   possible.\n\nThere is no functional change with this patch.  This new helper function\nwill be used in the next patch in the memory controller.\n\nReviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>\nAcked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>\nReviewed-by: Michal Hocko <mhocko@suse.cz>\nSigned-off-by: David Rientjes <rientjes@google.com>\nCc: Oleg Nesterov <oleg@redhat.com>\nReviewed-by: Sha Zhengju <handai.szj@taobao.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/sattarvoybek/KK_kernel/commits/12040f8a9a1639366c26a86a0e8d3d7d64e7ffbd"},{"sha":"b55efa0be942d857876be900b8acb7e8a2c70c11","author":{"email":"d8cd2994e15bc61ddb2b113030bda55eebc3a0fe@google.com","name":"David Rientjes"},"message":"mm, memcg: introduce own oom handler to iterate only over its own threads\n\nThe global oom killer is serialized by the per-zonelist\ntry_set_zonelist_oom() which is used in the page allocator.  Concurrent\noom kills are thus a rare event and only occur in systems using\nmempolicies and with a large number of nodes.\n\nMemory controller oom kills, however, can frequently be concurrent since\nthere is no serialization once the oom killer is called for oom conditions\nin several different memcgs in parallel.\n\nThis creates a massive contention on tasklist_lock since the oom killer\nrequires the readside for the tasklist iteration.  If several memcgs are\ncalling the oom killer, this lock can be held for a substantial amount of\ntime, especially if threads continue to enter it as other threads are\nexiting.\n\nSince the exit path grabs the writeside of the lock with irqs disabled in\na few different places, this can cause a soft lockup on cpus as a result\nof tasklist_lock starvation.\n\nThe kernel lacks unfair writelocks, and successful calls to the oom killer\nusually result in at least one thread entering the exit path, so an\nalternative solution is needed.\n\nThis patch introduces a seperate oom handler for memcgs so that they do\nnot require tasklist_lock for as much time.  Instead, it iterates only\nover the threads attached to the oom memcg and grabs a reference to the\nselected thread before calling oom_kill_process() to ensure it doesn't\nprematurely exit.\n\nThis still requires tasklist_lock for the tasklist dump, iterating\nchildren of the selected process, and killing all other threads on the\nsystem sharing the same memory as the selected victim.  So while this\nisn't a complete solution to tasklist_lock starvation, it significantly\nreduces the amount of time that it is held.\n\nAcked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>\nAcked-by: Michal Hocko <mhocko@suse.cz>\nSigned-off-by: David Rientjes <rientjes@google.com>\nCc: Oleg Nesterov <oleg@redhat.com>\nCc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>\nReviewed-by: Sha Zhengju <handai.szj@taobao.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/sattarvoybek/KK_kernel/commits/b55efa0be942d857876be900b8acb7e8a2c70c11"},{"sha":"046d0b6063db2f79f0930f7d859b4d0a71a0f819","author":{"email":"d8cd2994e15bc61ddb2b113030bda55eebc3a0fe@google.com","name":"David Rientjes"},"message":"mm, oom: reduce dependency on tasklist_lock\n\nSince exiting tasks require write_lock_irq(&tasklist_lock) several times,\ntry to reduce the amount of time the readside is held for oom kills.  This\nmakes the interface with the memcg oom handler more consistent since it\nnow never needs to take tasklist_lock unnecessarily.\n\nThe only time the oom killer now takes tasklist_lock is when iterating the\nchildren of the selected task, everything else is protected by\nrcu_read_lock().\n\nThis requires that a reference to the selected process, p, is grabbed\nbefore calling oom_kill_process().  It may release it and grab a reference\non another one of p's threads if !p->mm, but it also guarantees that it\nwill release the reference before returning.\n\n[hughd@google.com: fix duplicate put_task_struct()]\nSigned-off-by: David Rientjes <rientjes@google.com>\nCc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>\nReviewed-by: Michal Hocko <mhocko@suse.cz>\nCc: Oleg Nesterov <oleg@redhat.com>\nCc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>\nCc: Johannes Weiner <hannes@cmpxchg.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>\n\nConflicts:\n\tmm/oom_kill.c","distinct":true,"url":"https://api.github.com/repos/sattarvoybek/KK_kernel/commits/046d0b6063db2f79f0930f7d859b4d0a71a0f819"},{"sha":"f1e3a44f05058ee06466101cc18d228295365d3f","author":{"email":"d8cd2994e15bc61ddb2b113030bda55eebc3a0fe@google.com","name":"David Rientjes"},"message":"mm, memcg: move all oom handling to memcontrol.c\n\nBy globally defining check_panic_on_oom(), the memcg oom handler can be\nmoved entirely to mm/memcontrol.c.  This removes the ugly #ifdef in the\noom killer and cleans up the code.\n\nSigned-off-by: David Rientjes <rientjes@google.com>\nCc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>\nAcked-by: Michal Hocko <mhocko@suse.cz>\nCc: Oleg Nesterov <oleg@redhat.com>\nCc: 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: Paul Reioux <reioux@gmail.com>\n\nConflicts:\n\tmm/oom_kill.c","distinct":true,"url":"https://api.github.com/repos/sattarvoybek/KK_kernel/commits/f1e3a44f05058ee06466101cc18d228295365d3f"},{"sha":"ce6adda57326a1f89a34c5aac8fd499d95660f31","author":{"email":"d8cd2994e15bc61ddb2b113030bda55eebc3a0fe@google.com","name":"David Rientjes"},"message":"mm, oom: allow exiting threads to have access to memory reserves\n\nExiting threads, those with PF_EXITING set, can pagefault and require\nmemory before they can make forward progress.  This happens, for instance,\nwhen a process must fault task->robust_list, a userspace structure, before\ndetaching its memory.\n\nThese threads also aren't guaranteed to get access to memory reserves\nunless oom killed or killed from userspace.  The oom killer won't grant\nmemory reserves if other threads are also exiting other than current and\nstalling at the same point.  This prevents needlessly killing processes\nwhen others are already exiting.\n\nInstead of special casing all the possible situations between PF_EXITING\ngetting set and a thread detaching its mm where it may allocate memory,\nwhich probably wouldn't get updated when a change is made to the exit\npath, the solution is to give all exiting threads access to memory\nreserves if they call the oom killer.  This allows them to quickly\nallocate, detach its mm, and free the memory it represents.\n\nSummary of Luigi's bug report:\n\n: He had an oom condition where threads were faulting on task->robust_list\n: and repeatedly called the oom killer but it would defer killing a thread\n: because it saw other PF_EXITING threads.  This can happen anytime we need\n: to allocate memory after setting PF_EXITING and before detaching our mm;\n: if there are other threads in the same state then the oom killer won't do\n: anything unless one of them happens to be killed from userspace.\n:\n: So instead of only deferring for PF_EXITING and !task->robust_list, it's\n: better to just give them access to memory reserves to prevent a potential\n: livelock so that any other faults that may be introduced in the future in\n: the exit path don't cause the same problem (and hopefully we don't allow\n: too many of those!).\n\nSigned-off-by: David Rientjes <rientjes@google.com>\nAcked-by: Minchan Kim <minchan@kernel.org>\nTested-by: Luigi Semenzato <semenzato@google.com>\nCc: 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>","distinct":true,"url":"https://api.github.com/repos/sattarvoybek/KK_kernel/commits/ce6adda57326a1f89a34c5aac8fd499d95660f31"},{"sha":"0dff18df02883231f2f02742e70a91a6bb576c75","author":{"email":"4c9eb49378914b743bdd32292c04df29b820d73e@cn.fujitsu.com","name":"Lai Jiangshan"},"message":"oom: use N_MEMORY instead N_HIGH_MEMORY\n\nN_HIGH_MEMORY stands for the nodes that has normal or high memory.\nN_MEMORY stands for the nodes that has any memory.\n\nThe code here need to handle with the nodes which have memory, we should\nuse N_MEMORY instead.\n\nSigned-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>\nAcked-by: Hillf Danton <dhillf@gmail.com>\nSigned-off-by: Wen Congyang <wency@cn.fujitsu.com>\nCc: Christoph Lameter <cl@linux.com>\nCc: Lin Feng <linfeng@cn.fujitsu.com>\nCc: David Rientjes <rientjes@google.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/sattarvoybek/KK_kernel/commits/0dff18df02883231f2f02742e70a91a6bb576c75"},{"sha":"4244679c7a21f1e49e41fa991dae7d2af4e83276","author":{"email":"d8cd2994e15bc61ddb2b113030bda55eebc3a0fe@google.com","name":"David Rientjes"},"message":"mm, oom: cleanup pagefault oom handler\n\nTo lock the entire system from parallel oom killing, it's possible to pass\nin a zonelist with all zones rather than using for_each_populated_zone()\nfor the iteration.  This obsoletes try_set_system_oom() and\nclear_system_oom() so that they can be removed.\n\nSigned-off-by: David Rientjes <rientjes@google.com>\nCc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>\nCc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>\nReviewed-by: Michal Hocko <mhocko@suse.cz>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/sattarvoybek/KK_kernel/commits/4244679c7a21f1e49e41fa991dae7d2af4e83276"},{"sha":"2dac4be2d05879c8db161260cdaf9f65fdf96fc8","author":{"email":"df9728c9e5104131c08c7adb03af425394842596@rustcorp.com.au","name":"Rusty Russell"},"message":"mm/oom_kill: remove weird use of ERR_PTR()/PTR_ERR().\n\nThe normal expectation for ERR_PTR() is to put a negative errno into a\npointer.  oom_kill puts the magic -1 in the result (and has since\npre-git), which is probably clearer with an explicit cast.\n\nCc: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Rusty Russell <rusty@rustcorp.com.au>","distinct":true,"url":"https://api.github.com/repos/sattarvoybek/KK_kernel/commits/2dac4be2d05879c8db161260cdaf9f65fdf96fc8"},{"sha":"8956c8dd73bfca25e666b43ad7b1b47a8d671230","author":{"email":"20b70f0af00562e63758b9ee42012ecc96c58590@redhat.com","name":"Oleg Nesterov"},"message":"oom_kill: change oom_kill.c to use for_each_thread()\n\nChange oom_kill.c to use for_each_thread() rather than the racy\nwhile_each_thread() which can loop forever if we race with exit.\n\nNote also that most users were buggy even if while_each_thread() was\nfine, the task can exit even _before_ rcu_read_lock().\n\nFortunately the new for_each_thread() only requires the stable\ntask_struct, so this change fixes both problems.\n\nSigned-off-by: Oleg Nesterov <oleg@redhat.com>\nReviewed-by: Sergey Dyasly <dserrg@gmail.com>\nTested-by: Sergey Dyasly <dserrg@gmail.com>\nReviewed-by: Sameer Nanda <snanda@chromium.org>\nCc: \"Eric W. Biederman\" <ebiederm@xmission.com>\nCc: Frederic Weisbecker <fweisbec@gmail.com>\nCc: Mandeep Singh Baines <msb@chromium.org>\nCc: \"Ma, Xindong\" <xindong.ma@intel.com>\nReviewed-by: Michal Hocko <mhocko@suse.cz>\nCc: \"Tu, Xiaobing\" <xiaobing.tu@intel.com>\nAcked-by: David Rientjes <rientjes@google.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/sattarvoybek/KK_kernel/commits/8956c8dd73bfca25e666b43ad7b1b47a8d671230"},{"sha":"ce3f85921f5bc89f183e9d47e5cbef7a5cc347e3","author":{"email":"20b70f0af00562e63758b9ee42012ecc96c58590@redhat.com","name":"Oleg Nesterov"},"message":"oom_kill: has_intersects_mems_allowed() needs rcu_read_lock()\n\nAt least out_of_memory() calls has_intersects_mems_allowed() without\neven rcu_read_lock(), this is obviously buggy.\n\nAdd the necessary rcu_read_lock().  This means that we can not simply\nreturn from the loop, we need \"bool ret\" and \"break\".\n\nWhile at it, swap the names of task_struct's (the argument and the\nlocal).  This cleans up the code a little bit and avoids the unnecessary\ninitialization.\n\nSigned-off-by: Oleg Nesterov <oleg@redhat.com>\nReviewed-by: Sergey Dyasly <dserrg@gmail.com>\nTested-by: Sergey Dyasly <dserrg@gmail.com>\nReviewed-by: Sameer Nanda <snanda@chromium.org>\nCc: \"Eric W. Biederman\" <ebiederm@xmission.com>\nCc: Frederic Weisbecker <fweisbec@gmail.com>\nCc: Mandeep Singh Baines <msb@chromium.org>\nCc: \"Ma, Xindong\" <xindong.ma@intel.com>\nReviewed-by: Michal Hocko <mhocko@suse.cz>\nCc: \"Tu, Xiaobing\" <xiaobing.tu@intel.com>\nAcked-by: David Rientjes <rientjes@google.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/sattarvoybek/KK_kernel/commits/ce3f85921f5bc89f183e9d47e5cbef7a5cc347e3"}]}