From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ADEA8C433E1 for ; Mon, 24 Aug 2020 20:03:25 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3800620656 for ; Mon, 24 Aug 2020 20:03:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="jMH23Rky" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3800620656 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 4BA8B900002; Mon, 24 Aug 2020 16:03:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4457E8D0003; Mon, 24 Aug 2020 16:03:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2E26E900002; Mon, 24 Aug 2020 16:03:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0143.hostedemail.com [216.40.44.143]) by kanga.kvack.org (Postfix) with ESMTP id 15C278D0003 for ; Mon, 24 Aug 2020 16:03:24 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id CB5C6349B for ; Mon, 24 Aug 2020 20:03:23 +0000 (UTC) X-FDA: 77186536686.20.dock85_0e0597027055 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin20.hostedemail.com (Postfix) with ESMTP id 9A466180C07AB for ; Mon, 24 Aug 2020 20:03:23 +0000 (UTC) X-HE-Tag: dock85_0e0597027055 X-Filterd-Recvd-Size: 7305 Received: from mail-vs1-f67.google.com (mail-vs1-f67.google.com [209.85.217.67]) by imf13.hostedemail.com (Postfix) with ESMTP for ; Mon, 24 Aug 2020 20:03:22 +0000 (UTC) Received: by mail-vs1-f67.google.com with SMTP id r7so5138589vsq.5 for ; Mon, 24 Aug 2020 13:03:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8vKTPF0uHpttGBu3pAc6JTpBwBjvTc+sERWwIFnvQkY=; b=jMH23Rky+9ZGR3nFYu9CFT6JRFiIc0SeF66JZUOqwJmSjNVjYQrPipTi14kzsVb1lT qhC6225zBEEie82bxWl/Us2jC++G0QccmOWrJzDnwBVLjL0HV/Lk6TBjkKKpG8PvGTK9 aw4/XQR9qBRESqvoQhR99DAp/8leP+jC3cj1y35TNwPKXkG3hkRKvurf+XJOTiA8sxR1 aTfc+1xXDtLwiPTBNoTgBVkrCi505jvR15rv8zBrPtPrabsEZA6mTzT1dAIRojlYrSDr tt2qXhM7bsJ8ZXr0gGFRdNafDVZ6NeQ7rW0VnbrC06XR8LDp8pMEq4Y5nyk7cXn4vgy9 KS6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8vKTPF0uHpttGBu3pAc6JTpBwBjvTc+sERWwIFnvQkY=; b=kXetTGxctDnuCqOM1cPBVkJNsSSjPOOX1JZ5mcXD98hT+OzMIFeYUtRp5TC1RH8yPn b0uhmNMCruGP4cabQ8p0b2uxVhqs3Z8g1iZuz79vqiINKYC2LDWb+ejHS0vwLmduCc43 fi23iLwn7O81eUJOkQZDL5vW3I8vHArJxdq5GLpF7W/iw1/nOb/4PjybElA9Z0UIf6wL sT0WuLl2T5zsAliLZxCf7VbYI9xnf5t7nbjZXpt9te4V/2Jlv6qLDoI3gE1hRTdNFD10 1SFUYxpV3hbU3FoRtBsk0iBzvgAinwpVOJC7v4eXIORUxvwOp+Eu6YlMvNvbaGl0weJ5 CKdg== X-Gm-Message-State: AOAM530lt2c2HHicYkXYDjrOspOaXEXbWxDLmWuwlur9EOZkJoHyiJMA o7plDTjyBue24W8BUbBhbSHSFVzV0DPzqq2kCyjvGA== X-Google-Smtp-Source: ABdhPJwzBKahra2vHYJC7E4/5M3RHv1PQklZpzoKSjitonSnT18aJ4g97pkIJnnamelNSLFrflkn/bSNaDL5hjsz1zI= X-Received: by 2002:a67:e110:: with SMTP id d16mr3901391vsl.239.1598299401026; Mon, 24 Aug 2020 13:03:21 -0700 (PDT) MIME-Version: 1.0 References: <20200820140054.fdkbotd4tgfrqpe6@wittgenstein> <637ab0e7-e686-0c94-753b-b97d24bb8232@i-love.sakura.ne.jp> <87k0xtv0d4.fsf@x220.int.ebiederm.org> <20200820162645.GP5033@dhcp22.suse.cz> <87r1s0txxe.fsf@x220.int.ebiederm.org> <20200821111558.GG4546@redhat.com> <20200821163300.GB19445@redhat.com> <20200821175943.GD19445@redhat.com> In-Reply-To: From: Suren Baghdasaryan Date: Mon, 24 Aug 2020 13:03:09 -0700 Message-ID: Subject: Re: [PATCH 1/1] mm, oom_adj: don't loop through tasks in __set_oom_adj when not necessary To: Oleg Nesterov Cc: "Eric W. Biederman" , Michal Hocko , Tetsuo Handa , Christian Brauner , Tim Murray , mingo@kernel.org, Peter Zijlstra , Thomas Gleixner , esyr@redhat.com, christian@kellner.me, areber@redhat.com, Shakeel Butt , cyphar@cyphar.com, adobriyan@gmail.com, Andrew Morton , gladkov.alexey@gmail.com, Michel Lespinasse , daniel.m.jordan@oracle.com, avagin@gmail.com, bernd.edlinger@hotmail.de, John Johansen , laoar.shao@gmail.com, Minchan Kim , kernel-team , LKML , linux-fsdevel@vger.kernel.org, linux-mm Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 9A466180C07AB X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Aug 21, 2020 at 11:53 AM Suren Baghdasaryan wrote: > > On Fri, Aug 21, 2020 at 11:00 AM Oleg Nesterov wrote: > > > > On 08/21, Oleg Nesterov wrote: > > > > > > On 08/21, Suren Baghdasaryan wrote: > > > > > > > > On Fri, Aug 21, 2020 at 4:16 AM Oleg Nesterov wrote: > > > > > > > > > > bool probably_has_other_mm_users(tsk) > > > > > { > > > > > return atomic_read_acquire(&tsk->mm->mm_users) > > > > > > atomic_read(&tsk->signal->live); > > > > > } > > > > > > > > > > The barrier implied by _acquire ensures that if we race with the exiting > > > > > task and see the result of exit_mm()->mmput(mm), then we must also see > > > > > the result of atomic_dec_and_test(signal->live). > > > > > > > > > > Either way, if we want to fix the race with clone(CLONE_VM) we need other > > > > > changes. > > > > > > > > The way I understand this condition in __set_oom_adj() sync logic is > > > > that we would be ok with false positives (when we loop unnecessarily) > > > > but we can't tolerate false negatives (when oom_score_adj gets out of > > > > sync). > > > > > > Yes, > > > > > > > With the clone(CLONE_VM) race not addressed we are allowing > > > > false negatives and IMHO that's not acceptable because it creates a > > > > possibility for userspace to get an inconsistent picture. When > > > > developing the patch I did think about using (p->mm->mm_users > > > > > p->signal->nr_threads) condition and had to reject it due to that > > > > reason. > > > > > > Not sure I understand... I mean, the test_bit(MMF_PROC_SHARED) you propose > > > is equally racy and we need copy_oom_score() at the end of copy_process() > > > either way? > > > > On a second thought I agree that probably_has_other_mm_users() above can't > > work ;) Compared to the test_bit(MMF_PROC_SHARED) check it is not _equally_ > > racy, it adds _another_ race with clone(CLONE_VM). > > > > Suppose a single-threaded process P does > > > > clone(CLONE_VM); // creates the child C > > > > // mm_users == 2; P->signal->live == 1; > > > > clone(CLONE_THREAD | CLONE_VM); > > > > // mm_users == 3; P->signal->live == 2; > > > > the problem is that in theory clone(CLONE_THREAD | CLONE_VM) can increment > > _both_ counters between atomic_read_acquire(mm_users) and atomic_read(live) > > in probably_has_other_mm_users() so it can observe mm_users == live == 2. > > I see. So even though live is incremented after mm_users, the observer > from __set_oom_adj still can see them becoming equal because it reads > mm_users first. > > Do you see any such races if I incorporate the changes proposed by > Michal in http://lkml.kernel.org/r/20200820124109.GI5033@dhcp22.suse.cz > ? I have the new patch and I'm testing it right now. So far it behaves > well but maybe I'm missing some rare race here that won't show up in > my testing? > FYI: v2 of this patch with proposed changes is posted at: https://lore.kernel.org/patchwork/patch/1294520/ > > > > > Oleg. > > > > -- > > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com. > >