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 E9BF0C54E94 for ; Mon, 23 Jan 2023 16:23:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5CFA26B0075; Mon, 23 Jan 2023 11:23:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 57EF36B0078; Mon, 23 Jan 2023 11:23:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 447886B007B; Mon, 23 Jan 2023 11:23:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 3508D6B0075 for ; Mon, 23 Jan 2023 11:23:08 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 093C1A0A0B for ; Mon, 23 Jan 2023 16:23:08 +0000 (UTC) X-FDA: 80386583256.30.E8ACA50 Received: from mail-yb1-f174.google.com (mail-yb1-f174.google.com [209.85.219.174]) by imf22.hostedemail.com (Postfix) with ESMTP id 33BB2C000D for ; Mon, 23 Jan 2023 16:23:05 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=GT9CtnzF; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of surenb@google.com designates 209.85.219.174 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674490986; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=fMnbgf/RHQ3ZAFZtL86FFLpdOpXvUOvzb7OmVGfvdng=; b=HyCAiVK+P35OQEB7IN8mtXyXUA0hZti44RYchNAMQqLosySHA7g973tlxE6i2QDRwqtLw7 L3lT214YDVHYo1gqo91ZZfBYazJf8YOMCcdlu7wABpVxQOsbeUyGtYe/gltLP4BepHxGwS Z134CQok5hBaRZzfBCrZ6uIsylIqmK8= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=GT9CtnzF; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of surenb@google.com designates 209.85.219.174 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674490986; a=rsa-sha256; cv=none; b=Y5VG/7CKoMQpeLLHLj7JApu5RFtLOSQiorXqKgqCM/c2HIRwlqI0a10dcaA3JYnHSmnCow Wwc/fPinPnPe1xyenL7RHkL9DAnBom2gZ4kLeQF5AhXqWuvw91xJgnwOcJlijXUjJ/Iluu bNJe1XHgYrkuXGhNaX6Ry8moebwxpME= Received: by mail-yb1-f174.google.com with SMTP id 129so11493148ybb.0 for ; Mon, 23 Jan 2023 08:23:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=fMnbgf/RHQ3ZAFZtL86FFLpdOpXvUOvzb7OmVGfvdng=; b=GT9CtnzFDJgzUI5mydXp8vMCy8KjDM1ZqtBPYM0kcgx0FRmyl+E9TT47+NJLVc9OqG 5B3xB6XB0xC505sdjlph/P3bNWUs+gwAY1bJeex4c5AXqMOiJ4kjsB70LJKHU1jq0S1p hpeWHMoy7IOoUmJEKiUYEepireN9i7kkgjXe4rrGmSrAN1Teoju59/CEYvPmeHmEYidF p6NVvwPXwkThYpdM/Zr6S2ip9BawZ0L6I9IbGk4vDo34NVL1snNIbnQPkwhHHAoedn6L IAMXqS1Abqo4chqx/pUJclhMWVSXP4nbkA+vi+eRWwhfst2RSj0RmxvR/EUi0HREO6Zi Qa7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=fMnbgf/RHQ3ZAFZtL86FFLpdOpXvUOvzb7OmVGfvdng=; b=OT6sontpG2L4DuB3TIiQ/LDYJENdp4EtRrFcovNr4byiqgM6spSsB2u0XfXBjuzFKL ShF2uF3YCssMrn1u+2eVTFDxTTgUgVVH+ym0wtp8YIJRLTUmchyi2D9efpnZRj85GZ5m 7MHOtf7CfTO8qHF2sotmaaquauUBK4vxSdxAH8Q9sAQAIlOMpD+udi2POOT0tiqOoMjI DydplLVqc1v4CtFf5TF485uziCrl32HmLG0T8C9jzwofjs5Dz3iyc9edVcOG/aduKHZT FPlUclo9VPFgfG1088Nce7v17D5I2sW1rAhJA5CUBAsIXwbg4oM+xnlSA3c4RCU/iXaI oSfw== X-Gm-Message-State: AFqh2kqZh9ZjHTidnm9T7lKrsmyy7GIN2usLkfqRayO3hCg7Ds2G0XtR K2OQK6x8LjO6MVI3DNQpWf2PxZDCBWv20A5j2jwXEg== X-Google-Smtp-Source: AMrXdXtgthJLROeIi9Kdf1aWHb5lhJLB0d8xJETJsdksQhtsxXC8/QdbWj0HkxC0Jssb10n37A0eaFm+06xsm+/I2B0= X-Received: by 2002:a5b:cc8:0:b0:7ba:78b1:9fcc with SMTP id e8-20020a5b0cc8000000b007ba78b19fccmr2576165ybr.593.1674490984902; Mon, 23 Jan 2023 08:23:04 -0800 (PST) MIME-Version: 1.0 References: <20230120170815.yuylbs27r6xcjpq5@revolver> In-Reply-To: From: Suren Baghdasaryan Date: Mon, 23 Jan 2023 08:22:53 -0800 Message-ID: Subject: Re: [PATCH 39/41] kernel/fork: throttle call_rcu() calls in vm_area_free To: Michal Hocko Cc: Matthew Wilcox , "Liam R. Howlett" , akpm@linux-foundation.org, michel@lespinasse.org, jglisse@google.com, vbabka@suse.cz, hannes@cmpxchg.org, mgorman@techsingularity.net, dave@stgolabs.net, peterz@infradead.org, ldufour@linux.ibm.com, laurent.dufour@fr.ibm.com, paulmck@kernel.org, luto@kernel.org, songliubraving@fb.com, peterx@redhat.com, david@redhat.com, dhowells@redhat.com, hughd@google.com, bigeasy@linutronix.de, kent.overstreet@linux.dev, punit.agrawal@bytedance.com, lstoakes@gmail.com, peterjung1337@gmail.com, rientjes@google.com, axelrasmussen@google.com, joelaf@google.com, minchan@google.com, jannh@google.com, shakeelb@google.com, tatashin@google.com, edumazet@google.com, gthelen@google.com, gurua@google.com, arjunroy@google.com, soheil@google.com, hughlynch@google.com, leewalsh@google.com, posk@google.com, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, x86@kernel.org, linux-kernel@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 33BB2C000D X-Stat-Signature: kt3apj9msmcuwtm4enm7ikwcp8xpa6k5 X-HE-Tag: 1674490985-132194 X-HE-Meta: U2FsdGVkX19HZGPtI9styJ8YRO1dSw7lI4LFDRDwHJGbgmTzgO8DoQggObL8mzc5KaMry1hKOeG4Cfxp18TxjnLJI3Cj9T8MKVSSMb03pkeQv9CoCsbJH4WsDdA9GN8awtgg+DvVv/HHALuxdiDKyEor9HH58+7D72byxhDUNjaK9JYjexk2DCRlRCsxHtLkkGnBRLZsASxzH2VG5//K9abhGVklbqaA+aeya9trPLMVrVFiSFjyoPdXtqMGXWQpLvpHHcwbzprBDZ1rZApQtPulldsER4hBp9Wb7BLQuXJcmGXOFIYQqkHrGc94eoGyAcr3UJ8PLhlENSwmidvJKHvMHkoApsfNVV+8zaLpWMsy2DUzlzNHcG4/nGtDzsjqkLUYThexj+gbmgg5eL2DjzY4JYYXV4YRqeITBoxD2sCgySwg6hvMkClKortZt2ixU0VMDUzwAp7DGTVmF+q+ewpLPddfb381xSEl+3SKsiEzG9cWqEOl1tgv5XfVShSOSk+tRI9jS7uwzSzUydsb1K6ZwiU+1QcWBXKNKn8BS3DZaGFgtk5X0f6DQBCqX1oL0l7LP/lEHIPEpfrempP7/NBhN/NBjaykwzy++Lgv1kAhU3DaSxWycULX34P1x55OpMXTzWT8wZSax135gwjLQz05xSQWQ9a+Y6BWmzdwscZOP7mePvZdgNoHBQGdMAz7qv5L3eVXryLnPdvobupxEqgC3LVx++MMX5URHGQ8QOpQm9oHePvMlyti1YK/X1dlWdTkRG6Y2qyOpjy/0mscph/wO9IlH5K/RbfIk5dRD1Pd4RrZvIwEWCFiCPK0z6VXHDRFs80LikCW6Eacbx730CGNlxMEiOUn5iD5qHzJV/RlUk1egdozEMKXV0hZ/rXQhDxGqxgtnY31SqfeImaldHQP4bywDwwXtd+y7x+wFSUGSdkX/pbS8OhlpeiZE2SUP/U7elUNiBksws1Dcpq 3EihRfed VMk+h3l2mb8kVqevZGqlmwKRAAWkdOzL5yIMuc3oyakW5qHMqRfwAs+PAn9KjAGnNzZx0aSgsgMcwxvXnczVt9PvkLu3NFz57J57MsWKEuGiQYfDN0MW42R6VAbUK7gNdSl+ruIhm+/ND7VNe/4dEIrSprb1qk5pWHF/AxnLeqw845bq7t+QVIdVqgiBa/ZpwLn2lTSzcjLlW0CvxlZxwgciyLGyJ/a9y4u951CqsaZl4lU+pdVnbOCnxo3qOsYkVVkng3Cgc5olpIJEmABmFQhBJnW1/EWBiPlObIeCG0f9y2gDOgpbcQEU/MrJZk9o6wMjbnc38awAwuQJrmb+OwRxG4Z2z5gInrmZlpgnnmKeV74EqktLK0nP8fXRyxUiJ+EZreh8tbZh/ysFLPRex/bdt9w== 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 Mon, Jan 23, 2023 at 1:56 AM Michal Hocko wrote: > > On Fri 20-01-23 09:50:01, Suren Baghdasaryan wrote: > > On Fri, Jan 20, 2023 at 9:32 AM Matthew Wilcox wrote: > [...] > > > The page fault handler (or whatever other reader -- ptrace, proc, etc) > > > should have a refcount on the mm_struct, so we can't be in this path > > > trying to free VMAs. Right? > > > > Hmm. That sounds right. I checked process_mrelease() as well, which > > operated on mm with only mmgrab()+mmap_read_lock() but it only unmaps > > VMAs without freeing them, so we are still good. Michal, do you agree > > this is ok? > > Don't we need RCU procetions for the vma life time assurance? Jann has > already shown how rwsem is not safe wrt to unlock and free without RCU. Jann's case requires a thread freeing the VMA to be blocked on vma write lock waiting for the vma real lock to be released by a page fault handler. However exit_mmap() means mm->mm_users==0, which in turn suggests that there are no racing page fault handlers and no new page fault handlers will appear. Is that a correct assumption? If so, then races with page fault handlers can't happen while in exit_mmap(). Any other path (other than page fault handlers), accesses vma->lock under protection of mmap_lock (for read or write, does not matter). One exception is when we operate on an isolated VMA, then we don't need mmap_lock protection, but exit_mmap() does not deal with isolated VMAs, so out of scope here. exit_mmap() frees vm_area_structs under protection of mmap_lock in write mode, so races with anything other than page fault handler should be safe as they are today. That said, the future possible users of lock_vma_under_rcu() using VMA without mmap_lock protection will have to ensure mm's stability while they are using the obtained VMA. IOW they should elevate mm's refcount and keep it elevated as long as they are using that VMA and not before vma->lock is released. I guess it would be a good idea to document that requirement in lock_vma_under_rcu() comments if we decide to take this route. > > -- > Michal Hocko > SUSE Labs