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 CB579C433EF for ; Thu, 9 Dec 2021 20:48:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 341486B0072; Thu, 9 Dec 2021 15:48:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2F0756B0073; Thu, 9 Dec 2021 15:48:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 16AD76B0074; Thu, 9 Dec 2021 15:48:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0074.hostedemail.com [216.40.44.74]) by kanga.kvack.org (Postfix) with ESMTP id 046886B0072 for ; Thu, 9 Dec 2021 15:48:29 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id AFE2689109 for ; Thu, 9 Dec 2021 20:48:18 +0000 (UTC) X-FDA: 78899443476.08.A8E808D Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) by imf25.hostedemail.com (Postfix) with ESMTP id A6F76A0007 for ; Thu, 9 Dec 2021 20:48:17 +0000 (UTC) Received: by mail-qt1-f175.google.com with SMTP id t34so6531495qtc.7 for ; Thu, 09 Dec 2021 12:48:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=P3+Qzp/iT/XfetT3Cfp4G8l+HGGufPXYg6Iw3f+gTpM=; b=Q1541colSruE92jN06qy10g/3KNhtWWSxW1NbaqvWOwV2AVXQklZfHb3QGEsQDRPOD OyaMRyfEmWuAkWviDB95qEpS9M8s7ESKrcozuSq4H+wfXzpCqubylgFUjoIR95ywuddl QtbunefU8jXI6qLbJ4+0spN+f7plMju9an+Y38pc1b7sebpG3JA7ODqcDfAuJT7pXxq+ qIT3ORdcecR+7J/40aODehTvi4N7IlThy5l47gi62D7DmUK4m262BHZE3Tfl5CIpVV7J UmxRbpYeVRWJvWd15CFzxRaIogyW8Qn+lzeaNlSeeiLUJGfgs2u84eA/VmKMIxK/DXPT 1OOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=P3+Qzp/iT/XfetT3Cfp4G8l+HGGufPXYg6Iw3f+gTpM=; b=t6Qr/oZPiYTo478uc1QoQ7LjkpOGGgHWgy2LmrDSfxpECGvlRmS3jWrt50hSvxx2rg HrKdveRsUAOatSE5oeCQyTtJ7fwazJ/aVct6C6y+R0/yITR4umx3mycB8OZTZMpYEHPz ZntGGjmzxaOCXU879TV2ZJ03EsGWCU/Odf1FbhORLsW+KB5j2njQq9H0Uvxi37Yz+W1r +vpkjFtJZunjDENENj/BO7ANmOs5bqR99g0iC2jmMG3A84/I8wCHdTcDmmut+sAb4JkE vNoMKDF/EqeVvMaV9icnXX8Avu0lGv00veNclu1FK7mrQp9IO+lrtJk/Y86UViqp0MeW e8pQ== X-Gm-Message-State: AOAM53386XTg6tAoZ+l9urQYVZseZxs2Lr+0Xt1upQoLLf1MwVj+kYs4 9lmfFxWWo2ALu40SgO9z9TSyrA== X-Google-Smtp-Source: ABdhPJzBAhwyVg6aVv6mrjRRdZtvbI0aDHRVp0CpwytxoU4oHMhqh6bvnLKC6F/QJ/H1EkAk82XAVA== X-Received: by 2002:ac8:7e95:: with SMTP id w21mr21530426qtj.22.1639082897518; Thu, 09 Dec 2021 12:48:17 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-162-113-129.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.113.129]) by smtp.gmail.com with ESMTPSA id i14sm389184qko.9.2021.12.09.12.48.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Dec 2021 12:48:17 -0800 (PST) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1mvQKu-001R29-2S; Thu, 09 Dec 2021 16:48:16 -0400 Date: Thu, 9 Dec 2021 16:48:16 -0400 From: Jason Gunthorpe To: Suren Baghdasaryan Cc: akpm@linux-foundation.org, mhocko@kernel.org, mhocko@suse.com, rientjes@google.com, willy@infradead.org, hannes@cmpxchg.org, guro@fb.com, riel@surriel.com, minchan@kernel.org, kirill@shutemov.name, aarcange@redhat.com, christian@brauner.io, hch@infradead.org, oleg@redhat.com, david@redhat.com, jannh@google.com, shakeelb@google.com, luto@kernel.org, christian.brauner@ubuntu.com, fweimer@redhat.com, jengelh@inai.de, timmurray@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@android.com Subject: Re: [PATCH v5 3/3] mm/oom_kill: allow process_mrelease to run under mmap_lock protection Message-ID: <20211209204816.GF6467@ziepe.ca> References: <20211209191325.3069345-1-surenb@google.com> <20211209191325.3069345-3-surenb@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211209191325.3069345-3-surenb@google.com> Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=ziepe.ca header.s=google header.b=Q1541col; dmarc=none; spf=pass (imf25.hostedemail.com: domain of jgg@ziepe.ca designates 209.85.160.175 as permitted sender) smtp.mailfrom=jgg@ziepe.ca X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: A6F76A0007 X-Stat-Signature: orqo3jqtcrzjkqf5wwo6abihz1iw9zgt X-HE-Tag: 1639082897-340192 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 Thu, Dec 09, 2021 at 11:13:25AM -0800, Suren Baghdasaryan wrote: > With exit_mmap holding mmap_write_lock during free_pgtables call, > process_mrelease does not need to elevate mm->mm_users in order to > prevent exit_mmap from destrying pagetables while __oom_reap_task_mm > is walking the VMA tree. The change prevents process_mrelease from > calling the last mmput, which can lead to waiting for IO completion > in exit_aio. > > Signed-off-by: Suren Baghdasaryan > Acked-by: Michal Hocko > --- > changes in v5 > - Removed Fixes: tag, per Michal Hocko > - Added Acked-by's > > mm/oom_kill.c | 27 +++++++++++++++------------ > 1 file changed, 15 insertions(+), 12 deletions(-) Reviewed-by: Jason Gunthorpe There are mmget_not_zero's all over the place, can others be cleaned after this series goes ahead too? It seems like anything doing the mmget just to look at the vma list under the mmap lock is now fine with only a mmgrab? A few I know about: drivers/infiniband/core/umem_odp.c: if (!mmget_not_zero(umem->owning_mm)) { This is because mmu_interval_notifier_insert() might call mm_take_all_locks() which was unsafe with concurrent exit_mmap drivers/infiniband/core/umem_odp.c: if (!owning_process || !mmget_not_zero(owning_mm)) { This is because it calls hmm_range_fault() which iterates over the vma list which is safe now drivers/iommu/iommu-sva-lib.c: return mmget_not_zero(mm); drivers/iommu/iommu-sva-lib.c: return ioasid_find(&iommu_sva_pasid, pasid, __mmget_not_zero); It calls find_extend_vma() - but also it doesn't seem to have a mmgrab when it does that mmget. The rcu is messed up here too, so humm. Jason