From: kernel test robot <lkp@intel.com>
To: Mina Almasry <almasrymina@google.com>
Cc: kbuild-all@lists.01.org, Mina Almasry <almasrymina@google.com>,
Michal Hocko <mhocko@suse.com>, Theodore Ts'o <tytso@mit.edu>,
Greg Thelen <gthelen@google.com>,
Shakeel Butt <shakeelb@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Memory Management List <linux-mm@kvack.org>,
Hugh Dickins <hughd@google.com>, Roman Gushchin <guro@fb.com>,
Dave Chinner <david@fromorbit.com>
Subject: Re: [PATCH v2 2/4] mm/oom: handle remote ooms
Date: Fri, 12 Nov 2021 01:15:18 +0800 [thread overview]
Message-ID: <202111120134.IieR2mue-lkp@intel.com> (raw)
In-Reply-To: <20211110211951.3730787-3-almasrymina@google.com>
[-- Attachment #1: Type: text/plain, Size: 5221 bytes --]
Hi Mina,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on hnaz-mm/master]
url: https://github.com/0day-ci/linux/commits/Mina-Almasry/mm-shmem-support-deterministic-charging-of-tmpfs/20211111-062122
base: https://github.com/hnaz/linux-mm master
config: um-i386_defconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
# https://github.com/0day-ci/linux/commit/452a4d110272eb39892e4be30526411c7a5cb2e3
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Mina-Almasry/mm-shmem-support-deterministic-charging-of-tmpfs/20211111-062122
git checkout 452a4d110272eb39892e4be30526411c7a5cb2e3
# save the attached .config to linux build tree
mkdir build_dir
make W=1 O=build_dir ARCH=um SUBARCH=i386 SHELL=/bin/bash
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
mm/oom_kill.c: In function 'out_of_memory':
>> mm/oom_kill.c:1116:15: error: 'struct task_struct' has no member named 'in_user_fault'
1116 | if (current->in_user_fault &&
| ^~
vim +1116 mm/oom_kill.c
1044
1045 /**
1046 * out_of_memory - kill the "best" process when we run out of memory
1047 * @oc: pointer to struct oom_control
1048 *
1049 * If we run out of memory, we have the choice between either
1050 * killing a random task (bad), letting the system crash (worse)
1051 * OR try to be smart about which process to kill. Note that we
1052 * don't have to be perfect here, we just have to be good.
1053 */
1054 bool out_of_memory(struct oom_control *oc)
1055 {
1056 unsigned long freed = 0;
1057
1058 if (oom_killer_disabled)
1059 return false;
1060
1061 if (!is_memcg_oom(oc)) {
1062 blocking_notifier_call_chain(&oom_notify_list, 0, &freed);
1063 if (freed > 0)
1064 /* Got some memory back in the last second. */
1065 return true;
1066 }
1067
1068 /*
1069 * If current has a pending SIGKILL or is exiting, then automatically
1070 * select it. The goal is to allow it to allocate so that it may
1071 * quickly exit and free its memory.
1072 */
1073 if (task_will_free_mem(current)) {
1074 mark_oom_victim(current);
1075 wake_oom_reaper(current);
1076 return true;
1077 }
1078
1079 /*
1080 * The OOM killer does not compensate for IO-less reclaim.
1081 * pagefault_out_of_memory lost its gfp context so we have to
1082 * make sure exclude 0 mask - all other users should have at least
1083 * ___GFP_DIRECT_RECLAIM to get here. But mem_cgroup_oom() has to
1084 * invoke the OOM killer even if it is a GFP_NOFS allocation.
1085 */
1086 if (oc->gfp_mask && !(oc->gfp_mask & __GFP_FS) && !is_memcg_oom(oc))
1087 return true;
1088
1089 /*
1090 * Check if there were limitations on the allocation (only relevant for
1091 * NUMA and memcg) that may require different handling.
1092 */
1093 oc->constraint = constrained_alloc(oc);
1094 if (oc->constraint != CONSTRAINT_MEMORY_POLICY)
1095 oc->nodemask = NULL;
1096 check_panic_on_oom(oc);
1097
1098 if (!is_memcg_oom(oc) && sysctl_oom_kill_allocating_task &&
1099 current->mm && !oom_unkillable_task(current) &&
1100 oom_cpuset_eligible(current, oc) &&
1101 current->signal->oom_score_adj != OOM_SCORE_ADJ_MIN) {
1102 get_task_struct(current);
1103 oc->chosen = current;
1104 oom_kill_process(oc, "Out of memory (oom_kill_allocating_task)");
1105 return true;
1106 }
1107
1108 select_bad_process(oc);
1109 /* Found nothing?!?! */
1110 if (!oc->chosen) {
1111 if (is_remote_oom(oc->memcg)) {
1112 /*
1113 * For remote ooms in userfaults, we have no choice but
1114 * to kill the allocating process.
1115 */
> 1116 if (current->in_user_fault &&
1117 !oom_unkillable_task(current)) {
1118 get_task_struct(current);
1119 oc->chosen = current;
1120 oom_kill_process(
1121 oc,
1122 "Out of memory (Killing remote allocating task)");
1123 return true;
1124 }
1125
1126 /*
1127 * For remote ooms in non-userfaults, simply return
1128 * ENOMEM to the caller.
1129 */
1130 return false;
1131 }
1132
1133 dump_header(oc, NULL);
1134 pr_warn("Out of memory and no killable processes...\n");
1135 /*
1136 * If we got here due to an actual allocation at the
1137 * system level, we cannot survive this and will enter
1138 * an endless loop in the allocator. Bail out now.
1139 */
1140 if (!is_sysrq_oom(oc) && !is_memcg_oom(oc))
1141 panic("System is deadlocked on memory\n");
1142 }
1143 if (oc->chosen && oc->chosen != (void *)-1UL)
1144 oom_kill_process(oc, !is_memcg_oom(oc) ? "Out of memory" :
1145 "Memory cgroup out of memory");
1146 return !!oc->chosen;
1147 }
1148
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 9939 bytes --]
next prev parent reply other threads:[~2021-11-11 17:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20211110211951.3730787-1-almasrymina@google.com>
2021-11-10 21:19 ` [PATCH v2 1/4] mm/shmem: support deterministic charging of tmpfs Mina Almasry
2021-11-11 16:53 ` kernel test robot
2021-11-11 17:16 ` kernel test robot
2021-11-10 21:19 ` [PATCH v2 2/4] mm/oom: handle remote ooms Mina Almasry
2021-11-11 17:15 ` kernel test robot [this message]
2021-11-10 21:19 ` [PATCH v2 3/4] mm, shmem: add tmpfs memcg= option documentation Mina Almasry
2021-11-10 21:19 ` [PATCH v2 4/4] mm, shmem, selftests: add tmpfs memcg= mount option tests Mina Almasry
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=202111120134.IieR2mue-lkp@intel.com \
--to=lkp@intel.com \
--cc=akpm@linux-foundation.org \
--cc=almasrymina@google.com \
--cc=david@fromorbit.com \
--cc=gthelen@google.com \
--cc=guro@fb.com \
--cc=hughd@google.com \
--cc=kbuild-all@lists.01.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=shakeelb@google.com \
--cc=tytso@mit.edu \
/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