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 X-Spam-Level: X-Spam-Status: No, score=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6FA40C433DB for ; Fri, 12 Feb 2021 22:51:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 12E7164E08 for ; Fri, 12 Feb 2021 22:51:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 12E7164E08 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8D9A98D00A6; Fri, 12 Feb 2021 17:51:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 887978D0060; Fri, 12 Feb 2021 17:51:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 729AC8D00A6; Fri, 12 Feb 2021 17:51:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0070.hostedemail.com [216.40.44.70]) by kanga.kvack.org (Postfix) with ESMTP id 5943F8D0060 for ; Fri, 12 Feb 2021 17:51:56 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 2252D183F96BE for ; Fri, 12 Feb 2021 22:51:56 +0000 (UTC) X-FDA: 77811115032.22.54C03B6 Received: from mail-il1-f180.google.com (mail-il1-f180.google.com [209.85.166.180]) by imf03.hostedemail.com (Postfix) with ESMTP id 45911C0001F7 for ; Fri, 12 Feb 2021 22:51:54 +0000 (UTC) Received: by mail-il1-f180.google.com with SMTP id e1so698166ilu.0 for ; Fri, 12 Feb 2021 14:51:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CzDlzPzKU3YheI9b/NibUr3Erv08+T00iefc2m4bYp0=; b=Wr+212K+q+ykejSfO/y9AhAJc3j57hC3tdALgV+si3kpw3k2H7yiMirkDqF8javOti riEmedN1Oy/IM2jPVlR/EuOuGaY94jZoBwUo3d4hWk3TEId5RBE6LY0gXh4FOCDVsjTh hUz8UgFAirqegSXWX8/zBc3FI9fUhMAttLB7uHN/s2+bSN5iQUtaEFHMh79qCQ/SWdvX VIN01kyYrEOVrxxgnLx1siMvwRkUwvvZBgjNqsOqQG5BY/n7HqPpm8o8Q15a5/MXwPBH RQ+c9I1kHWYlRwskUJwHY1604M1pux9k0qZm0DkoTfanMnFLr49VaQDd4f2xAmMdSigq fVGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CzDlzPzKU3YheI9b/NibUr3Erv08+T00iefc2m4bYp0=; b=IxlRD1bYdiMIQzf4pWWrn0tGoyApjOQ1e9URPUnXgmPdx9+Ckb6J+AfUXeR6wzH28U U00wP7CWXbCNCrf3zQ8BDrWmDYslUZIXgMaN4srVjVXlRz8CIQiojIZNCFD6szc0Auz5 7XTLHT5bFyIKG/xiTlAnnTyE9mq4Nnk1w27rfEpF7kO1KruZ9kzgpTffgUrBWUMChSpQ /d1LKoCap0OIsAGIyNRpPyYjrzd0cFC/EHH3pJCOJ3TCMhB63sCx3NkeuS48eyn5yuDr 1JA0ry0sjyYvszD0h67xSR5k04+DFUHpOA/JBGSVFsJ3NJvxPUP6ldxhSOwKlzwlOAoj WG+A== X-Gm-Message-State: AOAM532c57mJFCusu7A7e9rpp9ERtNQ+u09BCux5q8b8Q3r36UqgbGdl E/aCSYP3Rj2dRm6o9ORE4M1Kk0Sc6H7sFZRCtvcBBQ== X-Google-Smtp-Source: ABdhPJx4W/jPwkcvJUmsDFbwpNoqSBD2q79ZnTQnQpwYiHcRi7sa3C6YNswuFZ1IosenLe6nyfZr7Y+WuK1axMIwALc= X-Received: by 2002:a05:6e02:194a:: with SMTP id x10mr4196424ilu.165.1613170314792; Fri, 12 Feb 2021 14:51:54 -0800 (PST) MIME-Version: 1.0 References: <20210210212200.1097784-1-axelrasmussen@google.com> <20210210212200.1097784-6-axelrasmussen@google.com> <20210212222145.GB2858050@casper.infradead.org> <20210212224405.GF3171@xz-x1> In-Reply-To: <20210212224405.GF3171@xz-x1> From: Axel Rasmussen Date: Fri, 12 Feb 2021 14:51:17 -0800 Message-ID: Subject: Re: [PATCH v5 05/10] userfaultfd: add minor fault registration mode To: Peter Xu Cc: Matthew Wilcox , Alexander Viro , Alexey Dobriyan , Andrea Arcangeli , Andrew Morton , Anshuman Khandual , Catalin Marinas , Chinwen Chang , Huang Ying , Ingo Molnar , Jann Horn , Jerome Glisse , Lokesh Gidra , Michael Ellerman , =?UTF-8?Q?Michal_Koutn=C3=BD?= , Michel Lespinasse , Mike Kravetz , Mike Rapoport , Nicholas Piggin , Shaohua Li , Shawn Anastasio , Steven Rostedt , Steven Price , Vlastimil Babka , LKML , linux-fsdevel@vger.kernel.org, Linux MM , Adam Ruprecht , Cannon Matthews , "Dr . David Alan Gilbert" , David Rientjes , Mina Almasry , Oliver Upton Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: qhi691hjtmw64ujz1k5t14yu57z7rznc X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 45911C0001F7 Received-SPF: none (google.com>: No applicable sender policy available) receiver=imf03; identity=mailfrom; envelope-from=""; helo=mail-il1-f180.google.com; client-ip=209.85.166.180 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1613170314-612324 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 Fri, Feb 12, 2021 at 2:44 PM Peter Xu wrote: > > On Fri, Feb 12, 2021 at 10:21:45PM +0000, Matthew Wilcox wrote: > > On Thu, Feb 11, 2021 at 11:28:09AM -0800, Axel Rasmussen wrote: > > > Ah, I had added this just after VM_UFFD_WP, without noticing that this > > > would be sharing a bit with VM_LOCKED. That seems like not such a > > > great idea. > > > > > > I don't see another unused bit, and I don't see some other obvious > > > candidate to share with. So, the solution that comes to mind is > > > > it'd be even better if you didn't use the last unused bit for UFFD_WP. > > not sure how feasible that is, but you can see we're really short on > > bits here. > > UFFD_WP is used now for anonymouse already.. And the support for hugetlbfs and > shmem is in rfc stage on the list. > > Is it possible to use CONFIG_ARCH_USES_HIGH_VMA_FLAGS here? So far uffd-wp is > only working for 64 bit x86 too due to enlarged pte space. Maybe we can also > let minor mode to only support 64 bit hosts. At least for my / Google's purposes, I don't care about 32-bit support for this feature. I do care about both x86_64 and arm64, though. So it's a possibility. Alternatively, the "it's an API feature not a registration mode" approach I sent in my v6 also works for me, although it has some drawbacks. Another option is, would it be terrible to add an extra u16 or u32 for UFFD flags to vm_area_struct (say within vm_userfaultfd_ctx)? Historically we've already added a pointer, so maybe an extra say 16 bits isn't so bad? This would avoid using *any* VM_* flags for UFFD, even VM_UFFD_MISSING could be in this new flag field. > > Thanks, > > -- > Peter Xu >