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 61B67C43334 for ; Wed, 15 Jun 2022 07:26:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EF3C16B0072; Wed, 15 Jun 2022 03:26:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EA3346B0073; Wed, 15 Jun 2022 03:26:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D43DB6B0074; Wed, 15 Jun 2022 03:26:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id C64C96B0072 for ; Wed, 15 Jun 2022 03:26:32 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 8D3F520317 for ; Wed, 15 Jun 2022 07:26:32 +0000 (UTC) X-FDA: 79579637424.20.3A158EE Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by imf24.hostedemail.com (Postfix) with ESMTP id E1B2B18007F for ; Wed, 15 Jun 2022 07:26:31 +0000 (UTC) Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 25F70dDS026230; Wed, 15 Jun 2022 07:26:30 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : content-transfer-encoding : in-reply-to; s=pp1; bh=LfqY7VwyMhzd0tL6ybNibHc8AEladQeT0bE8IPKZW1g=; b=Mr94+g+BaOSA/YX4J1lUUj8WrymE4a6ouhnphoE1/v2di67J+PaYzCxlVbSasrgSB1o+ a9DwByID3zpJJc117LCrEmiQpHebpvGH2QqRkioNwGY8fPyD6Dok4vcxeriMx+ZxA54J B5gkVuebxSZO2dF2z1t0Bb0oXtYtLY2D9iLdKxk6m/EYiXZ4rliFxHIKD/mnJJBmSy/5 q+AyUYmwEoL20QEaj7WDIyrSVMLVzGwYzy0ekMtt3ukwwFCUvcHqVBx2rsHDxK52l4HT Rd+6NRf791O0PC9veGhnrcCotxqfXwqA3QJIjL/FLcLu9qkztsxNjMAihL4+RwXFR7ey BA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3gpp6jad0u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 Jun 2022 07:26:30 +0000 Received: from m0098410.ppops.net (m0098410.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 25F6cUBK021680; Wed, 15 Jun 2022 07:26:29 GMT Received: from ppma06ams.nl.ibm.com (66.31.33a9.ip4.static.sl-reverse.com [169.51.49.102]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3gpp6jacyk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 Jun 2022 07:26:29 +0000 Received: from pps.filterd (ppma06ams.nl.ibm.com [127.0.0.1]) by ppma06ams.nl.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 25F7KWwk031301; Wed, 15 Jun 2022 07:26:27 GMT Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by ppma06ams.nl.ibm.com with ESMTP id 3gmjajdea4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 Jun 2022 07:26:26 +0000 Received: from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com [9.149.105.62]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 25F7QOeK22085974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 15 Jun 2022 07:26:24 GMT Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9C8D7AE045; Wed, 15 Jun 2022 07:26:24 +0000 (GMT) Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id CFFD3AE051; Wed, 15 Jun 2022 07:26:23 +0000 (GMT) Received: from linux.ibm.com (unknown [9.145.33.218]) by d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Wed, 15 Jun 2022 07:26:23 +0000 (GMT) Date: Wed, 15 Jun 2022 10:26:21 +0300 From: Mike Rapoport To: Nadav Amit Cc: John Hubbard , David Hildenbrand , Peter Xu , Linux MM , Mike Kravetz , Hugh Dickins , Andrew Morton , Axel Rasmussen Subject: Re: [PATCH RFC] userfaultfd: introduce UFFDIO_COPY_MODE_YOUNG Message-ID: 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0BB58ACF-2801-4622-BF3B-9913A23AE46C@gmail.com> X-TM-AS-GCONF: 00 X-Proofpoint-GUID: y5_VlN0d_thptM-ikjOXuoM6dXf-I3jt X-Proofpoint-ORIG-GUID: lO82D7sgMP_folF-m1qz0vRZvO_ac4yQ X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.874,Hydra:6.0.517,FMLib:17.11.64.514 definitions=2022-06-15_03,2022-06-13_01,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 bulkscore=0 lowpriorityscore=0 priorityscore=1501 clxscore=1011 adultscore=0 mlxlogscore=669 malwarescore=0 spamscore=0 phishscore=0 suspectscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2204290000 definitions=main-2206150024 ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655277992; a=rsa-sha256; cv=none; b=FVYrf4zm54XZ+ProbBWAhIMA5bYNbPhVMKD2mMU3+f+o3aTlfga2UWIwRwyjLzJBuCobZk aIXKJ3z55x0EeTsxPAcBK5q6CD/kfZdFHc/sVAX6wq7/ptaHHi4dDut4vlJnsiswQsIUR8 xBXvquxVKjOpxKrHcwFFMaq7H4kHrG0= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655277992; 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=LfqY7VwyMhzd0tL6ybNibHc8AEladQeT0bE8IPKZW1g=; b=kCfllcGGdKOVkWnMco3NMyhroAOpTXYTDPamCWU4wCeO+/HmvYkfRVb5i6GVwuFCt8SiLt Qq3p8w2ySahEzJ9RpUEFiNINO9GLNDBcYlgPU7jxCCdPNoGbraHtMPOmTGs0JgX0EGSCKF +FL2HkAuvbPA9p1igzmRCW7a3ANfI/4= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=Mr94+g+B; dmarc=pass (policy=none) header.from=ibm.com; spf=pass (imf24.hostedemail.com: domain of rppt@linux.ibm.com designates 148.163.156.1 as permitted sender) smtp.mailfrom=rppt@linux.ibm.com Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=Mr94+g+B; dmarc=pass (policy=none) header.from=ibm.com; spf=pass (imf24.hostedemail.com: domain of rppt@linux.ibm.com designates 148.163.156.1 as permitted sender) smtp.mailfrom=rppt@linux.ibm.com X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: E1B2B18007F X-Stat-Signature: s8kqhe61e7po8e43ober3hnyp417h7qu X-HE-Tag: 1655277991-142375 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 Tue, Jun 14, 2022 at 01:56:56PM -0700, Nadav Amit wrote: > On Jun 14, 2022, at 1:40 PM, John Hubbard wrote: > > > On 6/14/22 11:56, Mike Rapoport wrote: > >>> But, I cannot take it anymore: the list of arguments for uffd stuff is > >>> crazy. I would like to collect all the possible arguments that are used for > >>> uffd operation into some “struct uffd_op”. > >> Squashing boolean parameters into int flags will also reduce the insane > >> amount of parameters. No strong feelings though. > >> > > > > Just a quick drive-by comment about boolean arguments: they ruin the > > readability of the call sites. In practice, sometimes a single boolean > > argument can be OK-ish (still poor to read at the call site, but easier > > to code initially), but once you get past one boolean argument in the > > function, readability is hopeless: > > > > foo(ptr, true, false, a == b); > > > > 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 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. mfill_atomic_install_pte() is called by shmem_mfill_atomic_pte() so it's not entirely internal to mm/userfaultfd.c. Another thing is that with all the parameters packed into a struct, the call sites could become really hairy, so maybe the best way would be to pack some of the parameters and leave the others. But you'll never know until you try :) -- Sincerely yours, Mike.