linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Nadav Amit <nadav.amit@gmail.com>
To: John Hubbard <jhubbard@nvidia.com>
Cc: Mike Rapoport <rppt@linux.ibm.com>,
	David Hildenbrand <david@redhat.com>,
	Peter Xu <peterx@redhat.com>, Linux MM <linux-mm@kvack.org>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	Hugh Dickins <hughd@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Axel Rasmussen <axelrasmussen@google.com>
Subject: Re: [PATCH RFC] userfaultfd: introduce UFFDIO_COPY_MODE_YOUNG
Date: Tue, 14 Jun 2022 14:52:42 -0700	[thread overview]
Message-ID: <555DA48F-F297-4354-987D-9030688B0E0A@gmail.com> (raw)
In-Reply-To: <be5db25b-b5c9-a660-6c33-bd409de1c469@nvidia.com>

On Jun 14, 2022, at 2:40 PM, John Hubbard <jhubbard@nvidia.com> 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;
>> 	...
>> 	
>> 	/* ... and some flags */
>> 	int wp: 1;
>> 	int zero: 1;
>> 	int read_likely: 1;
> 
> I am more accustomed to seeing:
> 	unsigned int flags;
> 
> ...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.
> 

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 “page” and “newly_allocated”. I guess not.
> 
> 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 “struct
vm_fault” makes sense, especially since it would allow to avoid propagating
ugly arguments like mmap_changing. But I do not care enough to argue.

  reply	other threads:[~2022-06-14 21:52 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-13 20:40 Nadav Amit
2022-06-14 15:22 ` David Hildenbrand
2022-06-14 16:18   ` Nadav Amit
2022-06-14 17:14     ` David Hildenbrand
2022-06-14 18:56     ` Mike Rapoport
2022-06-14 19:25       ` Nadav Amit
2022-06-14 20:40       ` John Hubbard
2022-06-14 20:56         ` Nadav Amit
2022-06-14 21:40           ` John Hubbard
2022-06-14 21:52             ` Nadav Amit [this message]
2022-06-14 21:59               ` John Hubbard
2022-06-15  7:26           ` Mike Rapoport
2022-06-15 15:43             ` Peter Xu
2022-06-15 16:58               ` Nadav Amit
2022-06-15 18:39                 ` Peter Xu
2022-06-15 19:42                   ` Nadav Amit
2022-06-15 20:56                     ` Peter Xu
2022-06-16  5:24                       ` Nadav Amit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=555DA48F-F297-4354-987D-9030688B0E0A@gmail.com \
    --to=nadav.amit@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=axelrasmussen@google.com \
    --cc=david@redhat.com \
    --cc=hughd@google.com \
    --cc=jhubbard@nvidia.com \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=peterx@redhat.com \
    --cc=rppt@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox