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 1D320EB64DD for ; Thu, 29 Jun 2023 20:01:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AC46B8D0002; Thu, 29 Jun 2023 16:01:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A74558D0001; Thu, 29 Jun 2023 16:01:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 963958D0002; Thu, 29 Jun 2023 16:01:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 871B98D0001 for ; Thu, 29 Jun 2023 16:01:08 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 23615404C5 for ; Thu, 29 Jun 2023 20:01:08 +0000 (UTC) X-FDA: 80956854216.07.7A50FBB Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com [209.85.218.42]) by imf21.hostedemail.com (Postfix) with ESMTP id 919D81C003B for ; Thu, 29 Jun 2023 20:00:55 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=APCoejVb; dmarc=none; spf=pass (imf21.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.42 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=1688068856; 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=fECowZNpcpA0gZRwlMHH3UbCOy7cdW91Ppc09VLxieo=; b=GKoIDp+RWNLwOaMJ805EJZwfC7HyPeQlG0vfsi+CW4S3j8mE+qCiLOhYcG8JDq9x6vBmlo QEX3eKx6rQa8KIYcdA8sNrl8Axrg5gTP/E6QzcghgCOlx9tvcT9Ko5xM9KgQVBieMmZ/Yt 2lF+1EgbPYqh8PHF7NXQlqoj3a5tfmo= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=APCoejVb; dmarc=none; spf=pass (imf21.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.42 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688068856; a=rsa-sha256; cv=none; b=2hM0LqmsWJTS7XxlxucZySiEp8yc13bEa5WocPovhjMMawwrg+/7gZTTUmD1v1m1K7Ii/o NE1K2F20j/1jBLt9kdssC5Q0pNjdkreiE7Z3pRO8KfJHWPJOW2rKvtJb+G/sJrLMAKqS66 gKnISjRSM19D3VpkL4uvHehuDWiovc0= Received: by mail-ej1-f42.google.com with SMTP id a640c23a62f3a-992dcae74e0so7269066b.3 for ; Thu, 29 Jun 2023 13:00:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1688068854; x=1690660854; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=fECowZNpcpA0gZRwlMHH3UbCOy7cdW91Ppc09VLxieo=; b=APCoejVbi7NPMCZ2ZxiifT4LT8K/VyJGzCeCBDfFOHnI5/Jy6Xwp+h76TJGuOJ5aD6 8RimehdJ3vIONWDNXYJeJ9wXiV9KmY+uzqNgh18Qvyl8N4fA2N674gN1VnosnhCOdDmK 4Ewfg7R8FfHvizv0sza1ZAutc5FGL140rBvOI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688068854; x=1690660854; 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=fECowZNpcpA0gZRwlMHH3UbCOy7cdW91Ppc09VLxieo=; b=Ct4TqB1/S/RFV4pEPySRzQokDlDFkjCpYBFAC9VPSvNAaGEp45bYB5RuAgnO/NxlNL GIhk89EC/P/jhC7BVeoh3L87TGP6A/So1eyUM2CD1mMfW0IPrHmpElXsYrB2clZhVEjL hGu4E2OfmhyrkZ7zwgu3gBS7njdHsu3F0bKLf8Cd/UZG7k0GNp2QWuzUL/cU5ZOzmdEi 2tXvLx7s4NgRqqldUvrLCfxm/Gek2PcxJ2ctI9EJ/taIFKXfTRiUwtUkQhMR2ugxty7z pql9wt8j3fiXYwe6RIhISET0+Lj2NvVnbWl3bgspMjvugxMUwfG5ggVnCVSBFAe8XbFf AHgg== X-Gm-Message-State: ABy/qLZNUU+Fzsz7oBg7ek1Hq83i4m6U9/QqHdBLSfoDnbMPdpr5tRO/ 8qMWAFdzST/W3GkUNZUcCatniC6MQ0NdW0R9I9yzZa9H X-Google-Smtp-Source: APBJJlHo434z1L/lWjZMhnt5w8MLziQ8ShIbP+GszrNk2VvMcSa2lVyXpAQ2hB5Jw/FPW75puWJgAw== X-Received: by 2002:a17:906:d9cf:b0:974:32e:7de9 with SMTP id qk15-20020a170906d9cf00b00974032e7de9mr339879ejb.56.1688068854113; Thu, 29 Jun 2023 13:00:54 -0700 (PDT) Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com. [209.85.208.43]) by smtp.gmail.com with ESMTPSA id jt24-20020a170906dfd800b009788554ad10sm7158882ejc.138.2023.06.29.13.00.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jun 2023 13:00:53 -0700 (PDT) Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-51d9850ef09so1233557a12.0 for ; Thu, 29 Jun 2023 13:00:52 -0700 (PDT) X-Received: by 2002:aa7:d7d8:0:b0:51a:5e8f:ac1 with SMTP id e24-20020aa7d7d8000000b0051a5e8f0ac1mr220186eds.23.1688068852598; Thu, 29 Jun 2023 13:00:52 -0700 (PDT) MIME-Version: 1.0 References: <20230629191414.1215929-1-willy@infradead.org> In-Reply-To: <20230629191414.1215929-1-willy@infradead.org> From: Linus Torvalds Date: Thu, 29 Jun 2023 13:00:35 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] mm: Always downgrade mmap_lock if requested To: "Matthew Wilcox (Oracle)" Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Liam R . Howlett" Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 919D81C003B X-Stat-Signature: qpe4dugkksngbik3w5dm1nyxcmt8sk6n X-HE-Tag: 1688068855-254721 X-HE-Meta: U2FsdGVkX18YrKgmp7OqEOCQ8CUxP+V9tSjYpgIyE3R0exkEoDBjSqLnG5Ql28x5pUNCCvrY+jo3+5GuHK+9P4ijOh/EXXjb9gVH77asI7z10joaCarqV7ckeQRc0xS1FBeZ6QASRun2tdmwSVyxUKDyMeAUwCyXUubMVr6fALKAJ5HjjGZ96jOEyDfKzSTWdRNe3AkXqgM8XjT6G24+cdnB1Ok3RN514pR4RO4GzgZQ3LG70A60f4BStGGMmyFElMoMaKyLvmaB9BNOnYgW37ldAKLSQ6//DF35HD0FYQsSN/m1P44exu7P4dN8qkmAfrsIdEhRF3lDinqNNFBJ22iD5/rle0pa12qj5bZ03fQjLs51SsIs6oHIGCUbHx+1zMkYkacti4vT0xqiuBPovWrBV7TF/IsO7ZTZJ65DcMgBnSMqgDvWWKpP5Yb01VA0qsu9XXmj96AxSsKBjWKV1v2E4UHKQDNps/wOmkcBNa3YR0l2jev6sZ8zslfYh+654yXjKsxv8G6nBpUTT90lxPTpw1o+Pi4vvY51wkbVuSEAwq381u7Ycg+pmePfhrQYhFCIUz0BEwSmdIsNN7+4RLQJ7cpdlxqs4rSD0LgCAYUsUD+DRo81QG7vQ1VuBjf+L8Le80Fh+y9XW94inREePn/mW7WzSDl3YLPazx6G9skFut3L2amvW2dIwVY4eEJZNS7pEURVCqmyvHXVfIzH71hzsWqaKJSsnMuIWrKkbo9BZqKhcRnjT+6Z+gMMLe21Ww64b/Urct85KNddTCITiswMbhPsXLDscn5QQkw/km38Tf7BcqkEoMuciqiXENpDpJwLComUhreHKPZpydG+r42KcklISmCkEM0On5eMyTOcI5ELtEl11kOp9q5QvvG0C36dqKyKCBP9le4qakF9XVaw7kZsxm2FD7KqPXQuWzcsllawgfHxZr3YUfzEBwPZoeJH9mZckhYq9qVuAzV Ixq3GwFo NTtx0OTc++T4DBpiZwwZNhHmIsr+ALL7tBUuq0MVEcVl+ouAKssrFL+9iHM9izi2tfFOH9PGVDd2Osde7UKgS02P4nVZCqigUe6jpC9ljwkJRu3wRL/yp+WSQgU6g3oXAAkLeJzG0UJLLkZvEnPwR31itvCFYyShmRwV3bYhFzOAfufVZRwxlEXcpolA0VAPlZjWnb1MfSnpqtmcfA+zo7QHn3nRr0baSlE5icjSJVq78IMjH3+XqAyW9hMkIvcA4UMKYaWZViW7IDJcIcQ1qw6DH4VUiMpmYaHIkcT0dtEYQCeGQ5kDWSsFucP5l3qv1tTZ9eI9QrL8OFoM49JWfyMafmegbN86LD2m8GPYGDqeVF8o96cDvxByd15vAS7Eb4Zl6q1yEp/uVfL45OY+dAmS0b2N3EVCflIIPdCGJXh6chS/kUtzrtlxMqbYYOVN0AlMXA41afY6G2s/ooCwsZxMsPQS1dOwq5dlzzQGrS4HKPc8HZQnZ68OtkRfHmrKbUkBlPJL1dxrumrWKo+G5Tmy9/z6Iza+1zOC+3aWHY4gfkOLDIDax2K5mJGsGabI+JsC7qLSjMq+hpwC9xZiEdY6PKkIMbahzNLAC X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, 29 Jun 2023 at 12:14, Matthew Wilcox (Oracle) wrote: > > Now that stack growth must always hold the mmap_lock for write, we can > always downgrade the mmap_lock to read and safely unmap pages from the > page table, even if we're next to a stack. Can we please also fix the really odd return value semantics? Right now that function returns either an error - meaning that it didn't downgrade, or it returns 0/1 as a success to show "did I downgrade as you asked me to"? That is *really* confusing, but it was needed in that bad old world order. But now that the downgrade is not a "try to downgrade if you can", but something reliable, can we please just make the success case be 0, and make the callers all know that on success, it was downgraded? And yes, I realize that that means do_vmi_munmap() also has to be changed. The documentation for that function is horrid, btw, in that it says * Returns: -EINVAL on failure, 1 on success and unlock, 0 otherwise. which is just not true. It can return other errors than -EINVAL (through exactly that do_vmi_align_munmap() function), and the "1 on success and unlock" is not true, it's a "success and downgrade if you asked me to". So I think all of those callers should also be changed to "if you asked for a downgrade, and do_vmi_munmap() returned success, then you got a downgrade". Then some of the callers of *that* can be simplified too. Please? Linus