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 69793C433DF for ; Fri, 21 Aug 2020 18:53:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2F6F02076E for ; Fri, 21 Aug 2020 18:53:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="lOO5Kcje" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2F6F02076E 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 AFF308D0073; Fri, 21 Aug 2020 14:53:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A87658D0002; Fri, 21 Aug 2020 14:53:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9768F8D0073; Fri, 21 Aug 2020 14:53:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0127.hostedemail.com [216.40.44.127]) by kanga.kvack.org (Postfix) with ESMTP id 7F7708D0002 for ; Fri, 21 Aug 2020 14:53:13 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 471D618017098 for ; Fri, 21 Aug 2020 18:53:13 +0000 (UTC) X-FDA: 77175473466.04.shirt37_1812b862703b Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin04.hostedemail.com (Postfix) with ESMTP id 143FE80137C7 for ; Fri, 21 Aug 2020 18:53:13 +0000 (UTC) X-HE-Tag: shirt37_1812b862703b X-Filterd-Recvd-Size: 6862 Received: from mail-ua1-f67.google.com (mail-ua1-f67.google.com [209.85.222.67]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Fri, 21 Aug 2020 18:53:12 +0000 (UTC) Received: by mail-ua1-f67.google.com with SMTP id z12so817541uam.12 for ; Fri, 21 Aug 2020 11:53:12 -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=3ykL1MaQAjReQJ2aQ56GZWudKyZ/kETzd1mJIShvlqg=; b=lOO5KcjensU81n90JpwVdSdGl5pnw5AlKyiczE4LcmppuBoUTaiEO8XtuFPn4c4PaQ qddvy17JKDmJleSHaIO/Ogew7cBYeFm0pULTnsX65QMgLAMSSyAoynE5HSP5hFg9UVvt fxCxcmgFeMk1I/1MRqOX80fFINtH8/xQu3EChS11kj/UfRKA3Np5FtlLQ8ARBPO1T2Lx Zjzodc2A6qbv2G4od4J2JjvFlfj4FNrM2jL7fEbsJ3kZTUj3qtKjZNIVYJn61lbTGFmW C8cpfqZSURM8+r8V7HOyTGK2UyRXJVTntF7jXg3HKsBdF2j/xvTvOAWXA7k1st3Q/JBC FHDg== 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=3ykL1MaQAjReQJ2aQ56GZWudKyZ/kETzd1mJIShvlqg=; b=kCV/v6GYnrcHNEBF/hZ26isfSHDFsnDbKWn81btIxTq4VXEOXBEl2gKSFpEyh+6Il5 AVcZe4rHpEz5+BLS2VJFRqWkzGXxKyvCZa5k3x2CgvKjadxdDFycHtRMRdTI4+X8fXT5 PAdvnOEBmrsXh7zGD2NA/rZLrLr5g/hFe0HjTefR9DEbxYxtTvikKweqh/QUHMFpknXf qB4SDFTubOHS02NORYF56hPLILEHaiSM1KzsetdvJG6QcvNtpsqG0aMtRWLorYex705s FWHJ/KppUczyD9XbP0otnufm0JwW/b4qIizCtroo8byH9jNyahRP/wNxMbvSwQyaFt23 Z+xQ== X-Gm-Message-State: AOAM532WOhRb8dWb1+arMXtOXUAHVttfExeBa6CnITnFdN65s5+0vdB/ hwom2J1HbpiCDYgdPIl1CDQPaPsxPUwBUdBR5Q3lRg== X-Google-Smtp-Source: ABdhPJwLGWowOiHwq4OtK9k4dIWPuKAtxD38z1jFWXA2gU6Jz5vFAR5L9E8i2RsRzeGBQZ0cRDBXAVroDaZuRzdsANs= X-Received: by 2002:a9f:2265:: with SMTP id 92mr2464321uad.86.1598035991532; Fri, 21 Aug 2020 11:53:11 -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: <20200821175943.GD19445@redhat.com> From: Suren Baghdasaryan Date: Fri, 21 Aug 2020 11:53:00 -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: 143FE80137C7 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 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: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? > > Oleg. > > -- > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com. >