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 D3748C43334 for ; Tue, 14 Jun 2022 21:52:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 435906B0071; Tue, 14 Jun 2022 17:52:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3E4EB6B0072; Tue, 14 Jun 2022 17:52:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2857C6B0073; Tue, 14 Jun 2022 17:52:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 181556B0071 for ; Tue, 14 Jun 2022 17:52:46 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id E49E02EA for ; Tue, 14 Jun 2022 21:52:45 +0000 (UTC) X-FDA: 79578191490.20.0157BFF Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) by imf04.hostedemail.com (Postfix) with ESMTP id 8A77240089 for ; Tue, 14 Jun 2022 21:52:45 +0000 (UTC) Received: by mail-pl1-f179.google.com with SMTP id g8so3641243plt.8 for ; Tue, 14 Jun 2022 14:52:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bwiFFB7SW4LaUYyTTnC9uJje9j4nk1HdH3NM9lLaz6U=; b=YTqcUbAdLvpE2UPjGl5USBLpJ6GRc8HSmGfnioWW16fBKw4NxxRt3TBmO41J8KaZgL 58VdfIulLSsePWQBFwVjWQ+0rwxVsqIqW5NQVgg1aELM9Syj3W+W6O0LnKrMdAOTLGFC suEciKrhavgSurHevUt8yH8qTrLK/0sGgjbFE9wcmqEYlVHSJKE/vmGD5xg45wPitNwk f7vl7FhQTat9HkGTv8fy59vp4GRtYG614QR7I25ka3vso2bXUVAZ0mpn4PIEdIvjUK3M jkb3j1IAO5bcZ3JCC7XElDiBLtiiR6zG6inxnNivT1cGgGKWjPUBn7KqcKwJL7bLD2Rq 7kEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bwiFFB7SW4LaUYyTTnC9uJje9j4nk1HdH3NM9lLaz6U=; b=50R8ESyTv3jX92MJqJSF7Kd1M+q6V7hMRvw97JYBjccW/N+k1oKbsMeeYFd3Mz82p9 78+gcgc0Mw2kdvtjucIYUAaE4qRy6+bj21jPHIEpCulgUfY1pXq+eWkfgUG+GM2vr/V1 JqnFdkKyZat5zjjDDrkW20aiyh1iOhPy/0NxdDUw4zpBI6pXk7xaaZX5jMs2F691KvRS w2MroyRq482eQprqLmtw+vjUhRJCB55bxBG0ES0MHVYCbZinwlKUwLYCztnAGL6qoie1 UiZ/ly+smx02WFWARMhSOjVz4GWcLfwmfQafOtKp2uLhlbl2xSo0pMrxmx+5tltaexb8 5Tyw== X-Gm-Message-State: AJIora9C9VFuZXx45c3to483zDt7QFytXKR1lDscdtcIIxmaM1/lHjrx sy1hVR1UZ3WpBMkMzdrIyQ4= X-Google-Smtp-Source: AGRyM1tbo/iaEa+e6BJXz6l49T3ALLPHHPepyRaykpr52DyU0i0yIqwTxXNXCT2TtgGb1jfcU/SNug== X-Received: by 2002:a17:90a:e388:b0:1ea:d46e:77c5 with SMTP id b8-20020a17090ae38800b001ead46e77c5mr502890pjz.157.1655243564278; Tue, 14 Jun 2022 14:52:44 -0700 (PDT) Received: from smtpclient.apple (c-24-6-216-183.hsd1.ca.comcast.net. [24.6.216.183]) by smtp.gmail.com with ESMTPSA id k92-20020a17090a14e500b001ead2406552sm68905pja.46.2022.06.14.14.52.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Jun 2022 14:52:43 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Subject: Re: [PATCH RFC] userfaultfd: introduce UFFDIO_COPY_MODE_YOUNG From: Nadav Amit In-Reply-To: Date: Tue, 14 Jun 2022 14:52:42 -0700 Cc: Mike Rapoport , David Hildenbrand , Peter Xu , Linux MM , Mike Kravetz , Hugh Dickins , Andrew Morton , Axel Rasmussen Content-Transfer-Encoding: quoted-printable Message-Id: <555DA48F-F297-4354-987D-9030688B0E0A@gmail.com> References: <20220613204043.98432-1-namit@vmware.com> <3eea2e6e-1646-546a-d9ef-d30052c00c7d@redhat.com> <481fc9d0-6122-bf59-9d04-23c10d256764@nvidia.com> <0BB58ACF-2801-4622-BF3B-9913A23AE46C@gmail.com> To: John Hubbard X-Mailer: Apple Mail (2.3696.100.31) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655243565; a=rsa-sha256; cv=none; b=Keqkya2n/y/DQEkTz4XjQWvwLatvA+tGimMobEUxmfTqLvD8YjSvUU7e/+rNg9mwoz3dbo HhUfeIjKDuDiFzyGX6VjNFlk15ZflD+hqXiHNhDAuGe24TqwNaoBtacEbypfoJoyfaPP1v /F8pVwOoBAnDHzjUi+1ZFHEAVju7Lgs= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=YTqcUbAd; spf=pass (imf04.hostedemail.com: domain of nadav.amit@gmail.com designates 209.85.214.179 as permitted sender) smtp.mailfrom=nadav.amit@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655243565; 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=bwiFFB7SW4LaUYyTTnC9uJje9j4nk1HdH3NM9lLaz6U=; b=JMyoRdUDWqY6VT9MPvqmHQSwXETJ5v42go3cPYwsoistg5rFCU5yMIOCI9EcKFIQDjHLES SsbcNvVFnMdLgVEpldjegXv3UfZvxmVi5YQDnAHCqDVhgrzaBVacz2aV98Y7pbeZGehTLc tSRFNcXGDM8Mr2Jbq7eUk6TjpLiW364= X-Stat-Signature: 3eru1eyauh3cz1ei4tk6s3ekhomrcemx X-Rspamd-Queue-Id: 8A77240089 Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=YTqcUbAd; spf=pass (imf04.hostedemail.com: domain of nadav.amit@gmail.com designates 209.85.214.179 as permitted sender) smtp.mailfrom=nadav.amit@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspam-User: X-Rspamd-Server: rspam02 X-HE-Tag: 1655243565-270280 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000010, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Jun 14, 2022, at 2:40 PM, John Hubbard wrote: > On 6/14/22 13:56, Nadav Amit wrote: > ... >>> So if you have a choice, I implore you to prefer flags and/or enums. = :) >> Thanks for the feedback - I am aware it is very confusing to have = booleans >> and especially multiple ones in a func call. >> Just not sure how it maps to what I proposed. I thought of passing as = an >> argument reference (pointer) to something similar to the following = struct, >> which I think is very self-descriptive: >> struct uffd_op { >> /* various fields */ >> struct vm_area_struct *dst_vma; >> unsigned long len; >> atomic_t *mmap_changing; >> ... >> =09 >> /* ... and some flags */ >> int wp: 1; >> int zero: 1; >> int read_likely: 1; >=20 > I am more accustomed to seeing: > unsigned int flags; >=20 > ...and then some #defines or enums nearby that are used for .flags. > The bitfields are not used as much, Linus wrote some words about why, > (which I'm not hopeful I can find). Basically they are not a very > robust C feature, and the kernel has good support for dealing with > flags within a word. >=20 Yes, Linus wrote some harsh words about it to me specifically. But my understanding was the he opposes to the use of bitfields if they are = only used for flags. In this case it is not only flags, so there are not problems, for instance in initialization of parameter. There are many instances for such use (e.g., tcp_options_received).. >> ... >> }; >> I think that fits what you were asking for. The only thing I am not = sure of, >> is whether to include in uffd_op fields that are internal to = mm/userfaultfd >> such as =E2=80=9Cpage=E2=80=9D and =E2=80=9Cnewly_allocated=E2=80=9D. = I guess not. >=20 > Actually, I think passing around a struct might be overkill, when you = can > simply collapse the various boolean args into a single flags arg. It = looked > like a lot of the new args were bools... Ok. Whatever you prefer. I thought that having something similar to = =E2=80=9Cstruct vm_fault=E2=80=9D makes sense, especially since it would allow to avoid = propagating ugly arguments like mmap_changing. But I do not care enough to argue.=