From: kbuild test robot <lkp@intel.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: kbuild-all@01.org, guro@fb.com,
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
rientjes@google.com, hannes@cmpxchg.org, vdavydov.dev@gmail.com,
tj@kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org,
torvalds@linux-foundation.org
Subject: Re: [PATCH] mm, memcg, oom: fix pre-mature allocation failures
Date: Fri, 1 Jun 2018 00:31:43 +0800 [thread overview]
Message-ID: <201805312246.hC0wxCog%fengguang.wu@intel.com> (raw)
In-Reply-To: <20180529081639.GM27180@dhcp22.suse.cz>
[-- Attachment #1: Type: text/plain, Size: 4603 bytes --]
Hi Michal,
I love your patch! Yet something to improve:
[auto build test ERROR on mmotm/master]
[also build test ERROR on next-20180531]
[cannot apply to v4.17-rc7]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Michal-Hocko/mm-memcg-oom-fix-pre-mature-allocation-failures/20180531-220120
base: git://git.cmpxchg.org/linux-mmotm.git master
config: i386-randconfig-x078-201821 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All error/warnings (new ones prefixed by >>):
mm/oom_kill.c: In function 'out_of_memory':
>> mm/oom_kill.c:1157:28: error: invalid operands to binary | (have 'struct task_struct *' and 'struct mem_cgroup *')
return !!(oc->chosen_task | oc->chosen_memcg);
~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~
>> mm/oom_kill.c:1158:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
vim +1157 mm/oom_kill.c
1068
1069 /**
1070 * out_of_memory - kill the "best" process when we run out of memory
1071 * @oc: pointer to struct oom_control
1072 *
1073 * If we run out of memory, we have the choice between either
1074 * killing a random task (bad), letting the system crash (worse)
1075 * OR try to be smart about which process to kill. Note that we
1076 * don't have to be perfect here, we just have to be good.
1077 */
1078 bool out_of_memory(struct oom_control *oc)
1079 {
1080 unsigned long freed = 0;
1081 enum oom_constraint constraint = CONSTRAINT_NONE;
1082 bool delay = false; /* if set, delay next allocation attempt */
1083
1084 if (oom_killer_disabled)
1085 return false;
1086
1087 if (!is_memcg_oom(oc)) {
1088 blocking_notifier_call_chain(&oom_notify_list, 0, &freed);
1089 if (freed > 0)
1090 /* Got some memory back in the last second. */
1091 return true;
1092 }
1093
1094 /*
1095 * If current has a pending SIGKILL or is exiting, then automatically
1096 * select it. The goal is to allow it to allocate so that it may
1097 * quickly exit and free its memory.
1098 */
1099 if (task_will_free_mem(current)) {
1100 mark_oom_victim(current);
1101 wake_oom_reaper(current);
1102 return true;
1103 }
1104
1105 /*
1106 * The OOM killer does not compensate for IO-less reclaim.
1107 * pagefault_out_of_memory lost its gfp context so we have to
1108 * make sure exclude 0 mask - all other users should have at least
1109 * ___GFP_DIRECT_RECLAIM to get here.
1110 */
1111 if (oc->gfp_mask && !(oc->gfp_mask & __GFP_FS))
1112 return true;
1113
1114 /*
1115 * Check if there were limitations on the allocation (only relevant for
1116 * NUMA and memcg) that may require different handling.
1117 */
1118 constraint = constrained_alloc(oc);
1119 if (constraint != CONSTRAINT_MEMORY_POLICY)
1120 oc->nodemask = NULL;
1121 check_panic_on_oom(oc, constraint);
1122
1123 if (!is_memcg_oom(oc) && sysctl_oom_kill_allocating_task &&
1124 current->mm && !oom_unkillable_task(current, NULL, oc->nodemask) &&
1125 current->signal->oom_score_adj != OOM_SCORE_ADJ_MIN) {
1126 get_task_struct(current);
1127 oc->chosen_task = current;
1128 oom_kill_process(oc, "Out of memory (oom_kill_allocating_task)");
1129 return true;
1130 }
1131
1132 if (mem_cgroup_select_oom_victim(oc) && oom_kill_memcg_victim(oc)) {
1133 delay = true;
1134 goto out;
1135 }
1136
1137 select_bad_process(oc);
1138 /* Found nothing?!?! Either we hang forever, or we panic. */
1139 if (!oc->chosen_task && !is_sysrq_oom(oc) && !is_memcg_oom(oc)) {
1140 dump_header(oc, NULL);
1141 panic("Out of memory and no killable processes...\n");
1142 }
1143 if (oc->chosen_task && oc->chosen_task != INFLIGHT_VICTIM) {
1144 oom_kill_process(oc, !is_memcg_oom(oc) ? "Out of memory" :
1145 "Memory cgroup out of memory");
1146 delay = true;
1147 }
1148
1149 out:
1150 /*
1151 * Give the killed process a good chance to exit before trying
1152 * to allocate memory again.
1153 */
1154 if (delay)
1155 schedule_timeout_killable(1);
1156
> 1157 return !!(oc->chosen_task | oc->chosen_memcg);
> 1158 }
1159
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 27001 bytes --]
prev parent reply other threads:[~2018-05-31 16:32 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-12 14:18 [PATCH] mm,oom: Don't call schedule_timeout_killable() with oom_lock held Tetsuo Handa
2018-05-15 9:16 ` Michal Hocko
2018-05-18 10:14 ` Tetsuo Handa
2018-05-18 12:20 ` Michal Hocko
2018-05-20 15:56 ` Tetsuo Handa
2018-05-22 6:18 ` Michal Hocko
2018-05-23 10:24 ` Tetsuo Handa
2018-05-23 11:57 ` Michal Hocko
2018-05-23 13:45 ` Tetsuo Handa
2018-05-23 14:56 ` Michal Hocko
2018-05-24 10:51 ` Tetsuo Handa
2018-05-24 11:50 ` Michal Hocko
2018-05-25 1:17 ` Tetsuo Handa
2018-05-25 8:31 ` Michal Hocko
2018-05-25 10:57 ` Tetsuo Handa
2018-05-25 11:42 ` Michal Hocko
2018-05-25 11:46 ` Tetsuo Handa
2018-05-28 12:43 ` Michal Hocko
2018-05-28 20:57 ` Tetsuo Handa
2018-05-29 7:17 ` Michal Hocko
2018-05-29 23:07 ` Andrew Morton
2018-05-31 10:10 ` Tetsuo Handa
2018-05-31 10:44 ` Michal Hocko
2018-05-31 15:23 ` Tetsuo Handa
2018-05-31 18:47 ` Michal Hocko
2018-06-01 1:21 ` Tetsuo Handa
2018-06-01 8:04 ` Michal Hocko
2018-06-01 15:28 ` Michal Hocko
2018-06-01 21:11 ` Andrew Morton
2018-06-04 7:04 ` Michal Hocko
2018-06-04 10:41 ` Tetsuo Handa
2018-06-04 11:22 ` Michal Hocko
2018-06-04 11:30 ` Tetsuo Handa
2018-06-06 9:02 ` David Rientjes
2018-06-06 13:37 ` Tetsuo Handa
2018-06-06 18:44 ` David Rientjes
2018-05-29 7:17 ` Michal Hocko
2018-05-29 8:16 ` Michal Hocko
2018-05-29 14:33 ` Tetsuo Handa
2018-05-29 17:18 ` Michal Hocko
2018-05-29 17:28 ` Michal Hocko
2018-05-31 16:31 ` kbuild test robot [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201805312246.hC0wxCog%fengguang.wu@intel.com \
--to=lkp@intel.com \
--cc=akpm@linux-foundation.org \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=kbuild-all@01.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=rientjes@google.com \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=vdavydov.dev@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox