All of lore.kernel.org
 help / color / mirror / Atom feed
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 --]

WARNING: multiple messages have this Message-ID (diff)
From: kernel test robot <lkp@intel.com>
To: kbuild-all@lists.01.org
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: 5364 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(a)lists.01.org

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 9939 bytes --]

  reply	other threads:[~2021-11-11 17:15 UTC|newest]

Thread overview: 18+ 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-10 21:19   ` Mina Almasry
2021-11-10 21:19   ` Mina Almasry
2021-11-11 16:53   ` kernel test robot
2021-11-11 16:53     ` kernel test robot
2021-11-11 17:16   ` 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-10 21:19   ` Mina Almasry
2021-11-10 21:19   ` Mina Almasry
2021-11-11 17:15   ` kernel test robot [this message]
2021-11-11 17:15     ` kernel test robot
2021-11-10 21:19 ` [PATCH v2 3/4] mm, shmem: add tmpfs memcg= option documentation Mina Almasry
2021-11-10 21:19   ` Mina Almasry
2021-11-10 21:19   ` Mina Almasry
2021-11-10 21:19 ` [PATCH v2 4/4] mm, shmem, selftests: add tmpfs memcg= mount option tests Mina Almasry
2021-11-10 21:19   ` Mina Almasry
2021-11-10 21:19   ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.