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 89F0BC3601A for ; Mon, 7 Apr 2025 08:35:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 86E026B0005; Mon, 7 Apr 2025 04:35:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 81A2A6B0007; Mon, 7 Apr 2025 04:35:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6E2376B0008; Mon, 7 Apr 2025 04:35:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 51ADC6B0005 for ; Mon, 7 Apr 2025 04:35:19 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 64E1380FE0 for ; Mon, 7 Apr 2025 08:35:20 +0000 (UTC) X-FDA: 83306588400.14.E44EB2D Received: from out30-101.freemail.mail.aliyun.com (out30-101.freemail.mail.aliyun.com [115.124.30.101]) by imf21.hostedemail.com (Postfix) with ESMTP id 7E62C1C000D for ; Mon, 7 Apr 2025 08:35:17 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=WdB7BFhi; spf=pass (imf21.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.101 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744014918; 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=Udd0Kb0rIbcEFFzCXIlMyfGS8vlMEao8bdeGZFHIkGA=; b=wIQDXvvp+ibknAb9gnWt5AJGTVPmsfMPuBH3lHSPuQ54GvR/hcZ72tkNTmmKxk6YXNYdYK rs2HKG1lJ7kHrrZvghoj6lDhOCLjYjzrboeXKHWml1zM23iIimNM0kT2GLAnHBGOdJx+sx dRQcOaX/xfEziFutpFRgtK7R4wBXp1w= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744014918; a=rsa-sha256; cv=none; b=q3upSDDG+0D5GxqFkjWUhRaPNAUL7H9mdebgfSWTrmTIRXo/gyk7WGIDNPQ3zMSe2LVlSo kHLRFxiegrpQ6MB6kW+i/biYVxiZQEW2lqexMB1lvfhkZAmO5Ano6GvH+zDtMY41iIZFyA vHfLvrXOZPbn+YZQvKLUyl/9OUw9XpQ= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=WdB7BFhi; spf=pass (imf21.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.101 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1744014914; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=Udd0Kb0rIbcEFFzCXIlMyfGS8vlMEao8bdeGZFHIkGA=; b=WdB7BFhim82djbLH7L42EVOK/gxo2QeZRAKpCDEJ5tH1TUBAUHWLgO6UjgjPGIC+RiLOQxDEaQFvqkMOJ9N6rsHK6NfS9Np9tIiVrweBsiewJf+Z5MDFijWVnyaNQxw+n/iTtIIfFPe4asL5fJc3KNj6rS7OiJfvtieLMkPq8cA= Received: from 30.74.144.125(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WVrTlum_1744014912 cluster:ay36) by smtp.aliyun-inc.com; Mon, 07 Apr 2025 16:35:13 +0800 Message-ID: <635fb13b-0e22-4e3d-a9ab-971f301a7d99@linux.alibaba.com> Date: Mon, 7 Apr 2025 16:35:12 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] selftests: mincore: fix tmpfs mincore test failure To: David Hildenbrand , akpm@linux-foundation.org, hughd@google.com Cc: willy@infradead.org, 21cnbao@gmail.com, ryan.roberts@arm.com, ziy@nvidia.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <99a3e190d38b08a2b96ede952a29893bffdb3432.1742960003.git.baolin.wang@linux.alibaba.com> <9000c5c1-34be-4bc9-b1c0-11548264eaa6@redhat.com> <662ad650-8c68-40ef-a109-2e489658880d@redhat.com> From: Baolin Wang In-Reply-To: <662ad650-8c68-40ef-a109-2e489658880d@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Stat-Signature: 3yqqghspiugb3rj9e7gda583phjn8tus X-Rspam-User: X-Rspamd-Queue-Id: 7E62C1C000D X-Rspamd-Server: rspam08 X-HE-Tag: 1744014917-995404 X-HE-Meta: U2FsdGVkX18njctffL7UYXe6r6CxMq6E10GoDfdhhDBuNU348TkFcBZlDT6etDl0hPJq/o0U+dJ8yOcH0BlDkx36wkeu5JDGO20hZiS+H7SIJsdGB3t0Rid6OaZ0AXD0ja5/k/8r8Y7b9tgyk1PeYjVV17XyQ2f7gIOn5GdDtAp+jaEY6WNkblaD4ePAntTyS00sWlu6EGJrKn0joCb8x2LCNiIUI2NGFP9uyzomFo+c3IK9SQjcKpxER/QWzHmPLnfTpEn4eFS/Z4lPwXIbpgzRttfVH5I7B6EoDljHqocvY+QOGdLI4yo94b/e+f3nEmv4cDCxsrR7GwkJZDrait0Ex7ignU5y+nhPzHkPixlVrOLud63+dN0hITwNZnzFvafnlZ2xwg2JPMEFyft9I+SnwuUJHot7RAajov5me2apSPMbNIx7X61RmpmooTJ06MggAxT3q236pRRJXlpGueLrjZiXwjp+MvbJht45aHnc23rup9W4ascLKCw7LH3sAFQeHtpvt1SCKO852sSXToiRjPkqAGdipJqQ/yz8a7rnBEki+3yPCWl2znyG6pGiB+3VzYDPclpI2SbQ5nqZrPyfUzCY9JrB7jVsuwSD1CPTpTZX+eEoFAIoyQzZxEFZBTBapP2pvQUAj2e85MrEUIo1UHWFF3Y8EH4PyF1m1MWr1elYxWXWl7CF2fidq08JWr6dOTbv5koNgl87mOMR2sDtZ4aWdz6IiLfu6W2s1vS0KUKrNung0kKzctRA1+R+S++xqG7kiXk5M20ob4IzLxzWoRhzbydQMpsJWLmAWUNbXfY8gq4zwpRxgcrUVisueno60Kw46uE6jhQs1t3x7V/dzqJ1WR8SX1l1jvmGk4D9JopIteGgf7cGAFsN0pW/i3DpL77TqoOoK6tj9yNudVJS69UKcoylY3SjH/cOgtoN1tzMzsvWf0/Q+JlveRFGCSGu3UmOjwA6oUzQe2M gKdcBh8S 9Cvyf21FUsOaEQlCLLNhKEwe4uWl0OioGvuK9HTx8oO8syDncTBhkn8KpUxcwKu0EuiRMre4Pz66Pj9zx2zjKlRMWQo7O4xBL4V92lhsRBN2Mu9qdr0BOzi+4vtDVDx8roDo/E12OpqWK6/+5N+4CMKbO+YHcEBCjwToUxYSBGgxiSBp456p6YdnlmkBFCtiOCzgkz1OvBDiGyIMnyXrE2Q1LQ+x+Teot11qw9zvzX54nyfHHU7Gvz+7zeQJUpUNf3u1h4KChb9NkAEFTIQkv3guxxqmGuJWVTlB9+2rTb1s0XGBb+6tdD51lxHvQ9t7Xw25tMz5nmI0cEVI= 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: List-Subscribe: List-Unsubscribe: On 2025/4/7 15:49, David Hildenbrand wrote: > On 07.04.25 05:49, Baolin Wang wrote: >> >> >> On 2025/4/1 20:54, David Hildenbrand wrote: >>> On 26.03.25 04:38, Baolin Wang wrote: >>>> When running mincore test cases, I encountered the following failures: >>>> >>>> " >>>> mincore_selftest.c:359:check_tmpfs_mmap:Expected ra_pages (511) == 0 >>>> (0) >>>> mincore_selftest.c:360:check_tmpfs_mmap:Read-ahead pages found in >>>> memory >>>> check_tmpfs_mmap: Test terminated by assertion >>>>             FAIL  global.check_tmpfs_mmap >>>> not ok 5 global.check_tmpfs_mmap >>>> FAILED: 4 / 5 tests passed >>>> " >>>> >>>> The reason for the test case failure is that my system automatically >>>> enabled >>>> tmpfs large folio allocation by adding the >>>> 'transparent_hugepage_tmpfs=always' >>>> cmdline. However, the test case still expects the tmpfs mounted on >>>> /dev/shm to >>>> allocate small folios, which leads to assertion failures when >>>> verifying readahead >>>> pages. >>>> >>>> To fix this issue, remount tmpfs to a new test directory and set the >>>> 'huge=never' >>>> parameter to avoid allocating large folios, which can pass the test. >>>> >>>> Signed-off-by: Baolin Wang >>>> --- >>>>    .../selftests/mincore/mincore_selftest.c      | 25 >>>> +++++++++++++++++-- >>>>    1 file changed, 23 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/tools/testing/selftests/mincore/mincore_selftest.c >>>> b/tools/testing/selftests/mincore/mincore_selftest.c >>>> index e949a43a6145..e8d7a3a4739f 100644 >>>> --- a/tools/testing/selftests/mincore/mincore_selftest.c >>>> +++ b/tools/testing/selftests/mincore/mincore_selftest.c >>>> @@ -12,6 +12,7 @@ >>>>    #include >>>>    #include >>>>    #include >>>> +#include >>>>    #include >>>>    #include >>>> @@ -283,7 +284,7 @@ TEST(check_file_mmap) >>>>        free(vec); >>>>    } >>>> - >>>> +#define INPUT_MAX 80 >>>>    /* >>>>     * Test mincore() behavior on a page backed by a tmpfs file. >>>> This test >>>>     * performs the same steps as the previous one. However, we don't >>>> expect >>>> @@ -291,6 +292,9 @@ TEST(check_file_mmap) >>>>     */ >>>>    TEST(check_tmpfs_mmap) >>>>    { >>>> +    char tmpfs_template[] = "/tmp/check_tmpfs_XXXXXX"; >>>> +    const char *tmpfs_loc = mkdtemp(tmpfs_template); >>>> +    char testfile[INPUT_MAX]; >>>>        unsigned char *vec; >>>>        int vec_size; >>>>        char *addr; >>>> @@ -300,6 +304,10 @@ TEST(check_tmpfs_mmap) >>>>        int i; >>>>        int ra_pages = 0; >>>> +    ASSERT_NE(NULL, tmpfs_loc) { >>>> +        TH_LOG("Can't mkdir tmpfs dentry\n"); >>>> +    } >>>> + >>>>        page_size = sysconf(_SC_PAGESIZE); >>>>        vec_size = FILE_SIZE / page_size; >>>>        if (FILE_SIZE % page_size) >>>> @@ -311,7 +319,18 @@ TEST(check_tmpfs_mmap) >>>>        } >>>>        errno = 0; >>>> -    fd = open("/dev/shm", O_TMPFILE | O_RDWR, 0600); >>>> +    /* Do not use large folios for tmpfs mincore testing */ >>>> +    retval = mount("tmpfs", tmpfs_loc, "tmpfs", 0, >>>> "huge=never,size=4M"); >>>> +    ASSERT_EQ(0, retval) { >>>> +        TH_LOG("Unable to mount tmpfs for testing\n"); >>>> +    } >>>> + >>>> +    retval = snprintf(testfile, INPUT_MAX, "%s/test_file", tmpfs_loc); >>>> +    ASSERT_GE(INPUT_MAX, retval) { >>>> +        TH_LOG("Unable to create a tmpfs for testing\n"); >>>> +    } >>>> + >>>> +    fd = open(testfile, O_CREAT|O_RDWR, 0664); >>>>        ASSERT_NE(-1, fd) { >>>>            TH_LOG("Can't create temporary file: %s", >>>>                strerror(errno)); >>>> @@ -363,6 +382,8 @@ TEST(check_tmpfs_mmap) >>>>        munmap(addr, FILE_SIZE); >>>>        close(fd); >>>>        free(vec); >>>> +    umount(tmpfs_loc); >>>> +    rmdir(tmpfs_loc); >>>>    } >>>>    TEST_HARNESS_MAIN >>> >>> Is there anything that cleans up the mount in case something goes wrong >>> (we run into an assertion), or will the directory+mount stick around >>> forever? >> >> Good point, will cleanup the mount in the next version. >> >>> >>> But I also wonder whether check_tmpfs_mmap() should be changed to live >>> with the fact that readahead ("faultaround") could now happen. What's >>> the reason for not doing that? >> >>   From this test case's description, it doesn't expect any readahead. > > Yes, but why are we testing for that *at all*? We don't make such > assumptions/tests for anon memmory ("no faultaround happened"). > > Why not simply remove the "We expect only that page to be fetched into > memory." documentation + checking? OK. I'm fine with dropping the readahead check. Thanks.