linux-kernel - Re: [PATCH] mm,oom: add tracepoints for oom reaper-related events

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 30 May 2017 15:45:53 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Roman Gushchin <guro@...com>
Cc:     Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
        Johannes Weiner <hannes@...xchg.org>,
        Vladimir Davydov <vdavydov.dev@...il.com>, kernel-team@...com,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH] mm,oom: add tracepoints for oom reaper-related events

On Tue 30-05-17 14:33:35, Roman Gushchin wrote:
> On Tue, May 30, 2017 at 02:34:16PM +0200, Michal Hocko wrote:
> > On Tue 30-05-17 13:05:32, Roman Gushchin wrote:
> > > Add tracepoints to simplify the debugging of the oom reaper code.
> > > 
> > > Trace the following events:
> > > 1) a process is marked as an oom victim,
> > > 2) a process is added to the oom reaper list,
> > > 3) the oom reaper starts reaping process's mm,
> > > 4) the oom reaper finished reaping,
> > > 5) the oom reaper skips reaping.
> > 
> > I am not against but could you explain why the current printks are not
> > sufficient? We do not have any explicit printk for the 2) and 3) but
> > are those really necessary?
> 
> We also don't have any printks for 1) and 2) if, for, instance, we call
> out_of_memory() and task_will_free_mem(current) returns true.
> 
> > 
> > In other words could you describe the situation when you found these
> > tracepoints more useful than what the kernel log offers already?
> 
> During my work on cgroup-aware OOM killer and some issues discovered
> in process (which are described in https://lkml.org/lkml/2017/5/17/542;
> most important problem fixed by Tetsuo), I've found an existing debug output
> insufficient and sometimes too bulky.
> 
> Suggested traces allowed me to debug issues like I've met (double invocation
> of oom_reaper, etc) much easier.

Please describe those and examples how the new tracepoints will be
useful in the changelog.
-- 
Michal Hocko
SUSE Labs