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 6E9EAC76196 for ; Mon, 3 Apr 2023 19:06:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A4F8B6B0072; Mon, 3 Apr 2023 15:06:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A0AD46B0074; Mon, 3 Apr 2023 15:06:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8A04F6B0075; Mon, 3 Apr 2023 15:06:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 7A96D6B0072 for ; Mon, 3 Apr 2023 15:06:34 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 26AA9AB725 for ; Mon, 3 Apr 2023 19:06:34 +0000 (UTC) X-FDA: 80641011108.29.23105E8 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf23.hostedemail.com (Postfix) with ESMTP id 918D4140009 for ; Mon, 3 Apr 2023 19:06:31 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=O464Thtg; spf=pass (imf23.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680548792; 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=o312F+8qQ3csr6xoClPXHStqrqRF/NPJb7KBcI61xtc=; b=3b6yNYo2UdrDZFE6JaQnChmgfFYCOBskNxTPa3/btDsI0t2l3WZnFMP98dZ+G2EO73N1pe sY9D1R9Hlqax/FL1DoNFJ/9ZASwc2ajYA7j7I8ctFPGPS2TXu2Yt9z2v3QpLJ2tfOdbIv/ 3s5f8I1UBVI17aw5WSjn4xvYkm9GLYo= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=O464Thtg; spf=pass (imf23.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680548792; a=rsa-sha256; cv=none; b=My7eFiCVxR2xGEt728xu6SEz5ytzuOjMm+/ClafkQ0eRel2X01ca2nXG65nO0Q9SuuZHKb FmQSTvwrYyjSXxuBLYmBhCGJaJjAtAUF1ascTQjuuRcFkTCOeKfCHPDtdxr0jBy1ujeqGW 6CqN44f/H/hNbS1AZjQhuLq9rKNkWfA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1680548790; h=from:from: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; bh=o312F+8qQ3csr6xoClPXHStqrqRF/NPJb7KBcI61xtc=; b=O464ThtgQvDkQU5NYmfnrWaps7EaQ0ONLeU4Sc32h1VWS3xzWzolINM50Cmnv+AjcMEE4w e9hMIEvHyca1bW1YWpwmKYazbxRBBAtOVuYTylol4l2Sq37742RZV8m1bpIgjsbwTyS6NT FZgu8I7ZRz0h0ZcJPW7LUQP4/yUFteU= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-376-fIymLSdpNnifAWTHkfTCvg-1; Mon, 03 Apr 2023 15:06:29 -0400 X-MC-Unique: fIymLSdpNnifAWTHkfTCvg-1 Received: by mail-wm1-f71.google.com with SMTP id k1-20020a05600c1c8100b003ee6dbceb81so15169753wms.5 for ; Mon, 03 Apr 2023 12:06:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680548788; h=content-transfer-encoding:in-reply-to:subject:organization:from :references:cc:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=o312F+8qQ3csr6xoClPXHStqrqRF/NPJb7KBcI61xtc=; b=3hk4uR4/0OByziHIr5EDmnJk2Obh7Xin8YmiMA1mk18WLQSIHOwo3YZPVxlssE75Ya dADbwBjKqQUCcqye4ULm72RJM6S+OAHv8G1DLDANvRdo1gbN0CxsyYVf/q1ODGMY0Jfz rbRub1iwA0S6vqDs0XEY2r9FGaLmTtG8P8xZESye4qPLs5+Paj20hu/kQmDQjeN531m4 F1EdXttottGQSZBAe4/G6iRJViRVnPfCiMBj1m2Ac45+0yb7PZcwuDzcpXSwSxf8QGXc wIdXcuL5zjdXTgyjq0ZByDPVV4LatBipNE2iqAEws20jI6OX1k1MPxik4DzYiTi+8DMr +Vhw== X-Gm-Message-State: AAQBX9f+D6yv9KHHx64CtklkSZx4uFw9Y9YG00ILoY+yLZUveSoQL5nL fbEL1+5VdFt4vECh43fcgYVX/nBc8JjvN73pfEwiqPHFv+bIchSwx3V8apbM8T4LpldkGwFbNQV 0NAt+CFY1KXg= X-Received: by 2002:a5d:6710:0:b0:2e3:a038:7870 with SMTP id o16-20020a5d6710000000b002e3a0387870mr122125wru.40.1680548788385; Mon, 03 Apr 2023 12:06:28 -0700 (PDT) X-Google-Smtp-Source: AKy350bf2K9RhlECDumNV6UhMWL27ufSYHSPWnXBF4+HoFPMkwvRMlQkYdnLEfRr/e6GBdIDL0MKbQ== X-Received: by 2002:a5d:6710:0:b0:2e3:a038:7870 with SMTP id o16-20020a5d6710000000b002e3a0387870mr122113wru.40.1680548788048; Mon, 03 Apr 2023 12:06:28 -0700 (PDT) Received: from ?IPV6:2003:cb:c702:5e00:8e78:71f3:6243:77f0? (p200300cbc7025e008e7871f3624377f0.dip0.t-ipconnect.de. [2003:cb:c702:5e00:8e78:71f3:6243:77f0]) by smtp.gmail.com with ESMTPSA id r1-20020a5d4941000000b002cfefa50a8esm10380139wrs.98.2023.04.03.12.06.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 Apr 2023 12:06:27 -0700 (PDT) Message-ID: Date: Mon, 3 Apr 2023 21:06:26 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 To: Peter Xu Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrea Arcangeli , Andrew Morton , Nadav Amit , Mike Kravetz , Axel Rasmussen , Leonardo Bras Soares Passos , Mike Rapoport References: <20230330155707.3106228-1-peterx@redhat.com> <20230330160752.3107283-1-peterx@redhat.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH 16/29] selftests/mm: UFFDIO_API test In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: deiq594699wq81jk33ssqjbhdwupxjnj X-Rspamd-Queue-Id: 918D4140009 X-HE-Tag: 1680548791-673843 X-HE-Meta: U2FsdGVkX1/aJ9fiy5Rd+VZHCkV4M0Wc46q72Kc+PUtqYGO0zygcjNt6jhXS31cVEDAichAXR3UC+dUyVl4DrYRoHtoflr3pF9fOmQ35HD/+qv+F5QvQUxxYUPXEpm/M3VSGckh1GGBfSn0cqEBow/daIshR7Ptqow6WNe2QdgYBSsJ/PDhEpy8SBvmXcctb5etB8Qy3ixFQIPjmWLiJ/+dOACeJZSIUoqPbzr5aR2Z62U1oOeLu4vASlG+vcJn0uDfdje1rSVA6znAN5z1/vVPnFtsmzVKcVV8XtVfKR+2IGhL2n0NuQ0ZIcVtyUwxOcKrXutRQpau/Kv9tENcjugBF/lfArZxL1BE3OjgoAwPfnJhHLr5OUWNpfiTs73A0Hg+6qgC1O1UPtT/OirRRORi8bY+OXbOMgHgDouuOkqeBS0V+3yeoDR57OIIhzFT7Ywkb7aUya0obNJl5Iyz3WIlZyfv7IvQqT1VgOK/17LJ78QPGCHNTKRVwhnd40ry4ZRNaAT2HP5mHnHR2IMgSWIPUgVAmadtHSAIInABcRl5fjArLSZyNXmMPC2Oq1iWbe2fx2zB9hdldcNv8IUVfLidthzNBnl7BxweLNH9purJCYOpkYAnG5XP3kXbFJjCoSbuZcnPhX6M+CoS8y73WJShOS8pQTnghnFos9uZ97o4N2qX9jiyE9JBNPuq/Gh8WbQ9varIF+2q1nEBZX70tK2u4vJC+cJGnq4VwdUQ1l10gVs5QHzaJRA/RRgwxtMdvVcAAU2BZCKW7YmtH/AxWDqwGMP2MEmKQv1uh/oWckcpYg3qvQG6lVLSwx5wnIk2D4OiQbGQdqvTECXwrZq6YRMCFg/Fm6ebmVkLtH5FyyGJDSGi7nAqIBE/GDp9RZgTPvbIuF9qav0PmP2xuU6OoqpcmmhAVXxEZ55PV+7b+UaEGr+OdOZ0AkZqwEe/196727Ky4Gh7qrdRPcqLsaap iZOtpvW0 s3PATdSvV+7mOE5JYZlA1CBJr/9ru83nl1HavOc0AM+9s2b34cRwETRbDmmaO10tnNs4NUzX8kqcz/x4gsCSsNtFO6gVIcYR4i7C7xrWWL8SNxgkIJH9XI1swJkshBQtlsVL+W+I5FsC0NOZLp9eWcVHNQ5iT/zkRYJEi5Hluy3yNtzAqMoG3hQkacJM2fzKDfnpbHlOG2RyNw6BURpw5zp8D/V9qXgYlqtoTl8fc67RpV9w3TFbGTNbm8Fu2v50fh6Z1+J5ogEGBUH4fNfAxLvgaCM8Y9g1XBsWmz8ZxGx2Ub7JGZ5j1bmTv1x5lv6Iaay40AjT7RnyY5SldjL3Ft6u3Soy/2Hecc5kv1ETRzdXxmEsCn2G225qqs5jmSV5jevPc8CYYYNdwGczUsfggzcjkxVoLIvZ6rdhv3v2cC9ZsIXapq9uFl6VpjhKJT0hEIiFnIOHLx5XmIifowqvRrrEndKBfvxChv01s1t3bVdb/Jm0xgfaU016FmvIj6Pms5Ud/kmoNGafwPRQ= X-Bogosity: Ham, tests=bogofilter, spamicity=0.046311, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 03.04.23 18:43, Peter Xu wrote: > On Mon, Apr 03, 2023 at 09:59:50AM +0200, David Hildenbrand wrote: >> There is ksft_print_msg, ksft_test_result, ksft_test_result_fail, ... do we >> maybe want to convert properly to ksft while already at it? > > Yes, I started with trying to use that but found that there're not a lot of > things that I can leverage. > > Starting with ksft_set_plan() - I think this is something we call first. I > want the current unit test to skip everything if UFFD API test failed here, > then I need to feed in a dynamic number of "plan" into ksft_set_plan(). > But I never know after I ran the 1st test.. In cow.c I did that. Getting the number of tests right can be challenging indeed. Basic "feature availability" checks would go first (is uffd even around?), and depending on that you can set the plan. For everything else, you can skip instead of test, so it will still be accounted towards the plan. > > I can call ksft_set_plan() later than this, but it misses a few tests which > also looks weird. Yeah, it would be nice to simply make ksft_set_plan() optional. For example, make ksft_print_cnts() skip the comparison if ksft_plan == 0. At least ksft_exit_skip() handles that already in a descend way (below). > > It also seems to not really help anything at all and not obvious to use. > E.g. ksft_finished() will reference ksft_plan then it'll trigger > ksft_exit_fail() but here I want to make it SKIP if the 1st test failed > simply because the kernel probably doesn't have CONFIG_USERFAULTFD. You'd simply do that availability check first and then use ksft_exit_skip() in case not available I guess. > > Another example: I never figured what does x{fail|pass|skip} meant in the > header.. e.g. ksft_inc_xfail_cnt() is used nowhere so I cannot reference > either. Then I don't know when I should increase them. In cow.c I have the following flow: ksft_print_header(); ksft_set_plan(); ... tests ... err = ksft_get_fail_cnt(); if (err) ksft_exit_fail_msg(); return ksft_exit_pass(); That gives me: # [INFO] detected THP size: 2048 KiB # [INFO] detected hugetlb size: 2048 KiB # [INFO] detected hugetlb size: 1048576 KiB # [INFO] huge zeropage is enabled TAP version 13 1..190 ... # Totals: pass:87 fail:0 xfail:0 xpass:0 skip:103 error:0 I didn't use xfail or xpass so far, but what I understood is that these are "expected failures" and "expected passes". fail/pass/skip are straight forward. ksft_test_result_fail()/ksft_test_result_pass()/ksft_test_result_skip() are used to set them. You'd do availability checks before ksft_set_plan() and fail with a ksft_exit_skip() if the kernel doesn't support it. Then, you'd just use ksft_test_result_fail()/ksft_test_result_pass()/ksft_test_result_skip(). > > In short, to make the unit test behave as expected, I figured I'll just > write these few helpers and that's good enough for this unit test. That > takes perhaps 5 min anyway and isn't hugely bad for an unit test. > > Then I keep the exit code matching kselftests (KSFT_SKIP, etc.). > > What I can do here, though, is at least reuse the counters, e.g: > > ksft_inc_pass_cnt() / ksft_inc_fail_cnt() > > There's no ksft_inc_skip_cnt() so, maybe, I can just reuse > ksft_inc_xskip_cnt() assuming that counts "skip"s? > > Let me know if you have better ideas, I'll be happy to switch in that case. I guess once you start manually increasing/decreasing the cnt, you might be abusing the ksft framework indeed and are better off handling it differently :D -- Thanks, David / dhildenb