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=-18.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=unavailable 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 0A04DC433F5 for ; Tue, 21 Sep 2021 18:26:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AA88360FE6 for ; Tue, 21 Sep 2021 18:26:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org AA88360FE6 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 3252D6B0071; Tue, 21 Sep 2021 14:26:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2D51C6B0072; Tue, 21 Sep 2021 14:26:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1C4986B0073; Tue, 21 Sep 2021 14:26:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0068.hostedemail.com [216.40.44.68]) by kanga.kvack.org (Postfix) with ESMTP id 0E24B6B0071 for ; Tue, 21 Sep 2021 14:26:52 -0400 (EDT) Received: from smtpin35.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id C4E77181FEBB0 for ; Tue, 21 Sep 2021 18:26:51 +0000 (UTC) X-FDA: 78612411822.35.BCE272F Received: from mail-il1-f182.google.com (mail-il1-f182.google.com [209.85.166.182]) by imf04.hostedemail.com (Postfix) with ESMTP id 8A93E50000AD for ; Tue, 21 Sep 2021 18:26:51 +0000 (UTC) Received: by mail-il1-f182.google.com with SMTP id v16so23881125ilg.3 for ; Tue, 21 Sep 2021 11:26:51 -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=aIAwjoyqZOQgLyB/HfPgsMnh+X9W5oz1oq4yBUHKI9E=; b=jzSWPHHWdg6/T2XFMBtYdmEyJq3e/SuFWIfwNR6dmxqZC9edwDT+EqSkSGgOqMN2AL nt+rkZwUeXRAVd+Fr6HYBfuC+/kO7LAq9vtcWmkEuir9IHbq6e511FqFZGHIkmdb/niH q5yt5OJ4S/Aq0Hk28XceO8a3+E0nwJfjweegjZF9n8Y28aYOTuOaWGsfYCLm44tfxLHC LQTmJ0MctJfkaDEk2kik5xAYVZICUHfThX4/4+ngigp/Z9eUYRYXNkoNe/GBJkEZBMgr Q3qyth8UB5xeEtPuVxtOsLkb3VRqWyugedJU40EZJ2ymHo2GdM6FJ9BpOQyvlH21Fh9Z 5Mag== 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=aIAwjoyqZOQgLyB/HfPgsMnh+X9W5oz1oq4yBUHKI9E=; b=fuBU2TJr706+j71Oe4KNofY88nRrLAlhE6NmKSF4hVLOi6kFlJkOiIOYspCIEVmKHV dBZNGhpCuPIGxLgfrMPOfkQD2GOKV3k0/XAg+8rmeoZG7CV8Xd+Ul0AxIcRC3gzbrRLz kdgqkpk3dFCBeoW4OqH5+WJMRCR9Tb2YO55nOYSiDxbMlAvUxucALMLAvgogqGRoCAQI MFoBJ79fumEU/qTEQDkiNPHMT/InPlm/1fPRDOFMXFDJ+PAPd/opXjuwYj1LtqdigYBw Sgf52o+wR1eFH2E2tAh++e2bUy5pjI8N5ldfVszMr6UYk4wAhwl1KvGV5c0u18gbEaN3 x6xw== X-Gm-Message-State: AOAM531RTbYmoFjaruw0Xr6oPjsxFFQH+q9o2hMg5WhTNcf1VLMYx+Mk a87weH8EcdjZjS+CVEi6E3yU9Zk8x8FTQtOU1/C8yQ== X-Google-Smtp-Source: ABdhPJyyGhiWSc0MI8yMRYcV7DheCrh8Ap/YzlNY5R6XZxuT4TFBSl3Eont0d5Knysn/4110iYh0yOL/nwiPFiEYTcQ= X-Received: by 2002:a92:db0b:: with SMTP id b11mr22413467iln.275.1632248810601; Tue, 21 Sep 2021 11:26:50 -0700 (PDT) MIME-Version: 1.0 References: <20210921163323.944352-1-axelrasmussen@google.com> In-Reply-To: From: Axel Rasmussen Date: Tue, 21 Sep 2021 11:26:14 -0700 Message-ID: Subject: Re: [PATCH 1/3] userfaultfd/selftests: fix feature support detection To: Peter Xu Cc: Andrew Morton , Shuah Khan , Linux MM , Linuxkselftest , LKML Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 8A93E50000AD X-Stat-Signature: k8pwcbwmn33nuw7cjj18shnwmwcpiprh Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=jzSWPHHW; spf=pass (imf04.hostedemail.com: domain of axelrasmussen@google.com designates 209.85.166.182 as permitted sender) smtp.mailfrom=axelrasmussen@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1632248811-529384 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000121, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Sep 21, 2021 at 10:44 AM Peter Xu wrote: > > Hi, Axel, > > On Tue, Sep 21, 2021 at 09:33:21AM -0700, Axel Rasmussen wrote: > > diff --git a/tools/testing/selftests/vm/userfaultfd.c b/tools/testing/selftests/vm/userfaultfd.c > > index 10ab56c2484a..2366caf90435 100644 > > --- a/tools/testing/selftests/vm/userfaultfd.c > > +++ b/tools/testing/selftests/vm/userfaultfd.c > > @@ -79,10 +79,6 @@ static int test_type; > > #define ALARM_INTERVAL_SECS 10 > > static volatile bool test_uffdio_copy_eexist = true; > > static volatile bool test_uffdio_zeropage_eexist = true; > > -/* Whether to test uffd write-protection */ > > -static bool test_uffdio_wp = false; > > -/* Whether to test uffd minor faults */ > > -static bool test_uffdio_minor = false; > > IMHO it's not a fault to have these variables; they're still the fastest way to > do branching. It's just that in some cases we should set them to "false" > rather than "true", am I right? > > How about we just set them properly in set_test_type? Say, we can fetch the > feature bits in set_test_type rather than assuming it's only related to the > type of memory. We could do that, but it would require opening a userfaultfd, issuing a UFFDIO_API ioctl, and getting the feature bits in set_test_type. And then I guess just closing the UFFD again, as we aren't yet setting up for any particular test. To me, it seemed "messier" than this approach. Another thing to consider is, for the next patch we don't just want to know "does this kernel support $FEATURE in general?" but also "is $FEATURE supported for this particular memory region I've registered?", and we can't have a single global answer to that. It seemed a bit cleaner to me to write the code as if I was dealing with that case, and then re-use the infrastructure I'd built for patch 2/3. Basically, I didn't initially have a goal of getting rid of these variables, but it ended up being the cleanest way (IMHO). Just trying to explain the thinking. :) In the end, I think it's a stylistic choice and don't feel super strongly about it, either way could work. So, I can change it if you or others do feel strongly. > > Thanks, > > -- > Peter Xu >