Re: [PATCH] proc, oom: do not report alien mms when setting oom_score_adj

[Michal Hocko <mhocko@kernel.org>]

On Wed 13-02-19 10:24:16, Tetsuo Handa wrote:
> Andrew Morton wrote:
> > On Tue, 12 Feb 2019 11:21:29 +0100 Michal Hocko <mhocko@kernel.org> wrote:
> > 
> > > Tetsuo has reported that creating a thousands of processes sharing MM
> > > without SIGHAND (aka alien threads) and setting
> > > /proc/<pid>/oom_score_adj will swamp the kernel log and takes ages [1]
> > > to finish. This is especially worrisome that all that printing is done
> > > under RCU lock and this can potentially trigger RCU stall or softlockup
> > > detector.
> > > 
> > > The primary reason for the printk was to catch potential users who might
> > > depend on the behavior prior to 44a70adec910 ("mm, oom_adj: make sure
> > > processes sharing mm have same view of oom_score_adj") but after more
> > > than 2 years without a single report I guess it is safe to simply remove
> > > the printk altogether.
> > > 
> > > The next step should be moving oom_score_adj over to the mm struct and
> > > remove all the tasks crawling as suggested by [2]
> > > 
> > > [1] http://lkml.kernel.org/r/97fce864-6f75-bca5-14bc-12c9f890e740@i-love.sakura.ne.jp
> > > [2] http://lkml.kernel.org/r/20190117155159.GA4087@dhcp22.suse.cz
> > 
> > I think I'll put a cc:stable on this.  Deleting a might-trigger debug
> > printk is safe and welcome.
> > 
> 
> I don't like this patch, for I can confirm that removing only printk() is not
> sufficient for avoiding hungtask warning. If the reason of removing printk() is
> that we have never heard that someone hit this printk() for more than 2 years,
> the whole iteration is nothing but a garbage. I insist that this iteration
> should be removed.

As the changelog states explicitly, removing the loop should be the next
step and the implementation is outlined in [2]. It is not as simple
as to do the revert as you have proposed. We simply cannot allow to have
different processes disagree on oom_score_adj. This could easily lead
to breaking the OOM_SCORE_ADJ_MIN protection. And that is a correctness
issue.

As a side note.
I am pretty sure I would have more time to do that if only I didn't
really have to spend it on pointless and repeated discussions. You
are clearly not interested on spending _your_ time to address this
issue properly yourself. This is fair but nacking a low hanging
fruit patch that doesn't make situation any worse while it removes a
potential expensive operation from withing RCU context is nothing but
an obstruction.  It is even more sad that this is not the first example
of this attitude which makes it pretty hard, if not impossible, to work
with you.

And another side note. I have already pointed out that this is by far
not the only problem with CLONE_VM without CLONE_SIGHAND threading
model. Try to put your "only the oom paths matter" glasses down
for a moment and try to look what are the actual and much more
serious consequences of this threading model. Hint have a look at
mm_update_next_owner and how we have to for_each_process from under
tasklist_lock or zap_threads with RCU as well.
-- 
Michal Hocko
SUSE Labs