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 0062FC74A5B for ; Wed, 29 Mar 2023 17:54:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 49F666B0072; Wed, 29 Mar 2023 13:54:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 44EA26B0074; Wed, 29 Mar 2023 13:54:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3159C6B0075; Wed, 29 Mar 2023 13:54:19 -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 21CD56B0072 for ; Wed, 29 Mar 2023 13:54:19 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id C8E83140B58 for ; Wed, 29 Mar 2023 17:54:18 +0000 (UTC) X-FDA: 80622684996.13.4FD9A0B Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) by imf25.hostedemail.com (Postfix) with ESMTP id F1B5FA0028 for ; Wed, 29 Mar 2023 17:54:16 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=BvTNLj+T; spf=pass (imf25.hostedemail.com: domain of axelrasmussen@google.com designates 209.85.167.43 as permitted sender) smtp.mailfrom=axelrasmussen@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=1680112457; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=j7r474dcwAeSgzFtA0e++9lGH7M7F1P88vLQKvQsNGk=; b=x2sNRmk+zNImMroWbbC/6IhitZFyxMvRxS2JkkPrtc1k07AlW1tLEpnQfCYbSXS3pP7dpc KvJN27arIedp4yPb60uLXSsmWUCS2D1kePpN6fvFFp56xw7M0Anhv7ChwUlrY5hvfnXuop xZVAkpq16To8rWnawTFo+sdcdC5/Glk= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=BvTNLj+T; spf=pass (imf25.hostedemail.com: domain of axelrasmussen@google.com designates 209.85.167.43 as permitted sender) smtp.mailfrom=axelrasmussen@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680112457; a=rsa-sha256; cv=none; b=Gcgrk6TOeUe6k4zdMnNPIDITxCjevQMozFQ6JbP8SV9xSJrEBa34/04aPTo1EclC1jMpSB 2UEMSFoYi6JEuu/EoUls34+OAf9EFBeAlAPWCXT8N3mpEX6TRyPW74Ha+SvJ96FePvX7pD ClghlMOXb4/Nij2PZP5UaDOYbHTGGhY= Received: by mail-lf1-f43.google.com with SMTP id k37so21341877lfv.0 for ; Wed, 29 Mar 2023 10:54:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1680112455; x=1682704455; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=j7r474dcwAeSgzFtA0e++9lGH7M7F1P88vLQKvQsNGk=; b=BvTNLj+T6CPVNp/B17LSyz/YfoU50UfKpT8APVBjmijPPh3VFYJahkylhYlXnIk43Q 6cHt3gQeVzUk7wTQWXdZeGFnVOKnYd453W3FNjOL5XfQEuLFXvXlYTMUAZ5EpIpxIBlJ fDaArvKVjDUgumVb53IEDTLBhZF/oeW78YWaRHFI5pwZKEa4We2ErPZ+LoZ0Vjz940T4 kAjtBW6zReQwLO4VHR+jS19ef74AzyxOc/ftH5A2C/bKM4D032qE+SsBgljcY9ntOfTG pQB7E7k/+is01eN8PhehbkJfo6KvAgVDatZr6icaCIHo2jo2atZLkR6NMRTtgmyzKRGJ f4vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680112455; x=1682704455; h=content-transfer-encoding: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=j7r474dcwAeSgzFtA0e++9lGH7M7F1P88vLQKvQsNGk=; b=4ZZVDmtDJdcPOUYSIyVBKyLasFzJLafjQ1Yxvlcxb1OC5a9Hi/fj9t+aViUgxDJCIb IOXKXrVFVcHFlkWGEdR6KguskqEhp7ooomA7aebGaNEWsColiHpPPQhVPV6zqwb2Qnwv SGB2IVsE0gDMkYYNkoKcPkJHsc6LobayZq/ThUZ2wpTfx8mgeDguZdJ5OC4/SLCjIZl8 FO8kUeR1SRSh6lMkpMcYoeYNElX+CkkwsjaG51zyO6furpetKH5xGi906qIii4YwGeON HoGvybDMy8A7szyjxRklsn+N+9jEgUOt9paPOnMPnFFizcqPkfRy3rSVIZP964+JyH9/ gUZQ== X-Gm-Message-State: AAQBX9ffnBf+L6vi1Naj5uG3/S70BS0lRNBEExa4HVYsh1XyTZYaRm1R s81G33qgsPrb3aFxZMdNA0rjAVXRs6vp1YcasNYclA== X-Google-Smtp-Source: AKy350ZSPh9VmsS6Q/pJBKAbtq5YPvsyHXlILYzOrNSc83L8rkC9PnnTNtcUV7vNWn5zQpAe0CB+yJLGOmLk+fmAX+o= X-Received: by 2002:ac2:55a2:0:b0:4ea:f9d4:93a1 with SMTP id y2-20020ac255a2000000b004eaf9d493a1mr6037484lfg.10.1680112455212; Wed, 29 Mar 2023 10:54:15 -0700 (PDT) MIME-Version: 1.0 References: <20220722201513.1624158-1-axelrasmussen@google.com> In-Reply-To: From: Axel Rasmussen Date: Wed, 29 Mar 2023 10:53:38 -0700 Message-ID: Subject: Re: [PATCH] userfaultfd: don't fail on unrecognized features To: Peter Xu Cc: Alexander Viro , Andrew Morton , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: F1B5FA0028 X-Stat-Signature: kg1qjjqxzu64iqgjcmuozeja67ojotc1 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1680112456-742485 X-HE-Meta: U2FsdGVkX1+kUNwbjtm7kQodjyYBOdtlpPfUZLWHtKodT66S0pWTWDBBgqH8BlCCX8v6hZjlv3zzJlBv1V5HZbQsHodo5IeVS60O9g62WQDluxtfNMQJPnALqwoQ3gBzbEc3UcYUDqDMULm+9Er17OUWB9v4S9xiR0FbfJKObxQWmMOC6dp4fJnV9TBCuzVDxyflzUFRpEa9qYQoGqHVB6UhEyavWW2izqEoaxbiJxQf/iEa53LZqKX9HZhev81m1IBhBRkmJa4aFgZjlMMmjG724iYOhn2DTGee6oPuOUfUMHaJetBsjv1llN8To2aVbOrXgDFith27QMgxq31YXj2m9MACjhtLHwA+483DqXjaSKh3fOMj+i/6ktZ9I6HZ3C5GgNBo86BeUp6CXmPmd1PAqZXMcK51+HkCMRHF9jwLxyFyfrHXglKv5rdEKuootd86gSfxWpHaDUNmHn4nza5GM4iqlehUy5p+IfQmZepmwpI4IMrHHIgxGsu9/+IZoM37L0rK7+q2vxjT7oV6EL7+Ns5uMHJQ/2T9xRymji25Yv8POro02dDkPt+cxaLfNZ1HQ7AyZx+rRHgWxVBNxLefGE1I/25R/cFGb5Rj1k7mNyA+KweYkIQmR+HY89kc7uCgLujjHf67yR+FqMBq74pjL0XYMxS85VOn7yGStuxUIeBB1QVcV5YSVHV/bwI7QNBNPBOogLu6O8/AfrFDxvs/MoqotJYadydOsenYoWhGVrExNFHjKtg8uq0E2VpkywYb10jnYlelZn+MUsgNm1WR8eW2LxeIPwB2fwQ0iVVB7EwLpPgZoGleOOQ3Nt/VPO08a2yM/xa1AzdGxy1LhS06jTK5JFeM5eaUUcO+x9bZhwDtaFUNCG9hOJuwraI4/PXZsgLMez0zxFwnqWyZvgaVPhIwT2yl4x2YSoIXuGBSHsXnpjkMJT0OlZFaFZCmfun27dkRygylkqJ6iOV h5gaeMml Yu63YrTDUrZjP7v0nJhUjYNYSvd1GEwPcl/6VBohmMvYC6y7mL98fhdGYtLiMDNYDr/QtXxj3ePhj8FoL06WZwbu8j+Bc/xPQaWEJmeqGkyK8vvi3COlR1yGymlWWdK9C6h5x7q9lL/l0t6sT+33Sj3fDob8jdGIhTu1e1+LHrCcSYoAGHLOjuOZ43+TcRLZPJIiet1N8G7mkC9t3S+SCi0Dwf+jmrZ4lkcvaLZesPqxNMWoCZZs072Z8dl/wBl3+E7pfdruy7YbXNVd5EhhK6QT+7RJe0czN5Gmgfw1u9tWu2DQ= X-Bogosity: Ham, tests=bogofilter, spamicity=0.001237, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Mar 28, 2023 at 3:34=E2=80=AFPM Peter Xu wrote: > > On Tue, Mar 28, 2023 at 02:52:35PM -0700, Axel Rasmussen wrote: > > I don't see being very strict here as useful. Another example might be > > madvise() - for example trying to MADV_PAGEOUT on a kernel that > > doesn't support it. There is no way the kernel can proceed here, since > > it simply doesn't know how to do what you're asking for. In this case > > an error makes sense. > > IMHO, PAGEOUT is not a great example. I wished we can have a way to prob= e > what madvise() the system supports, and I know many people wanted that to= o. > I even had a feeling that we'll have it some day. > > So now I'm going back to look at this patch assuming I'm reviewing it, I'= m > still not convinced the old API needs changing. > > Userfaultfd allows probing with features=3D0 with/without this patch, so = I > see this patch as something that doesn't bring a direct functional benefi= t, The benefit is we combine probing for features and creating a userfaultfd into a single step, so userspace doesn't have to open + manipulate a userfaultfd twice. In my mind, both approaches achieve the same thing, it's just that one requires extra steps to get there. To me, it's still unclear why there is any harm in supporting the simpler way? And, I also don't see any way in which the more complex way is better? > but some kind of api change due to subjective preferences which I cannot > say right or wrong. Now the patch is already merged. If we need to chan= ge > either this patch or the man page to make them match again, again I'd > prefer we simply revert it to keep everything like before and copy stable= . I think we need to change documentation either way. But, I think the changes needed are actually bigger if we want to revert. With the simpler behavior, the selftest and the example program in the man page are ~correct as-is; otherwise we would need to modify those to use the two-step probing method. (By the way, I am excited about the selftest refactoring you talked about! Thanks for doing that work. It definitely needs it, the complexity there has gotten significantly worse as we've added more things onto it [wp, minor faults].) I think the man page description of how to use the API is incomplete in either case. Right now it sort of alludes to the fact that you can probe with features=3D=3D0, but it doesn't explicitly say "you need to probe first, then close that userfaultfd and open the real one you want to use, with a subset of the features reported in the first step". If we want to keep the old behavior, it should be more explicit about the steps needed to get a userfaultfd. You are right that it also doesn't describe "you can just ask for what you want, and the kernel tells you what subset it can give you; you need to check that the reported features are acceptable" - the new behavior. That should be updated. > > Thanks, > > -- > Peter Xu >