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 2B51AEE49A8 for ; Mon, 21 Aug 2023 05:38:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7F1308D0007; Mon, 21 Aug 2023 01:38:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7A0C78D0001; Mon, 21 Aug 2023 01:38:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6681D8D0007; Mon, 21 Aug 2023 01:38:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 531C68D0001 for ; Mon, 21 Aug 2023 01:38:55 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 2DA301603AA for ; Mon, 21 Aug 2023 05:38:55 +0000 (UTC) X-FDA: 81147007830.03.9FB548F Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com [209.85.218.53]) by imf20.hostedemail.com (Postfix) with ESMTP id 29B961C001A for ; Mon, 21 Aug 2023 05:38:52 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=ehJwUZzc; dmarc=none; spf=pass (imf20.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.53 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692596333; 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=uGZPyjgt3BgZZGLfyFPtYNDWKcSWUwfliXHm1wb3l4U=; b=OQu/rj49zVePMWbImUPfesmqjl0lCpZ8CVzAITmeTOaQF+hn0N0MOiUKOGzLvo1t7vDPbi nGMVQTWMI6PmaKvPFnIzIYoAiIK1nENkUdZy+jxvfSmLoy9LL+95JWiz/fZvwDEjx+8TzX d2sNZLjHUzksQ9L8X2DPHWXsiw7er+Y= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=ehJwUZzc; dmarc=none; spf=pass (imf20.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.53 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692596333; a=rsa-sha256; cv=none; b=wZy5wECtu17vYKVMWwtSHAEJhoDdtXiwwKH0lVl6JH62PSsWNumvqDF58RAV7K7S3oadlu OFbhUX6Tb6opeKEn5sejOqB5+1ZhPqSGQXyXDOMsQuPht+sJb6XGIepjbbsogUjn1aJKur FJOe1GolGvh7wKC5MSmpIaMSktoqhGQ= Received: by mail-ej1-f53.google.com with SMTP id a640c23a62f3a-99c47ef365cso395005366b.0 for ; Sun, 20 Aug 2023 22:38:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1692596331; x=1693201131; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=uGZPyjgt3BgZZGLfyFPtYNDWKcSWUwfliXHm1wb3l4U=; b=ehJwUZzca2pV6VEkA+rwqHDmpWr5R2LeUOhR8f3VQgTuUHlrmjaxZVuj9DtTak+NYl y6A5JEMsOJAKoPWZTJcbjaCIV5uFWH5iqUHlVkLP/gz/pEYR6dEo2OwTwvXmEwyF91j/ AX/eXf7Mv8VZoQrmKu8PcyMuWUm09VuaL5Ux8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692596331; x=1693201131; 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=uGZPyjgt3BgZZGLfyFPtYNDWKcSWUwfliXHm1wb3l4U=; b=b9UrpTHGUinDQlAS3j5r/Ih30jET+2/6/Ix4vXwfhRoEwOgAzyh3VExctWx6t/xjpr YuSOpwsXTXBi+UG0HRk4QthmGGhbd4l/Un9fRZu5TRLpD3nUjWSQMgNVDcu69ogCBi4W 4oXgzKwFK/fpKYdxcS63vLJLeInHlCdAwX6pYJiWywCSHNI9J4HXrRs1AmBhJcBCPZ8N /OL3QxGh0QD3ZwjeeKtqlqvFVdVxAggQiD9ao3vrya1U7k+csi3lH4Td6mkJ3DKZkaMB tmOy8SgTrOeJTa3sNM6nWmft5CDB/G9xThUu4xlOdegTtvjxnPgkcNTGFWKMYt6dJaTh H7ng== X-Gm-Message-State: AOJu0Yz/T6MRb+9BbErTApSR9um1li5PTF0TSn31P+WIEA1TqzK6+u+F gNtqdZX/V3VaLFCCEPI4aJLFn3NCyFrP1eYCyyHv9H/8 X-Google-Smtp-Source: AGHT+IE3Bc48SICvr43EbvFNk41HgecHc7Uptr4Waju0YupVQ2SLexTbpRE/5wDn3Sr+RpbM+eBtbQ== X-Received: by 2002:a17:907:7897:b0:993:f15f:efb7 with SMTP id ku23-20020a170907789700b00993f15fefb7mr4282809ejc.8.1692596331528; Sun, 20 Aug 2023 22:38:51 -0700 (PDT) Received: from mail-ej1-f51.google.com (mail-ej1-f51.google.com. [209.85.218.51]) by smtp.gmail.com with ESMTPSA id i6-20020a170906264600b0099bd1ce18fesm5970115ejc.10.2023.08.20.22.38.49 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 20 Aug 2023 22:38:50 -0700 (PDT) Received: by mail-ej1-f51.google.com with SMTP id a640c23a62f3a-99bf8e5ab39so392082266b.2 for ; Sun, 20 Aug 2023 22:38:49 -0700 (PDT) X-Received: by 2002:a17:907:2721:b0:957:2e48:5657 with SMTP id d1-20020a170907272100b009572e485657mr3737665ejl.68.1692596329546; Sun, 20 Aug 2023 22:38:49 -0700 (PDT) MIME-Version: 1.0 References: <20230820104303.2083444-1-mjguzik@gmail.com> <20230821011303.hoeqjbmjaxajh255@f> In-Reply-To: From: Linus Torvalds Date: Mon, 21 Aug 2023 07:38:32 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] mm: remove unintentional voluntary preemption in get_mmap_lock_carefully To: Matthew Wilcox Cc: Mateusz Guzik , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 29B961C001A X-Stat-Signature: 4kk9tq5emnbd6pt59n36woxd4845mj6y X-Rspam-User: X-HE-Tag: 1692596332-401201 X-HE-Meta: U2FsdGVkX18p2rM4/Dxdq6VqmaRI9IP7ktaw1RSOY0nWJ9vfsSMlwGonACLuuOzVg2H1LsNg7caR2U9/lRXXnMToLmcGK4eUMQN81e/bYtomsGTSLlp4ojlFfyAxezkBgIwSVUMs3Qp7Edsk7ktuv4riq8AK2zh2qxc2iFTajoM/50yfzRfqXErM21ZubCLaz7MxucJdXj7tUWzsdzvVC+zIp85BjUIc2GRB+YEjPIJUb/Y8BHDnWXgTAnctIyMbaHOd6ynqw8s9J1mExkjBjdVYLs35Jy8FMbgxcZGDGPq9t7CSGSf7ryi+9KOx1sDOtIWX3Xebg2WCwT3QhMdxZgsh0opJv+0ZM+w3Y/OWaUusL3TE9+US7wqsFcFeG0GgYUxGZQ95UIZLQLjDUdiyalibP9rH+4ub5mzChs+6lTKul5iG2ae885q/KHYYTCv+4J+IhZVgsH/La8vo9deupu/2DIFxb6cS3TL7JEw7lL7XANhz/EMLDq//+HjBMfY65RjtbbK10mqTnkRzadEuu4R/ZWuYDGwv6emqbYXNyKKBu374gSCUb0aGbzBZ/RgVEVL8wJ0OP3okfXUnrjAhIDx7lc+db00Zt4DogU/iZPlXGYpcXFo7uhG+V1BN8UlyJgUnyhsudZFcMaF6fcrSFZUzn5ghzINNzpXJ3/bSqVdfqYpFZshrxpVwn2X3Ragsz1cg2Q6xWcijOZ9huTwZ+EGgKBj57olFPC7+MmyaiJSbzoGCnp+YI0+OAllvy4Zko8JwuRYoPmydETGxvrgKlcvME2vi49MpU46/tQm3DRw8wFTM0SNAMgGI/ylbMxC7SRZbn9jUCR04aH+KnKjd6e4bM5A5wvqwgSeccuSQHqmyaLQpoZfMSL7d7WoYn6U88Dh6C2XUFfZF5pdZ4zOGXrpXr2603TriI6Cx3/JsvS4qVOktdJA/uhOknhb2JlO3v7LvzbN+Uolg6hAfdsE njdc3Od/ 6t9DN2Ke5dDNRaP67w7Op0fQlHR4ymlkyndxmYhQ2ZYMS+01P0vHXjPd9ajf+757zkJdU608dNf1w/Gt1EUwjvKiGEuDZhcVj66/2o1zLPOYH4wuyKwlOKWaSx6H+tQv0Eelqv8Fh3x9twkZZ7r+xejP5kmlWn/ZnnO9Z08mWO3STEjZ6w6e5BhKagv4hImYIR9s4TGcQWDBICKrRSe3hHDENBKmyKRJzGXCXjVdSH9eI37L3uhGK1ZSC56zwxzTgFdGiT5aehxijoLr4J0p+y6AJu8oQMM/BYC/TmHUNn+vksNl1BOOzyWTrhJdkK+qlbQBMND5Vquua0Kr+qxxNw2ZOQ7UaMqss0eV1nwgaDsr4MNg41tFA35k7RZtuXYRz05LOwQlW2UxyuvGSgwZlGzY9JujPeCM8v2wEK/XgIBYxg1XYw6VjB0qD5Pnv5aBm3aPNEW23d9mHaxq79Kj2aafU1PGxSfLcLLP+TD/OrGoRF6PqaSj9e4JGDN4j6KETdE8oddV0IPEpTk8i72pWqWB23ElMAJ0QDxUOFYRhgHDtjfWKTFNCs30i60i1Iq7XtryLMJJWn6hfQK/q0anaYjUfy54dcpYZteFY 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, 21 Aug 2023 at 06:55, Linus Torvalds wrote: > > I do think that maybe we should then re-introduce the might_sleep() in > some actually appropriate place in the page fault path, which might be > 'handle_mm_fault()'. Just to clarify: if we do it in handle_mm_fault(), we should obviously do it only for kernel faults - just to avoid the unnecessary preemption with lock held for the normal user space case. That said, I don't love the handle_mm_fault() option, I just think it would be lovely if we had that test in a generic place. Sadly, we don't seem to have any such thing other than handle_mm_fault(). The reason we shouldn't do this for user space faults are fine is because not only are they obviously always sleepable, but they also reschedule on return to user space. So neither the debugging nor the preemption makes sense there. That's also why the per-vma locking paths don't need this - we only do per-vma locking for user space faults. So it really is only "kernel faults" it makes sense for, and they are rare enough that I think the preemption point issue might be moot. But it might still be better to just do this all as a special kernel fault case in the exception handler - even if it's then architecture-specific (like it always was before commit c2508ec5a58d). Linus