Received: by 2002:a05:6602:2086:0:0:0:0 with SMTP id a6csp4379430ioa; Wed, 27 Apr 2022 02:28:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJynYhelOkvea0HDCYNsJQhxf86XS2skOXEWZDge4ZXSlzeuqRa5OgnR0GM3ltgKNb++mwYp X-Received: by 2002:a05:6a00:b54:b0:50d:5998:6dcb with SMTP id p20-20020a056a000b5400b0050d59986dcbmr7770307pfo.19.1651051681183; Wed, 27 Apr 2022 02:28:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651051681; cv=none; d=google.com; s=arc-20160816; b=nFiVsGQ0Gg3btVKmGNlNmdkHM4H+BXPws5TGJU3Cm0VnkzMOy2LuCc2wVAD3k/jYEc Xc8urGp3mcc8lcDRsi7uwQJaRTZbBt23fsgjOvx+HSnSNnO2K/LjWiJDj3alLJjvK974 uHbWMBwyO/wzJYOgU9phmELt4UcMEWh/0mkyO4xgqbXrjBGGkQExVi9mNJMgeQ5Gn3w5 te/QE2HJM6SSOfL7iYkOZER7IwCOHIm4sy7rJLeXSerw7g8ytJXw72tYaqjo1pe9kNUj 5CP80n88U8YubZMPr+zE8CnixFW8lBrOhdqPjVojs0SxNgi/zgy9FTW4d5XAbIhPMX47 JD8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=zJHneikLXEGfJde4krQasd9PQhsFRpApoS4ZRag7+RU=; b=jVvSeKt4q0hbXYGFBoXOXqtZFGdk3XIffN7MpfirFpdoGopsSWzInzmtr3TLBolI2q TnT1zSXlCDWvcUFKeU05hZY0R0T8E+ly4EYoQLhcCVaM5drkBVvRsjY4+rAwT7Bd1HnN zKT/xzy/GeGhps2bm1Fh0Si8vmxLBeXMgQJL2hVJQkddQKHKuDdT5PAkhU7R5tSTphjd GnApbQeyMBtgvJdq7fq0b9PNnrBprTCC2bN4VbdSQQUw4EP5B4Nao3rCrFQKp1+JU/qF ccIUJc54gCVg/PCpw5fMS91iO2N4vcFUNntXH7gBXCo2jDYqzKx0ZqhflWVz02hMF3pP ypHQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="EdwxR0V/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id q18-20020a056a00089200b004fa3a8e00b1si891229pfj.360.2022.04.27.02.28.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Apr 2022 02:28:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="EdwxR0V/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id C9C691668CC; Wed, 27 Apr 2022 02:10:38 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242656AbiDZVhP (ORCPT + 99 others); Tue, 26 Apr 2022 17:37:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54694 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346480AbiDZVhN (ORCPT ); Tue, 26 Apr 2022 17:37:13 -0400 Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7811B1A5DD1 for ; Tue, 26 Apr 2022 14:34:04 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id h8so203285iov.12 for ; Tue, 26 Apr 2022 14:34:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zJHneikLXEGfJde4krQasd9PQhsFRpApoS4ZRag7+RU=; b=EdwxR0V/0R58E5VQDj0HrytGDcfRa0ZaI7Me6rDBjirAgNHRbWWWvGaw7HmQEIGzu+ 8UTTpBJpVmtohKiGL5cVYIq8PicWJvFUQVly2vSP4TS+56W86k/aX6l5WCrdoFzyILM+ 1Yehf40AqvUszrZodWCBswvT50v8vrsYb0CT9VT0ik1assb3s50rjI/Ghc6ERMC0+hQS kngQQpUrenrx0Z/CG7kuYI7vOHHB9pxCvklytawOfmTdu9cTLRddizluzNirEjBtvgHq /7wjZvrPSoiAuTCiyBqcBwBGz7SjzYicglmkQ0p2ZcHJZmj17y1/IkCZAoejAg68UMHJ xOsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zJHneikLXEGfJde4krQasd9PQhsFRpApoS4ZRag7+RU=; b=Q5QFQj4dxDIG6cf96TDDZ5+F2QYB1kxwsrhABAnl0j1PVcdrhp8RSezTmQEkDs6b5D yEke2c737a9BkozNhGWq+um6og4bOAlQdP9dAfia9VB2A6Xgj6f/jd7EM0eygzR/D2md dmHFX2k7Mj/2xf9qQfvHs53/qpFOLb1/zKyxEV+kq7T5hAH7hASOkHgBGIFtYCJcnbxs CJ0CKybUj+ppjrX8aNuLW7Z7KlGLkT9zJkT2oi2tmElGbQ0a3HqQdf06suQkVyzNmVx2 x9ud7z2Kk848BNm2ET6b624Ay6frvhjYuN08NNoqC5Q4oFpodFcCEyD26vN/5E/JsGFJ LawQ== X-Gm-Message-State: AOAM531gOpLvITMdDCchWPYUA7O/1r3dtUl3aV53D0Qs7iULnOPD24+S 3utShs+/n2mVRSbrhBQhBipE6ek7KgmkS177xokT/EPE7DA= X-Received: by 2002:a5d:9448:0:b0:657:24e0:c0b2 with SMTP id x8-20020a5d9448000000b0065724e0c0b2mr10388348ior.167.1651008843696; Tue, 26 Apr 2022 14:34:03 -0700 (PDT) MIME-Version: 1.0 References: <20220422212945.2227722-1-axelrasmussen@google.com> <20220422212945.2227722-3-axelrasmussen@google.com> In-Reply-To: From: Axel Rasmussen Date: Tue, 26 Apr 2022 14:33:27 -0700 Message-ID: Subject: Re: [PATCH v2 2/6] userfaultfd: add /dev/userfaultfd for fine grained access control To: Peter Xu Cc: Alexander Viro , Andrew Morton , Charan Teja Reddy , Dave Hansen , "Dmitry V . Levin" , Gleb Fotengauer-Malinovskiy , Hugh Dickins , Jan Kara , Jonathan Corbet , Mel Gorman , Mike Kravetz , Mike Rapoport , Nadav Amit , Shuah Khan , Suren Baghdasaryan , Vlastimil Babka , zhangyi , linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, LKML , Linux MM , Linuxkselftest Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.5 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 26, 2022 at 1:33 PM Peter Xu wrote: > > Axel, > > On Fri, Apr 22, 2022 at 02:29:41PM -0700, Axel Rasmussen wrote: > > @@ -65,6 +66,8 @@ struct userfaultfd_ctx { > > unsigned int flags; > > /* features requested from the userspace */ > > unsigned int features; > > + /* whether or not to handle kernel faults */ > > + bool handle_kernel_faults; > > Could you help explain why we need this bool? I failed to figure out > myself on the difference against "!(ctx->flags & UFFD_USER_MODE_ONLY)". Ah, yeah you're right, we can get rid of it and just rely on UFFD_USER_MODE_ONLY. Just to add context, in a previous version I never sent out, I had: ctx->handle_kernel_faults = userfaultfd_allowed(...); That's wrong for other reasons, but if we were going to do that we'd have to store the result, since it's a function not just of the flags, but also of the method used to create the userfaultfd. I changed this without also dropping the boolean, which can now be cleaned up. I'll include this change in a v3. > > Thanks, > > -- > Peter Xu >