On 2023/9/23 07:17, Roman Gushchin wrote: > On Fri, Sep 22, 2023 at 07:05:28AM +0000, Haifeng Xu wrote: >> When application in userland receives oom notification from kernel >> and reads the oom_control file, it's confusing that under_oom is 0 >> though the omm killer hasn't finished. The reason is that under_oom >> is cleared before invoking mem_cgroup_out_of_memory(), so move the >> action that unmark under_oom after completing oom handling. Therefore, >> the value of under_oom won't mislead users. >> >> Signed-off-by: Haifeng Xu <haifeng.xu@xxxxxxxxxx> > > Makes sense to me. > > Acked-by: Roman Gushchin <roman.gushchin@xxxxxxxxx> > > Thanks! OK,thanks. But I forgot to cc mailing list and akpm. I'll resend a new mail later. > >> --- >> mm/memcontrol.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/mm/memcontrol.c b/mm/memcontrol.c >> index e8ca4bdcb03c..0b6ed63504ca 100644 >> --- a/mm/memcontrol.c >> +++ b/mm/memcontrol.c >> @@ -1970,8 +1970,8 @@ static bool mem_cgroup_oom(struct mem_cgroup *memcg, gfp_t mask, int order) >> if (locked) >> mem_cgroup_oom_notify(memcg); >> >> - mem_cgroup_unmark_under_oom(memcg); >> ret = mem_cgroup_out_of_memory(memcg, mask, order); >> + mem_cgroup_unmark_under_oom(memcg); >> >> if (locked) >> mem_cgroup_oom_unlock(memcg); >> -- >> 2.25.1 >>
