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 AB443C433FE for ; Wed, 8 Dec 2021 16:50:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2640C6B0073; Wed, 8 Dec 2021 11:50:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 213246B0074; Wed, 8 Dec 2021 11:50:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0DA566B0075; Wed, 8 Dec 2021 11:50:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 003926B0073 for ; Wed, 8 Dec 2021 11:50:34 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id CA2FC8248076 for ; Wed, 8 Dec 2021 16:50:24 +0000 (UTC) X-FDA: 78895215168.21.2ED605E Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com [209.85.219.178]) by imf23.hostedemail.com (Postfix) with ESMTP id 601BE90000A0 for ; Wed, 8 Dec 2021 16:50:24 +0000 (UTC) Received: by mail-yb1-f178.google.com with SMTP id g17so7279455ybe.13 for ; Wed, 08 Dec 2021 08:50:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3Ve3H3qYXxbFpvH5KxZ/byzkUd87jGsC+/Ar5Ml7q30=; b=sj7Az99CmVQ4DUjCRt9g+rHD+buRiC6O0WVNPTxVKcsSrw+mBcnKNjBiEP56c+H64j XnIJL1jcW5EGxbZhdyStOauRkj7tB1xyNn80RIzKZztPHrd0TU1u1qJLeGf+XI/0+m2E NCzjoVGdV4h+PAN6zIUlL3AkYbh6Zkv2Rg5ytnohaMY+P3Y9TOJx0i9q47CAdL/oXw+o 8kR2dXWx+s3PwuPsEn02++uvvN9lqhgR+RzI92H/RMZNxTBK0OvIg5Zn3YbeKL++13tK d9wvXjq3jctGPapogmqM0Pqy2NwQbr24DKwOLoiOV4Rdtq8jMj8Aw3hWjZizGFHwr4fp W9MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3Ve3H3qYXxbFpvH5KxZ/byzkUd87jGsC+/Ar5Ml7q30=; b=66cbPxhw8z6I+YhHw2ntsC46Rn2WDay815ULIuDCbWsJPJVSH6zhRdplx8dcloMvm9 vYtiuIZxdGBmxhfbH0W2iaCzIKtMI00v/3K0QZCxJ5x+d1kuauwrJbAIGbBY0jt3ZJNV 9w2oViQ8SvCKiXwGlKY2ugNLB6gcJtElPg/w3mf6uYTWckt2ej7o461xWbz4uW45SNGJ Oe2R6ci+SzbXXw+snoJJwXfpne++M9l/kqONvbLWVtV68K1SJovAMB9NmyMf9CachWqU UJIHS785DuJXM57H5Y+84VKquflnnlPaDKyGqE9+wrZ1nmq+RDRcA+oRDaonmQ6T4qqu 9S/g== X-Gm-Message-State: AOAM531c8kEDwd6BZCPyeD0UFixRKJoQ0JWd52RwRVRh++7AmCncYj9l uxOVclJPErPwUIfmA7IE7XBprbuLWnjWCRGH6vdhnQ== X-Google-Smtp-Source: ABdhPJyzJkw8GbWYdBBxspECp6hxchfurugjZFKEPQaJO73WxSEvj4d2AGV+oaceIRhKYHACXjAn/c3wmZqqo/hetdU= X-Received: by 2002:a25:6ec5:: with SMTP id j188mr60198733ybc.602.1638982223412; Wed, 08 Dec 2021 08:50:23 -0800 (PST) MIME-Version: 1.0 References: <20211207215031.2251719-1-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Wed, 8 Dec 2021 08:50:12 -0800 Message-ID: Subject: Re: [PATCH v3 1/2] mm: protect free_pgtables with mmap_lock write lock in exit_mmap To: Matthew Wilcox Cc: Michal Hocko , akpm@linux-foundation.org, rientjes@google.com, 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 Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=sj7Az99C; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of surenb@google.com designates 209.85.219.178 as permitted sender) smtp.mailfrom=surenb@google.com X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 601BE90000A0 X-Stat-Signature: q81sm6stp6npwzjzqb1guquf65bx6dsm X-HE-Tag: 1638982224-544905 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 Wed, Dec 8, 2021 at 8:05 AM Matthew Wilcox wrote: > > On Wed, Dec 08, 2021 at 04:51:58PM +0100, Michal Hocko wrote: > > On Wed 08-12-21 15:01:24, Matthew Wilcox wrote: > > > On Tue, Dec 07, 2021 at 03:08:19PM -0800, Suren Baghdasaryan wrote: > > > > > > /** > > > > > > * @close: Called when the VMA is being removed from the MM. > > > > > > * Context: Caller holds mmap_lock. > > > > > > > > BTW, is the caller always required to hold mmap_lock for write or it > > > > *might* hold it? > > > > > > __do_munmap() might hold it for read, thanks to: > > > > > > if (downgrade) > > > mmap_write_downgrade(mm); > > > > > > Should probably say: > > > > > > * Context: User context. May sleep. Caller holds mmap_lock. > > > > > > I don't think we should burden the implementor of the vm_ops with the > > > knowledge that the VM chooses to not hold the mmap_lock under certain > > > circumstances when it doesn't matter whether it's holding the mmap_lock > > > or not. > > > > If we document it like that some code might depend on that lock to be > > held. I think we only want to document that the holder itself is not > > allowed to take mmap sem or a depending lock. > > The only place where we're not currently holding the mmap_lock is at > task exit, where the mmap_lock is effectively held because nobody else > can modify the task's mm. Besides, Suren is changing that in this patch > series anyway, so it will be always true. Ok, I'll make it a separate patch after the patch that changes exit_mmap and this statement will become always true. Sounds reasonable?