lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAGWkznEuGCZq600XjCtp3hzgN2LrCgwSAfoLwQR7jTw5p=qHoQ@mail.gmail.com> Date: Tue, 10 Apr 2018 10:32:36 +0800 From: Zhaoyang Huang <huangzhaoyang@...il.com> To: Steven Rostedt <rostedt@...dmis.org> Cc: Ingo Molnar <mingo@...nel.org>, LKML <linux-kernel@...r.kernel.org> Subject: Re: [PATCH v1] ringbuffer: Don't choose the process with adj equal OOM_SCORE_ADJ_MIN On Tue, Apr 10, 2018 at 8:32 AM, Zhaoyang Huang <huangzhaoyang@...il.com> wrote: > On Mon, Apr 9, 2018 at 9:49 PM, Steven Rostedt <rostedt@...dmis.org> wrote: >> On Mon, 9 Apr 2018 08:56:01 +0800 >> Zhaoyang Huang <huangzhaoyang@...il.com> wrote: >> >>> >> >>> >> if (oom_task_origin(task)) { >>> >> points = ULONG_MAX; >>> >> goto select; >>> >> } >>> >> >>> >> points = oom_badness(task, NULL, oc->nodemask, oc->totalpages); >>> >> if (!points || points < oc->chosen_points) >>> >> goto next; >>> > >>> > And what's wrong with that? >>> > >>> > -- Steve >>> I think the original thought of OOM is the flag 'OOM_SCORE_ADJ_MIN' is >>> most likely to be set by process himself via accessing the proc file, >>> if it does so, OOM can select it as the victim. except, it is >>> reluctant to choose the critical process to be killed, so I suggest >>> not to set such heavy flag as OOM_SCORE_ADJ_MIN on behalf of -1000 >>> process. >> >> Really, I don't think tasks that are setting OOM_CORE_ADJ_MIN should be >> allocating a lot of memory in the kernel (via ring buffer). It sounds >> like a good way to wreck havoc on the system. >> >> It's basically saying, "I'm going to take up all memory, but don't kill >> me, just kill some random user on the system". >> >> -- Steve > Sure, but the memory status is dynamic, the process could also exceed the limit > at the moment even it check the available memory before. We have to > add protection > for such kind of risk. It could also happen that the critical process > be preempted by > another huge memory allocating process, which may cause insufficient memory when > it schedule back. For bellowing scenario, process A have no intension to exhaust the memory, but will be likely to be selected by OOM for we set OOM_CORE_ADJ_MIN for it. process A(-1000) process B i = si_mem_available(); if (i < nr_pages) return -ENOMEM; schedule ---------------> allocate huge memory <------------- if (user_thread) set_current_oom_origin(); for (i = 0; i < nr_pages; i++) { bpage = kzalloc_node
Powered by blists - more mailing lists