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 4CCB5C433F5 for ; Mon, 25 Apr 2022 19:00:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9E1406B0078; Mon, 25 Apr 2022 15:00:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 990AE6B007E; Mon, 25 Apr 2022 15:00:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 830A26B0080; Mon, 25 Apr 2022 15:00:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 7455C6B0078 for ; Mon, 25 Apr 2022 15:00:31 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 3BDF862529 for ; Mon, 25 Apr 2022 19:00:31 +0000 (UTC) X-FDA: 79396317462.23.D77D743 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf31.hostedemail.com (Postfix) with ESMTP id BFB9F2004E for ; Mon, 25 Apr 2022 19:00:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1650913229; 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=yesgUQqnGsJp5AZDU8lHq6JmWqxHleZ7ErqYUsZh9NA=; b=I4+sVm+YugF/usbgAp6lOaCY5wUZhPNArqOC6tBAfOn87alyuP0cbA3zC8OMfAoIy8eWxf rhKP/GSvS7+R+ppgGlq3IUb4E3J44sMuX4SZZW4T90XQ59yzQuwjpiFTzXRt23+RypvMNM yY1XWtHZIhm+b1aO0EjFe/+g+Y2ZgOw= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-621-9x0cmQzHM-KPvEBiC_OI3w-1; Mon, 25 Apr 2022 15:00:27 -0400 X-MC-Unique: 9x0cmQzHM-KPvEBiC_OI3w-1 Received: by mail-qv1-f69.google.com with SMTP id dv6-20020ad44ee6000000b0045642576917so819805qvb.17 for ; Mon, 25 Apr 2022 12:00:27 -0700 (PDT) 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=yesgUQqnGsJp5AZDU8lHq6JmWqxHleZ7ErqYUsZh9NA=; b=q9A5y0rVF/0MY3sn2Z2Pv2eN5HZJghkmSpvubS4cvikZY7vDOWLA8OjGiGK3djGt2G DiYTiZOXH6LBhvVXvHEsEM3bIYyx4+Yw2VDttpEkpxM2GHouc9Wb8frU5mLFyR2g6o5r 0KKhOWw3KuRERbyzXMF/+/SEaOS5jI9S9dbC5JkZ0LA+xbCmfhngqoqMxn2r+YoI1kYo b/TWDY+mjL2mKQhRzqCPWGPgRAd4SDufp3zWxzFXZ3htDdE4yBNvVng1HEybth9NuZNX GvoLZ0QNwc14tF2W1Y9untvsd/txovY099UEWY7xl2nwnQmyTkxfGzLB2e4bFcf0tbMx 1aqw== X-Gm-Message-State: AOAM532PUx7zqzTRaerZF5NIvvxiJCmlPbGr3fJLnAZ/oi1wRlUey3E8 hyQx2/BWqOR0I8Ku7paemQ/On2l+vjTFdD5VkxWxupq6QbFCCLcIVw0QW+ibVmHZsZKN7hnFo+G QaHDPXX/maBA= X-Received: by 2002:a05:620a:f03:b0:67e:1e38:3a90 with SMTP id v3-20020a05620a0f0300b0067e1e383a90mr10906170qkl.442.1650913227368; Mon, 25 Apr 2022 12:00:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJysUK0+Y5yn9Be8Tckv3kv/cNzzWDG3BSxM5NdR773RfhPy1SUZWHcctVRgFRbzM8SsxuS4Kg== X-Received: by 2002:a05:620a:f03:b0:67e:1e38:3a90 with SMTP id v3-20020a05620a0f0300b0067e1e383a90mr10906156qkl.442.1650913227153; Mon, 25 Apr 2022 12:00:27 -0700 (PDT) Received: from [192.168.138.203] (76-230-233-110.lightspeed.miamfl.sbcglobal.net. [76.230.233.110]) by smtp.gmail.com with ESMTPSA id c136-20020a379a8e000000b0069e5df9d953sm5307449qke.34.2022.04.25.12.00.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 Apr 2022 12:00:26 -0700 (PDT) Message-ID: <19303483-5700-fb6e-ba4a-398913370100@redhat.com> Date: Mon, 25 Apr 2022 15:00:24 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [RFC 3/3] exit: Check for MMF_OOM_SKIP in exit_mmap To: Michal Hocko Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, David Rientjes , Andrea Arcangeli References: <20220421190533.1601879-1-npache@redhat.com> <20220421190533.1601879-4-npache@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-Stat-Signature: kxcjgroz17hmn5c8wjgocfgp3s3zt85a Authentication-Results: imf31.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=I4+sVm+Y; spf=none (imf31.hostedemail.com: domain of npache@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=npache@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: BFB9F2004E X-HE-Tag: 1650913222-758242 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 4/22/22 11:38, Michal Hocko wrote: > On Thu 21-04-22 15:05:33, Nico Pache wrote: >> The MMF_OOM_SKIP bit is used to indicate weather a mm_struct can not be >> invalided or has already been invalided. exit_mmap currently calls >> __oom_reap_task_mm unconditionally despite the fact that the oom reaper >> may have already called this. >> >> Add a check for the MMF_OOM_SKIP bit being set in exit_mmap to avoid >> unnessary calls to the invalidate code. > > Why do we care about this? Is there no cost to the MMU/TLB invalidation? The MMU notifier contains a lock too so perhaps we can also avoids some unnecessary MMU notifier lock contention. > >> A slight race can occur on the MMF_OOM_SKIP bit that will still allow >> this to run twice. My testing has shown an ~66% decrease in double calls >> to _oom_reap_task_mm. >> >> Fixes: 27ae357fa82b ("mm, oom: fix concurrent munlock and oom reaper unmap, v3") > > I do not see this would be fixing anything. Ok im just trying to make sure we are keeping an eye on what introduced this double call. Davids commit above is what introduced the oom_reap_task_mm in the exit_mmap code. It goes along with some other changes that I dont fully understand without more studying, so that's why I was hoping he could provide some input around that CVE (the main thing im concerned about re-introducing). > >> Cc: David Rientjes >> Cc: Michal Hocko >> Cc: Andrea Arcangeli >> Signed-off-by: Nico Pache >> --- >> mm/mmap.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/mm/mmap.c b/mm/mmap.c >> index a2968669fd4e..b867f408dacd 100644 >> --- a/mm/mmap.c >> +++ b/mm/mmap.c >> @@ -3113,7 +3113,8 @@ void exit_mmap(struct mm_struct *mm) >> /* mm's last user has gone, and its about to be pulled down */ >> mmu_notifier_release(mm); >> >> - if (unlikely(mm_is_oom_victim(mm))) { >> + if (unlikely(mm_is_oom_victim(mm)) && >> + !test_bit(MMF_OOM_SKIP, &mm->flags)) { >> /* >> * Manually reap the mm to free as much memory as possible. >> * Then, as the oom reaper does, set MMF_OOM_SKIP to disregard >> -- >> 2.35.1 >