From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757803AbcFAKsX (ORCPT ); Wed, 1 Jun 2016 06:48:23 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:36248 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751839AbcFAKsW (ORCPT ); Wed, 1 Jun 2016 06:48:22 -0400 Date: Wed, 1 Jun 2016 12:48:19 +0200 From: Michal Hocko To: Tetsuo Handa Cc: oleg@redhat.com, linux-mm@kvack.org, rientjes@google.com, vdavydov@parallels.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/6] proc, oom: drop bogus task_lock and mm check Message-ID: <20160601104819.GL26601@dhcp22.suse.cz> References: <1464613556-16708-2-git-send-email-mhocko@kernel.org> <20160530174324.GA25382@redhat.com> <20160531073227.GA26128@dhcp22.suse.cz> <20160531225303.GE26582@redhat.com> <20160601065339.GA26601@dhcp22.suse.cz> <201606011941.DJJ09369.FSFtQVMLFOJOOH@I-love.SAKURA.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201606011941.DJJ09369.FSFtQVMLFOJOOH@I-love.SAKURA.ne.jp> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 01-06-16 19:41:09, Tetsuo Handa wrote: > Michal Hocko wrote: > > On Wed 01-06-16 00:53:03, Oleg Nesterov wrote: > > > On 05/31, Michal Hocko wrote: > > > > > > > > Oleg has pointed out that can simplify both oom_adj_write and > > > > oom_score_adj_write even further and drop the sighand lock. The only > > > > purpose of the lock was to protect p->signal from going away but this > > > > will not happen since ea6d290ca34c ("signals: make task_struct->signal > > > > immutable/refcountable"). > > > > > > Sorry for confusion, I meant oom_adj_read() and oom_score_adj_read(). > > > > > > As for oom_adj_write/oom_score_adj_write we can remove it too, but then > > > we need to ensure (say, using cmpxchg) that unpriviliged user can not > > > not decrease signal->oom_score_adj_min if its oom_score_adj_write() > > > races with someone else (say, admin) which tries to increase the same > > > oom_score_adj_min. > > > > I am introducing oom_adj_mutex in a later patch so I will move it here. > > Can't we reuse oom_lock like > > if (mutex_lock_killable(&oom_lock)) > return -EINTR; > > ? I think that updating oom_score_adj unlikely races with OOM killer > invocation, and updating oom_score_adj should be a killable operation. We could but what would be an advantage? Do we really need a full oom exclusion? -- Michal Hocko SUSE Labs