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 203E6C36010 for ; Mon, 7 Apr 2025 03:49:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AF8126B0007; Sun, 6 Apr 2025 23:49:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AA8106B0008; Sun, 6 Apr 2025 23:49:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 96FC26B000A; Sun, 6 Apr 2025 23:49:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 78FB86B0007 for ; Sun, 6 Apr 2025 23:49:26 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id EBE58B7E29 for ; Mon, 7 Apr 2025 03:49:13 +0000 (UTC) X-FDA: 83305867386.20.9A09AC6 Received: from out30-130.freemail.mail.aliyun.com (out30-130.freemail.mail.aliyun.com [115.124.30.130]) by imf03.hostedemail.com (Postfix) with ESMTP id 4CB1420006 for ; Mon, 7 Apr 2025 03:49:09 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=cVWRhwxw; spf=pass (imf03.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.130 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=1743997752; 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=DEDu5rdn8ShbXDZZa2qYlfq0mSmMd2y6q6eMReHRAKg=; b=Ija4ixC3MtEAuh3+a532AY7rDVUDkNGrCgkmm0Wp5TCFOGxvcoenddDSkjlW7oBNJMpjY1 JSkQhp3jFd81m9dxlO/MmY2K4e+0lvu7vjHXqwvueyKbhmXRkjZCP054Rhf99w3rqjlP6m KLkDPWn8SDtHr3S2ceBrTYfQnbzQhPE= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=cVWRhwxw; spf=pass (imf03.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.130 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743997752; a=rsa-sha256; cv=none; b=f8UszVTQFwaiQt4XKNWmjs0RudQUBbaNFqzwUGIj+jLeQRvod5f8HEPlgGOZEP+7Jv69i4 4/2iCM2xWi+gQGPhesH9cMmg70ONzlS/m2TxxtCRY34jxIxDA5IOnwVoJyYJgymyc9D8+U BepiOsZ+kOWXE9b4EdSo96BiAkm36DA= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1743997747; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=DEDu5rdn8ShbXDZZa2qYlfq0mSmMd2y6q6eMReHRAKg=; b=cVWRhwxwUUqbMyFR0dblrWdwDifedpN67gY2A8pz/wcImFpukA4/b8mOOPqwhipCyv+/R6RgCwVfb9AgZp/rlsBnpvJRTDmehWGa6gOnB36wmYc+0OTs0xZGvJWCaH1WlKONICTmt2WKiBVkYpfH4TJu62pRLB/QusBF5UHhNpE= Received: from 30.74.144.125(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WVlqZzc_1743997745 cluster:ay36) by smtp.aliyun-inc.com; Mon, 07 Apr 2025 11:49:06 +0800 Message-ID: Date: Mon, 7 Apr 2025 11:49:05 +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> From: Baolin Wang In-Reply-To: <9000c5c1-34be-4bc9-b1c0-11548264eaa6@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4CB1420006 X-Stat-Signature: bsrudjsao9kzboy7an7tf73xszw4t6j6 X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1743997749-66050 X-HE-Meta: U2FsdGVkX1+3+e2a+2xRB4PnoyQtrNgtFm6V28cLoJp7hD6qm7X4BOQYdwKB4ECOTHwJxkqyjdjCL0ds3U2VxbpIq+dQt4g5KDfBfLX8NbHCcYWqOtq+1rnh5aLLSdibHOH10M6CqIzqZJgoCFjMAQ7FBDpnr9CYK42dUHU65XwY7+j5dw7UIS5Z/JViluT/fXi5jHbV5JbaL0SDsvcDc1MP/l+10CMikF0JZmsCGQxro89dhMyZdJGSKHVNUXmooFQ454zpvrsDi8FwMY8FIQhWniWObSwWSetJl26cRVd0gwcMZg37ahOTQQLZk+IwQqp8Q3v43JxIA4PouPv5LiOXtKd8UDkyPOncpjGtsFC4I8PFNQblMoqDYxihstJlnxTVhRzKH3YgbS8J4efa8WzuwTXSyuTbLHni5vm+72AmhEy9pvkEQ6Z1Zzj8F6qo9KOtWDbUAH7UrJZwOT7/QDxKqBDwiYCUNxxWWpct4dj2+RxuKJ4J5Z2O1ulnQQFDvEQvzBhPffjA7/PNxImEzHOyekx3O1T8GAJ6h/CJI5tOw2ORYtzQN4n8g/crSZXIhSnVAeVTPAVCBZxZSE3loj0WPKhX/QTLtPTmHx/f56fNxjIcbjos0tSTF23bIcQETTb/5fvRx2TebHrb5z8S5SmKk6XuNygE+qxv/33+K5mmKGFv5+NB3qCYmHCFvCIK88XpeeImkUSVVp9cO1i2rCWrrvxCanuFNOwclLbYZ21M4IfTbyPzpK5tcGQn2K3TNc6Q0rFv6+6dMMrvloxnUppuxhhCVMw+xdNEc6QuEwNR44z2tAwAevKyHG73arTB6w9Fl5yn/U3u0dRr72//Aht04rlVCobIUmOqx2mPMqEmBkss7YHfqQCWSwJVKokijFwMdH3RCbHpQKKBuGv6MV/WE2Kwciw3tu/s+wEK66gIpUfYAbpxGfQp0DCdnigrXep1sccDsA6P1Oj5O1p 7G6b11vx gdmLyhHFpf2Rk8FQjRwOlWucuPixsYYkQMNQKMvzrSLnWzhpdlOx5DpHQktFcomMa86kd04/I/jqua2zQSJqOmvQUZDFXddcoM0JJpWckMtma+x4NtoRsJl+swEr012rYLfflymE/SxPM2PxC7nZUe7JnrXj/RPkxpkXjHBh5HgYNpFdOlmRbyu/zIfbJPzbvg78UPt91hiHhnmfiBhEXLYc3YdLiKxaVVfwq7xERnHE32VxQ9wh59ZopLfYe2NPUweYyY6g7SyBRkS6Jo6YCg7e2ycQK1ITODchhjgJ53JfRsP5uyShNu6AMRINp0cN/Qt/VVccqscvAx9g= 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/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. " /* * 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 * any readahead in this case. */ " Maybe adding a new test case to expect the readahead for tmpfs file.