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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id EC614C433EF for ; Wed, 2 Mar 2022 17:26:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 13CB98D0002; Wed, 2 Mar 2022 12:26:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0ECDF8D0001; Wed, 2 Mar 2022 12:26:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EF5DB8D0002; Wed, 2 Mar 2022 12:26:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0218.hostedemail.com [216.40.44.218]) by kanga.kvack.org (Postfix) with ESMTP id DC94A8D0001 for ; Wed, 2 Mar 2022 12:26:51 -0500 (EST) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 94AF69D282 for ; Wed, 2 Mar 2022 17:26:51 +0000 (UTC) X-FDA: 79200126222.18.ABBD223 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf02.hostedemail.com (Postfix) with ESMTP id 0E54F80013 for ; Wed, 2 Mar 2022 17:26:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1646242010; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0JShSuOVLOzs3H1G/w8tPv6MflNWdaL6JxcHTBNKQ3o=; b=f7v05PQHwTOQE2PRjKCL5kMQiUGwV/3TeavOqC4nsGtr9VCpPZMsUp2a+ieLxyMjvFLN19 PZrMvriFnB600kWhkwwd3n/VMTtKdBZQ9g7Wl8xdvmodLkHj5kwTPKWZUaCkaMXe2LcZ8+ Q3izfar2rJVQWoyLBCMyXkSoKzJ2ywI= Received: from mail-il1-f198.google.com (mail-il1-f198.google.com [209.85.166.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-458-uF4MDNZTMXmlcCpDi6dncw-1; Wed, 02 Mar 2022 12:26:48 -0500 X-MC-Unique: uF4MDNZTMXmlcCpDi6dncw-1 Received: by mail-il1-f198.google.com with SMTP id j7-20020a92ca07000000b002c2b8f24cffso1706091ils.9 for ; Wed, 02 Mar 2022 09:26:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=0JShSuOVLOzs3H1G/w8tPv6MflNWdaL6JxcHTBNKQ3o=; b=JwMxCvUMRjkyG+z2NLmPQVLscl4XaTIwaDYe384td6UrzzXy1wH/35qWbxHcMiJifp 6SzkQLymwPYJyh/kTwJdCdOe+iil77/y4O39oOzM/znTUDC/Y+iSoHFJ02vRnS8WmnpD 7wgL3NyUPLR/pHjjYvTB1HuOr+iTYpXcbOUcm7uE/AdcvYxtaw5LHyWC2l+n3Zm8+4tc UsvUPjp+KYCXrOB42ZOjEcjyt2dmStj6wexyeFbL5qX3mLVqWbcBkHh2LBCXfF7u7yiv Ep9Y0J1uoojQY8dCiIIl3N7N++7lHtBTNZziL3BezigU50+5pEV1wmY4qq2fcBMkyJNa RtLA== X-Gm-Message-State: AOAM530kG8lCfhwaNpjfW8gQ40Js5ZUHq/DookxL1IJtPwa4tMetz0j5 r8j7SSi4o5YIpccMTNIkKN4F6/v1CWx5RHZ2NwfKUFslwrZEJahW4T6u5xDZvJTs6AWRcB8AfP7 cOHUnro5kaIM= X-Received: by 2002:a05:6e02:1a06:b0:2c2:20c8:c016 with SMTP id s6-20020a056e021a0600b002c220c8c016mr27470768ild.143.1646242008009; Wed, 02 Mar 2022 09:26:48 -0800 (PST) X-Google-Smtp-Source: ABdhPJzL8xcxepFTjy/r3mc6Yk5JN69xs++O5rrSs71VHh3GfhTigqI2aHu4Hez7d8OX8UoAnpiSrg== X-Received: by 2002:a05:6e02:1a06:b0:2c2:20c8:c016 with SMTP id s6-20020a056e021a0600b002c220c8c016mr27470748ild.143.1646242007786; Wed, 02 Mar 2022 09:26:47 -0800 (PST) Received: from ?IPV6:2601:280:4400:a2e0::11d7? ([2601:280:4400:a2e0::11d7]) by smtp.gmail.com with ESMTPSA id p2-20020a92d682000000b002c291ae0e1bsm9853732iln.23.2022.03.02.09.26.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Mar 2022 09:26:47 -0800 (PST) Message-ID: <7f1ba14f-34e8-5f05-53b7-c12913693df8@redhat.com> Date: Wed, 2 Mar 2022 12:26:45 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH v3] mm/oom: do not oom reap task with an unresolved robust futex To: Michal Hocko Cc: Waiman Long , linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, jsavitz@redhat.com, peterz@infradead.org, tglx@linutronix.de, mingo@redhat.com, dvhart@infradead.org, dave@stgolabs.net, andrealmeid@collabora.com References: <20220114180135.83308-1-npache@redhat.com> <43a6c470-9fc2-6195-9a25-5321d17540e5@redhat.com> <118fc685-c68d-614f-006a-7d5487302122@redhat.com> From: Nico Pache In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 0E54F80013 X-Stat-Signature: 4onzthygswh7wz84ji1b3d64wqk6ut3a Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=f7v05PQH; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf02.hostedemail.com: domain of npache@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=npache@redhat.com X-HE-Tag: 1646242010-930679 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 3/2/22 09:24, Michal Hocko wrote: > Sorry, this has slipped through cracks. > > On Mon 14-02-22 15:39:31, Nico Pache wrote: > [...] >> We've recently been discussing the following if statement in __oom_reap_task_mm: >> if (vma_is_anonymous(vma) || !(vma->vm_flags & VM_SHARED)) >> >> Given the comment above it, and some of the upstream discussion the original >> RFC, we are struggling to see why this should be a `||` and not an `&&`. If we >> only want to reap anon memory and reaping shared memory can be dangerous is this >> statement incorrect? >> >> We have a patch queued up to make this change, but wanted to get your opinion on >> why this was originally designed this way in case we are missing something. > > I do not really see why this would be wrong. Private file backed > mappings can contain a reapable memory as well. I do not see how this > would solve the futex issue. We were basing our discussion around the following comment: /* * Only anonymous pages have a good chance to be dropped * without additional steps which we cannot afford as we * are OOM already. * * We do not even care about fs backed pages because all * which are reclaimable have already been reclaimed and * we do not want to block exit_mmap by keeping mm ref * count elevated without a good reason. */ So changing to an && would align the functionality with this comment by ignoring fs backed pages, and additionally it prevents shared mappings from being reaped. We have tested this change and found we can no longer reproduce the issue. In our case we allocate the mutex on a MAP_SHARED|MAP_ANONYMOUS mmap so the if- statement in question would no longer return true after the && change. If it is the case that private fs backed pages matter perhaps we want something like this: if ((vma_is_anonymous(vma) && !(vma->vm_flags & VM_SHARED)) ||(!vma_is_anonymous(vma) && !(vma->vm_flags & VM_SHARED))) or more simply: if(!(vma->vm_flags & VM_SHARED)) to exclude all VM_SHARED mappings. -- Nico