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 0AC54C05027 for ; Mon, 23 Jan 2023 19:57:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 79E726B0071; Mon, 23 Jan 2023 14:57:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 728296B0075; Mon, 23 Jan 2023 14:57:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5A14E6B0078; Mon, 23 Jan 2023 14:57:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 4BA656B0071 for ; Mon, 23 Jan 2023 14:57:46 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 2079BA3DBB for ; Mon, 23 Jan 2023 19:57:46 +0000 (UTC) X-FDA: 80387124132.02.23F0F7A Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) by imf01.hostedemail.com (Postfix) with ESMTP id 46D3340014 for ; Mon, 23 Jan 2023 19:57:43 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Bv35EwZq; spf=pass (imf01.hostedemail.com: domain of surenb@google.com designates 209.85.128.48 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674503864; 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=N9qQteWUwJAybu5GRF/Inp+dulaE16FE+nFFa5cXdiw=; b=3CjQdfyOks2Gx3C4stWO3ThHM77fXu+yDr4AvooPC/vSYLhl4hDEggoU1zuQWN/jB7XGjC T1S9MZ+XExNjyFF7qUwzyHCsOZS5/XqFG6wHe727u0gzNMP2Mp8gCw6SPddyAKSo4lyZgD HIKvVVMRCpdbzHZrOVAZFoW5Q8rTnoU= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Bv35EwZq; spf=pass (imf01.hostedemail.com: domain of surenb@google.com designates 209.85.128.48 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674503864; a=rsa-sha256; cv=none; b=1V1xG1dlGB5rtmXGrFzcHdHj7PFQUGjhFC9EhGfWP8IfaHUBa9sCvqN+7/cH16YB5n4ORK Bv1QWGCwTc/B7RqtCB6ulEIp2kSMMZj9A5wqa8gVhk7x+kaW3p0hm4RBfQZQO6LtkjrJyX 4lXBQx/POyAZFviG6LfbBP/AodxJ24w= Received: by mail-wm1-f48.google.com with SMTP id e19-20020a05600c439300b003db1cac0c1fso9920162wmn.5 for ; Mon, 23 Jan 2023 11:57:43 -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=N9qQteWUwJAybu5GRF/Inp+dulaE16FE+nFFa5cXdiw=; b=Bv35EwZqB5nxyfqZxvO4lwvh8MLjmXwaCbA2/qy9aRspOZWssKSLZNy1CJi6P2Rn5q VaGw+yN1V50UWyKMeGwynQOb7hF/ZfbIbdFR/lGzcA4C0YsDCysKaI2Ew5+2SN28SRpS PQuQZzuOA3GgIkkhuZcapOi/l72TfgcIr0qYhGtVxiq+Kj/ID+igXXq3jaRMNCPG8Cxo yACXNWWYQMHT0KGLp70yDEhiaTqlaLgAavvJ/N1MumrXfgP3vD+NpWfzIjr5Wv/tMw4k Sr1NzETlMhnsm/5FEcYy2eMKInOQVf1b21OlIhiA0e+wg58EJ5dEOix4XJTLI1MLHahp s1iA== 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=N9qQteWUwJAybu5GRF/Inp+dulaE16FE+nFFa5cXdiw=; b=AylFhw+7JvpAR5/VloQlW/2KRxylWaZ93AMUGSEyJ0ZS6nFtSmpaN5GqOi5xaS5m0+ XbCLSOGflIHWmU/k10wPcwH9Ej5xXw8SJVEN9xbGb7FRsC7KObaIm+gkA0dx3CNC6O+p rg+F+Smpi1g/lyCe6nBSefTC3y/9P221i43TqVYDrSwRt3SVGvcFkbsPcd9dawGh2Ogy 4Y3BbuuMFLwnt9hINRDnWAoX/Btn3Yjs7HwdVUW8kWCLTyDp15LJlvrkF3obSkh7yj1G TZgNL14t8x2i2X5xc2MRqWrdAlSM023p6VlKkDNjHdFGGOiBd7TWX741E2H1l5DkMaTF KVlg== X-Gm-Message-State: AFqh2kqXhLf8nRKxwsb8/K97sWuVV9h5fHPaHTjnvUTrIOBvGDy/RJ9w 8UxHS2KfnxURCNX4WoO2YAmxeoWFaUtLfO6j/+454A== X-Google-Smtp-Source: AMrXdXtrPcaRXutaoPRaMiUkuyZPEFxjJaJdQAYs4KPWXWBZrMYZ3+R/eUUgMejXYArVmp3bLK0Z+Cqc/V9/bckA/ko= X-Received: by 2002:a05:600c:d1:b0:3d9:f629:9043 with SMTP id u17-20020a05600c00d100b003d9f6299043mr1458123wmm.122.1674503862640; Mon, 23 Jan 2023 11:57:42 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Suren Baghdasaryan Date: Mon, 23 Jan 2023 11:57:30 -0800 Message-ID: Subject: Re: [PATCH 39/41] kernel/fork: throttle call_rcu() calls in vm_area_free To: Matthew Wilcox Cc: Michal Hocko , "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-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 46D3340014 X-Stat-Signature: aan5umk9hg6zxawx75ybhdxqk85xmne9 X-Rspam-User: X-HE-Tag: 1674503863-771235 X-HE-Meta: U2FsdGVkX1/J0zGnS8kOUwwJIIsNF1kkF7HsNJMQep7M1ebXhdUFe6HsGVLswjJgBd9H0wP9m1nI16urEnqZOLFV6yivVJSoJXv1P4xMP+K5oez01gCWQXxmDYqnW515qVsZiCVzML2Mm+7Jd5h7c445qn77IQfoOwbaSQPyVGo+9DrlLEtrJaf5dLIv7D/j+H4FrWW0TADYePnEhMySx5Y74OXJa5pAu+KKMhqtf6g3lHUIrb/uoukGiPwwpZ/Hpu8daC0w8Iefj/hoZ5dATuAIbbxXzFdfVRahVIFplDj1je9sysWDHPLqdg3Y0tVyhKFtWs4evru57aSQhY9OMFDkQ8fFOkeacoU8eKXD8IzereBJXsUUdm/emWq1bYoyaw65DRECDGkke6kXkzghQgS3VlNPXEI8UuEeqV5P9RfDGz+RSukxq8pc70a3f8GEp85t/XzWhMznjXTFBgYaITOlGGO3P6DLTvQSBVOQ53814j/JLoeWDK25mBDb2WhZomhZT6/gBieHKZ14PzHK1Hx4ADBKeiHaa5Ke644k9o0QYeaJd/HDz0arIXISoY8c7UNzVrZeOgkfVlSa5Eoj3wZtZmLlgYE32inJZwmVS3ME0MQKW4Ge7AOZFzUqKiF2Wx3ky/FOFaaUrLU+RZToSdqZrvQywoFqxwX6NBpXpxiH01Op9KuOhYssR88UXFhrTCJXZw6dXNOTuVRXcXJMpT5AK9TaCzegjDKTze2R173G7UWpnr1C/lcl0fpAX3SscO/g6ykVgH71Xn1KzqdK1WyFmUa5mV4S/yxAuOQZsvkUAcDwCDsh7/3SXTrv1eYh8iLL8EuftHnD4z4nnOxF4BSTSBY+ZZeqsufR1mEsogKHKmOgcs7OZZdFErIVp4ELxYtdEEIAtYpSa71RMLZ9xLKmYlDXsj4aBXrlFfpXC23PIiv0sRceMmCiytwf/X5T5HEFXdPHyCaLfBWOe9y BlHbPXw6 20+IWFavWrM7ZjJmYW9iSUmcv3ssIuBUb9Us/bVn1fLIR6Q6V+TgfgbVwym0xaCaDZ90C10NoGN5eYNofH0XyVLUlKbleczGeOyWBgNjsAZ9OWLLyNu6ityBezAL3b+WzludFk3pdPg6CZsNc5WqTLR+2PJ3H3N2K/QrDWUkmrwdqf5FlPzAKEZx8zahAenEfG7RApRgpfjh9VwUPO+QMusvOlSZg34BWQ9JDx/AFVoILddSb8BxYAMG4pm96fL8ush2td1nOgLdJ3FRgIMIB/pckKHqFR52HskiTm5x0DKqGUThln/uKUH0GFI4eQcFL1NvDF1ebtIsCT/ct306iwtQ/dSUNRX6rqnsm 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 11:31 AM Matthew Wilcox wrote: > > On Mon, Jan 23, 2023 at 08:18:37PM +0100, Michal Hocko wrote: > > On Mon 23-01-23 18:23:08, Matthew Wilcox wrote: > > > On Mon, Jan 23, 2023 at 09:46:20AM -0800, Suren Baghdasaryan wrote: > > [...] > > > > Yes, batching the vmas into a list and draining it in remove_mt() and > > > > exit_mmap() as you suggested makes sense to me and is quite simple. > > > > Let's do that if nobody has objections. > > > > > > I object. We *know* nobody has a reference to any of the VMAs because > > > you have to have a refcount on the mm before you can get a reference > > > to a VMA. If Michal is saying that somebody could do: > > > > > > mmget(mm); > > > vma = find_vma(mm); > > > lock_vma(vma); > > > mmput(mm); > > > vma->a = b; > > > unlock_vma(mm, vma); > > > > > > then that's something we'd catch in review -- you obviously can't use > > > the mm after you've dropped your reference to it. > > > > I am not claiming this is possible now. I do not think we want to have > > something like that in the future either but that is really hard to > > envision. I am claiming that it is subtle and potentially error prone to > > have two different ways of mass vma freeing wrt. locking. Also, don't we > > have a very similar situation during last munmaps? > > We shouldn't have two ways of mass VMA freeing. Nobody's suggesting that. > There are two cases; there's munmap(), which typically frees a single > VMA (yes, theoretically, you can free hundreds of VMAs with a single > call which spans multiple VMAs, but in practice that doesn't happen), > and there's exit_mmap() which happens on exec() and exit(). > > For the munmap() case, just RCU-free each one individually. For the > exit_mmap() case, there's no need to use RCU because nobody should still > have a VMA pointer after calling mmdrop() [1] > > [1] Sorry, the above example should have been mmgrab()/mmdrop(), not > mmget()/mmput(); you're not allowed to look at the VMA list with an > mmget(), you need to have grabbed. I think it's clear that this would work with the current code and that the concern is about any future possible misuse. So, it would be preferable to proactively prevent such misuse. vma_write_lock() and vma_write_unlock_mm() both have mmap_assert_write_locked(), so they always happen under mmap_lock protection and therefore do not pose any danger. The only issue we need to be careful with is calling vma_read_trylock()/vma_read_unlock() outside of mmap_lock protection while mm is unstable. I don't think doing mmget/mmput inside these functions is called for but maybe some assertions would prevent future misuse?