Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 15 Feb 2019 10:37:48 +0100
From:   Michal Hocko <mhocko@kernel.org>
To:     Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        David Rientjes <rientjes@google.com>,
        Johannes Weiner <hannes@cmpxchg.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Yong-Taek Lee <ytk.lee@samsung.com>, linux-mm@kvack.org,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] proc, oom: do not report alien mms when setting
 oom_score_adj
Message-ID: <20190215093748.GV4525@dhcp22.suse.cz>
References: <201902130124.x1D1OGg3070046@www262.sakura.ne.jp>
 <20190213114733.GB4525@dhcp22.suse.cz>
 <201902150057.x1F0vxHb076966@www262.sakura.ne.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201902150057.x1F0vxHb076966@www262.sakura.ne.jp>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri 15-02-19 09:57:59, Tetsuo Handa wrote:
> Sigh, you are again misunderstanding...
> 
> I'm not opposing to forbid CLONE_VM without CLONE_SIGHAND threading model.

We cannot do that unfortunatelly. This is a long term allowed threading
model and somebody might depend on it.

> I'm asserting that we had better revert the iteration for now, even if we will
> strive towards forbidding CLONE_VM without CLONE_SIGHAND threading model.
> 
> You say "And that is a correctness issue." but your patch is broken because
> your patch does not close the race.

Removing the printk as done in this patch has hardly anything to do with
race conditions and it is not advertised to close any either. So please
stop being off topic again.

> Since nobody seems to be using CLONE_VM
> without CLONE_SIGHAND threading, we can both avoid hungtask problem and close
> the race by eliminating this broken iteration. We don't need to worry about
> "This could easily lead to breaking the OOM_SCORE_ADJ_MIN protection." case
> because setting OOM_SCORE_ADJ_MIN needs administrator's privilege.

This is simply wrong. We have to care about the OOM_SCORE_ADJ_MIN
especially because it is the _admin's_ decision to hide a task from the
OOM killer.

> And it is
> YOUR PATCH that still allows leading to breaking the OOM_SCORE_ADJ_MIN
> protection. My patch is more simpler and accurate than your patch.

Please stop this already. Your patch to revert the oom_score_adj
consistency is simply broken. Full stop. I have already outlined how to
do that properly. If you do care really, go and try to play with that
idea. I can be convinced there are holes in that approach and can
discuss further solutions but trying to propose a broken approach again
and again is just wasting time.
-- 
Michal Hocko
SUSE Labs