Re: [PATCH v4 1/2] mm: introduce process_mrelease system call

On Tue, Aug 3, 2021 at 11:21 PM Michal Hocko [off-list ref] wrote:

On Tue 03-08-21 15:09:43, Suren Baghdasaryan wrote:

quoted

On Tue, Aug 3, 2021 at 10:27 AM Suren Baghdasaryan [off-list ref] wrote:

[...]

quoted

quoted

quoted

quoted

+     if (task_will_free_mem(task) && (task->flags & PF_KTHREAD) == 0) {
+             mm = task->mm;
+             mmget(mm);
+     }
+     task_unlock(task);
+     if (!mm) {

Do we want to treat MMF_OOM_SKIP as a failure?

Yeah, I don't think we want to create additional contention if
oom-killer is already working on this mm. Should we return EBUSY in
this case? Other possible options is ESRCH, indicating that this
process is a goner, so don't bother. WDYT?

After considering this some more I think ESRCH would be more
appropriate. EBUSY might be understood as "I need to retry at a better
time", which is not what we want here.

Why cannot we simply return 0 in that case. The work has been done
already by the kernel so why should we tell the caller that there was
something wrong?

Ah, you are right. I was under the impression that MMF_OOM_SKIP means
oom-killer is reaping the mm, but looks like it means that mm was
already reaped. If that's true then I agree, returning 0 is the right
move here. Will fix.

--
Michal Hocko
SUSE Labs