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 4DBA9EB64D9 for ; Tue, 4 Jul 2023 13:08:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DA5BF280078; Tue, 4 Jul 2023 09:08:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D527C280076; Tue, 4 Jul 2023 09:08:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C4188280078; Tue, 4 Jul 2023 09:08:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id A947B280076 for ; Tue, 4 Jul 2023 09:08:23 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 42BFCA0496 for ; Tue, 4 Jul 2023 13:08:23 +0000 (UTC) X-FDA: 80973958086.22.B6CB68A Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf16.hostedemail.com (Postfix) with ESMTP id DBBBF180024 for ; Tue, 4 Jul 2023 13:08:20 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="XDy78Ba/"; spf=none (imf16.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688476101; 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=mZ+xBEra3XL2B6MpFYchTvUzUWodFWufoXv8wnmTzzY=; b=ydSWVBVJvsPcQvhz3vdOvcpPtS8UU3G4amSUk2g9sXbCALM31XQVa9yCPIULGIcB5bJq/I s7LCbYRTKAxPDpey+ioO9rDc8XmjMN1MgcID42lYkIm4K1dJqbAvQrJRMNpwaHYaPPHtdq uq1OsKZEPtA/BycHbenxsua13/fZWto= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688476101; a=rsa-sha256; cv=none; b=dtZ82z0YTcreAYDfZ2MXWCjeP1CkBCwDH6grJrWHQ2+0/qSCFDL55BywjEKj4qc7tC7OQR vPdyFPFmlXFWf9EeTtIHD71kcOQc4Vd8UD1CKe8liLQOthKzU3eNq42fSVVYsrEXwG4b+q mxmEEMjyXH2CfcAgq6FcNKvp5cXBA4U= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="XDy78Ba/"; spf=none (imf16.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=mZ+xBEra3XL2B6MpFYchTvUzUWodFWufoXv8wnmTzzY=; b=XDy78Ba/820wKMnshwtlVEdu+4 ccBa5XkQ+lcACaI/ixfPQCjq5+ET5DWnBupS1W3+APanMqccK5OeYJz+Lj1sTPfJLrtuLt3ekm22N pR/LChhgXd6KzYp9071PjwD5OMad7TUbcfP0bow9bkmxrEqByDzl4QLvx3MaHzh0rrRpPTjUTV91V xBr6eAOOmRZzpcSk4H9ylg8sS6K4U2xwyH+vYGnPMjtqvDN0Pumu2alPrgr7uaAyj/fEcl7O4ZrKa 9qDyCUQ4UV83MRnr+xUAm/eQwVOnljGBb4N+X0OCGKTkNLBK3hqOiMnmFl2irekDLqEWk72oSumIj NfhCrPwA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qGfkq-009AR2-DC; Tue, 04 Jul 2023 13:07:40 +0000 Date: Tue, 4 Jul 2023 14:07:40 +0100 From: Matthew Wilcox To: David Hildenbrand Cc: Suren Baghdasaryan , akpm@linux-foundation.org, jirislaby@kernel.org, jacobly.alt@gmail.com, holger@applied-asynchrony.com, michel@lespinasse.org, jglisse@google.com, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, mgorman@techsingularity.net, dave@stgolabs.net, liam.howlett@oracle.com, peterz@infradead.org, ldufour@linux.ibm.com, paulmck@kernel.org, mingo@redhat.com, will@kernel.org, luto@kernel.org, songliubraving@fb.com, peterx@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, chriscli@google.com, axelrasmussen@google.com, joelaf@google.com, minchan@google.com, rppt@kernel.org, jannh@google.com, shakeelb@google.com, tatashin@google.com, edumazet@google.com, gthelen@google.com, linux-mm@kvack.org Subject: Re: [PATCH 1/1] mm: disable CONFIG_PER_VMA_LOCK by default until its fixed Message-ID: References: <20230703182150.2193578-1-surenb@google.com> <7e3f35cc-59b9-bf12-b8b1-4ed78223844a@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: DBBBF180024 X-Rspam-User: X-Stat-Signature: wjftsga1sruffg576u15437dh5q3cqq5 X-Rspamd-Server: rspam03 X-HE-Tag: 1688476100-221530 X-HE-Meta: U2FsdGVkX18/o6oMhYRuuEWulegr23vyuHLqHoSpz02kHwDLqaHDUpXSETp4IXREzDevP5BtgvkNHDKBB3s8P5JONuZ1hHowVAMs9Y06IZQJVHHYZ5tCoSG+lnMahHXfyglgw8TZlr2nUSNCjmCP71nBPEpDpwIWvWQrKh8rp9oJSathwY2j74HHpKsYZbA2QMGj8GR5xebuxF9mM9jfUkRROI32sAIhwFEzkYrtVht4KwWiGIxWeiOP9YFUS/BfAfTWmEbhYlH3ot+nEYzmaST/xudmYhQREN84ZLxAPxzDR2iVhE0EvsOul6AqdFPxogWUdo64WU7F6QWydBF7LdL29OIgodw22yCAVWSaDYFoBpT6+CHHwmtBA6r9RcDFPukQTzaCi4IjVtOt6GUeicrYcCMR4Du4Ri3AntfmKd+uHYIcxDBDmg53uA5budTgQ3nDiTsBX3ZHujPHJSkFp/3tn/77k7FF3G3m19fWWjJ1Ii5xboEExrnTFBZXXTkMhrxu00sABSG/jqG9zcQx8kMsgNGArABhIVrjCtK7u4y/KgX5U2ICx7Cr3Po3HYf9ZeM3J9kycHhD3He2RoFSuEKxYRneqqXiEMtfYscN1qZwpRfqIkuzbKEKG9WPdH9NQ1O9V6VNwmiyVWHZG5yQQ9xQ7H/4xl3pMJY//t/ZsnzMj1twavax6MluZY+mTIxIqXSYflGkPQhrVQRntXebJIM40n9H5Y1gYyQTKjYwQJ5Enemts9QXsvWY3s2jUk8Hze7qZB/P4gG/saNvhxl5LGTzsFmcG/nmjBUtzYgLBZ3vQ46HzoZDhvi0j1Kq0oogHHkcc4qOASopI87CiRznw9yeY4mE6VGsMsEfJrRr38T9w1yEeAQWuUXkPy0mGdY9cgkN0Lw0DuT6bcydYQaq3k4v/mk968ECzi5ob6pRE+QcBxVXeEtafKS3mhuLNvurWf+yrJ3rYguIjBGP8tA P33WMA7b kTffKoxktQcE1DK2THxqIYtMKjsCvvGWcyvVBLcWgYhqNYMVbz2lGS6jRtoS6oQFIHEztRkQrE8+b2k293VXp6N5h2GrhOARF8Eio6et2Ym0dECIzwzao7UGAE3PefoxH2M3oZ2gDN9JnQAiIJlk61ZQCQ8cebz2TSSo29+JaNXtStscTP+teIJGlJfjcztPKGixwX7V1Fe4lrZ/++YaHhaYYihxdojOpGK/9Q0/Xzq2gCfMr8YQaoO4GcjBUD5BQ8jAinzuYOvEoUGPOCNsi2/gbRC6rLQLfwaJG/slSZ1008CS8ReKHgO7RP23e9nFtUkC4LRAouNv9zcbVw01BcYP5he49bMcKuNslk076luxTsTJgTdf08J/XGvAyUF69dA2HxdyOgy021ZYUlcjt5fM4YQ== 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 Tue, Jul 04, 2023 at 09:18:18AM +0200, David Hildenbrand wrote: > > At least the reproducer at > > https://bugzilla.kernel.org/show_bug.cgi?id=217624 is working now. But > > I wonder if that's the best way to fix this. It's surely simple but > > locking every VMA is not free and doing that on every fork might > > regress performance. > > > That would mean that we can possibly still get page faults concurrent to > fork(), on the yet unprocessed part. While that fixes the issue at hand, I > cannot reliably tell if this doesn't mess with some other fork() corner > case. > > I'd suggest write-locking all VMAs upfront, before doing any kind of fork-mm > operation. Just like the old code did. See below. Calling fork() from a multi-threaded program is fraught with danger. It's a rare thing to do, and we don't need to optimise for it. It does, of course, need to not crash. But we can slow it down as much as we want to. Slowing down single-threaded programs calling fork is much less acceptable. https://pubs.opengroup.org/onlinepubs/9699919799/functions/fork.html