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 D9717C43334 for ; Thu, 23 Jun 2022 22:05:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 66C638E0198; Thu, 23 Jun 2022 18:05:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 61A388E0192; Thu, 23 Jun 2022 18:05:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4E2878E0198; Thu, 23 Jun 2022 18:05:11 -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 3E3038E0192 for ; Thu, 23 Jun 2022 18:05:11 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 09B2A35321 for ; Thu, 23 Jun 2022 22:05:11 +0000 (UTC) X-FDA: 79610882022.12.5B1DBCA Received: from mail-pj1-f52.google.com (mail-pj1-f52.google.com [209.85.216.52]) by imf20.hostedemail.com (Postfix) with ESMTP id 8D9E51C001D for ; Thu, 23 Jun 2022 22:05:10 +0000 (UTC) Received: by mail-pj1-f52.google.com with SMTP id 73-20020a17090a0fcf00b001eaee69f600so952091pjz.1 for ; Thu, 23 Jun 2022 15:05:10 -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=gTHQlOEXgglUiLQvY4aL+dxZSfCB2NBv8453k+b3FaU=; b=eBDlUiXgRzkn647UZssZqriJO8qk4zY3yM6YrdFocTPIZmLooHOttexMdV6EOEc/37 735sh8st/3o0TYVzBWeWwXKj9R0PY3P5MeSk2t0F1jO/ulfoTVKhvJ3gySpxSndoIign 9a0pj7rHEp23WsOJ9BgRtiUvTdVErhZopx/cop14jroIH6qW2hWQ23VtXMbgtwkQG/Rd Ij9VUQH4Zp1H8vA0LfMzYnc2XrbxgcxSc0M36JTmd2V0qZrI4B5YAsavMbgO+HT7L2xj 4bpdoxKLQ7abl9DmpTy1IChRyTa00hF0iAhGqtUCMLSbcGJz87gVc5yCmjcAZSE5leqm cVNA== 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=gTHQlOEXgglUiLQvY4aL+dxZSfCB2NBv8453k+b3FaU=; b=uHhZA9+BFB2Zuj1ynsuagAYfUo/3c7IM7y7gXAGKhduqLFB6l0lqK4Y9E+3fuVpB4O ZuHx1B8Df2pPDJk8GxKqQWM1QRrEzHqOJJ5bdcGSN5KHAagEG5TcZwL91RiupqVAV3Zk nvbYXLW8/fV7aPCXH/TK1DANra71OhKFjcgvzMVTpHZP83v5Kdev0MFxnxAowT/LVtuC h8rb2P+Wz0FnGm1oftcLp+VHI8aS1N2jqNB7PoPKIZk3fivxhDb0bHjB/1oUznloCRAd c1VgHR0QhMEvbfaZ70ljIyADV1634b9lnc6Pit4tISZaIRnlfJ+EUKUOegqS/FQYIbq/ KPRQ== X-Gm-Message-State: AJIora8OZjtteBoqcntM2s0cUn10/A8zmr4GoJpYBWhBXm4nD1yHyZBg I1Ud8nPhdlsDIf7C6fqyO5svmkq6V/tRJA== X-Google-Smtp-Source: AGRyM1sXhJqZfunsMdIL4YV5urWf82US34jrDnABWbLwulZd/nsR1x0rYXkEYYIIlQo73D24DOjuFA== X-Received: by 2002:a17:903:32c6:b0:16a:124c:9df with SMTP id i6-20020a17090332c600b0016a124c09dfmr27824773plr.126.1656021909257; Thu, 23 Jun 2022 15:05:09 -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 h13-20020a170902f7cd00b001651562eb16sm279926plw.124.2022.06.23.15.04.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jun 2022 15:04:45 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Subject: Re: [PATCH v1 1/5] userfaultfd: introduce uffd_flags From: Nadav Amit In-Reply-To: Date: Thu, 23 Jun 2022 15:04:27 -0700 Cc: Linux MM , Mike Kravetz , Hugh Dickins , Andrew Morton , Axel Rasmussen , Mike Rapoport , David Hildenbrand Content-Transfer-Encoding: quoted-printable Message-Id: References: <20220622185038.71740-1-namit@vmware.com> <20220622185038.71740-2-namit@vmware.com> To: Peter Xu X-Mailer: Apple Mail (2.3696.100.31) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656021910; 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=gTHQlOEXgglUiLQvY4aL+dxZSfCB2NBv8453k+b3FaU=; b=3Xsc3XMisKu1sXDbDaxs5bDSIdQL0azVgn/SmCIC/HIsCr1NHuNYRzzyObx6VnwyH8V+fS FKlJXOs0D3L90hZsLnTMmwjj6dnXXOAGr4iGz9NGuOZ8975NVJyDO28624rl9emHyVg7UB vQ8JTmFTAQKEPw7CnxXNDVUtVxxfK5s= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656021910; a=rsa-sha256; cv=none; b=vJNGsCyXcdKxaPwXaqpidONU/m4dXxIXjyhq+zuI6GWnq4JyHkj6/yNOGaaDzMfIt6bS/c 0ivwoS7aNETJKZzaYEbfP1A30gk2dyjQgWO3omRDy/ve7SrDozd1/e0++KT6suWl8n/3KF RF0k/k8tE5ANYbYMXiMPVe0kCIufBwo= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=eBDlUiXg; spf=pass (imf20.hostedemail.com: domain of nadav.amit@gmail.com designates 209.85.216.52 as permitted sender) smtp.mailfrom=nadav.amit@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspam-User: Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=eBDlUiXg; spf=pass (imf20.hostedemail.com: domain of nadav.amit@gmail.com designates 209.85.216.52 as permitted sender) smtp.mailfrom=nadav.amit@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 8D9E51C001D X-Stat-Signature: pbrejp8rga6ii1m44z9eruxtdac9ukuf X-HE-Tag: 1656021910-417143 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 Jun 23, 2022, at 2:57 PM, Peter Xu wrote: > On Wed, Jun 22, 2022 at 11:50:34AM -0700, Nadav Amit wrote: >> @@ -1891,7 +1902,7 @@ static int userfaultfd_continue(struct = userfaultfd_ctx *ctx, unsigned long arg) >> if (mmget_not_zero(ctx->mm)) { >> ret =3D mcopy_continue(ctx->mm, = uffdio_continue.range.start, >> uffdio_continue.range.len, >> - &ctx->mmap_changing); >> + &ctx->mmap_changing, 0); >=20 > Shall we consistently use either 0 or UFFD_FLAGS_NONE? I'd go for 0 > directly since that's clearer on having "nothing" as flag. >=20 >> mmput(ctx->mm); >> } else { >> return -ESRCH; >=20 > [...] >=20 >> ssize_t mfill_zeropage(struct mm_struct *dst_mm, unsigned long start, >> - unsigned long len, atomic_t *mmap_changing) >> + unsigned long len, atomic_t *mmap_changing, >> + uffd_flags_t uffd_flags) >> { >> return __mcopy_atomic(dst_mm, start, 0, len, = MCOPY_ATOMIC_ZEROPAGE, >> mmap_changing, 0); >=20 > I think you agreed on passing the uffd_flags into __mcopy_atomic() = (and > also below). Is it forgotten or plan changed? I addressed these issues in the following patches - I messed up slightly = the patch order. I will address these two into patch 1. Regards, Nadav=