From: Andrew Morton <akpm@linux-foundation.org> To: shuah@kernel.org,joel@joelfernandes.org,mike.kravetz@oracle.com,akpm@linux-foundation.org,patches@lists.linux.dev,linux-mm@kvack.org,mm-commits@vger.kernel.org,torvalds@linux-foundation.org,akpm@linux-foundation.org Subject: [patch 12/12] selftests/memfd: clean up mapping in mfd_fail_write Date: Fri, 25 Feb 2022 19:11:26 -0800 [thread overview] Message-ID: <20220226031127.424C0C340EF@smtp.kernel.org> (raw) In-Reply-To: <20220225191021.f71538a3f43dc448110e88b6@linux-foundation.org> From: Mike Kravetz <mike.kravetz@oracle.com> Subject: selftests/memfd: clean up mapping in mfd_fail_write Running the memfd script ./run_hugetlbfs_test.sh will often end in error as follows: memfd-hugetlb: CREATE memfd-hugetlb: BASIC memfd-hugetlb: SEAL-WRITE memfd-hugetlb: SEAL-FUTURE-WRITE memfd-hugetlb: SEAL-SHRINK fallocate(ALLOC) failed: No space left on device ./run_hugetlbfs_test.sh: line 60: 166855 Aborted (core dumped) ./memfd_test hugetlbfs opening: ./mnt/memfd fuse: DONE If no hugetlb pages have been preallocated, run_hugetlbfs_test.sh will allocate 'just enough' pages to run the test. In the SEAL-FUTURE-WRITE test the mfd_fail_write routine maps the file, but does not unmap. As a result, two hugetlb pages remain reserved for the mapping. When the fallocate call in the SEAL-SHRINK test attempts allocate all hugetlb pages, it is short by the two reserved pages. Fix by making sure to unmap in mfd_fail_write. Link: https://lkml.kernel.org/r/20220219004340.56478-1-mike.kravetz@oracle.com Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com> Cc: Joel Fernandes <joel@joelfernandes.org> Cc: Shuah Khan <shuah@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> --- tools/testing/selftests/memfd/memfd_test.c | 1 + 1 file changed, 1 insertion(+) --- a/tools/testing/selftests/memfd/memfd_test.c~selftests-memfd-clean-up-mapping-in-mfd_fail_write +++ a/tools/testing/selftests/memfd/memfd_test.c @@ -455,6 +455,7 @@ static void mfd_fail_write(int fd) printf("mmap()+mprotect() didn't fail as expected\n"); abort(); } + munmap(p, mfd_def_size); } /* verify PUNCH_HOLE fails */ _
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org> To: shuah@kernel.org, joel@joelfernandes.org, mike.kravetz@oracle.com, akpm@linux-foundation.org, patches@lists.linux.dev, linux-mm@kvack.org, mm-commits@vger.kernel.org, torvalds@linux-foundation.org, akpm@linux-foundation.org Subject: [patch 12/12] selftests/memfd: clean up mapping in mfd_fail_write Date: Fri, 25 Feb 2022 19:11:26 -0800 [thread overview] Message-ID: <20220226031127.424C0C340EF@smtp.kernel.org> (raw) In-Reply-To: <20220225191021.f71538a3f43dc448110e88b6@linux-foundation.org> From: Mike Kravetz <mike.kravetz@oracle.com> Subject: selftests/memfd: clean up mapping in mfd_fail_write Running the memfd script ./run_hugetlbfs_test.sh will often end in error as follows: memfd-hugetlb: CREATE memfd-hugetlb: BASIC memfd-hugetlb: SEAL-WRITE memfd-hugetlb: SEAL-FUTURE-WRITE memfd-hugetlb: SEAL-SHRINK fallocate(ALLOC) failed: No space left on device ./run_hugetlbfs_test.sh: line 60: 166855 Aborted (core dumped) ./memfd_test hugetlbfs opening: ./mnt/memfd fuse: DONE If no hugetlb pages have been preallocated, run_hugetlbfs_test.sh will allocate 'just enough' pages to run the test. In the SEAL-FUTURE-WRITE test the mfd_fail_write routine maps the file, but does not unmap. As a result, two hugetlb pages remain reserved for the mapping. When the fallocate call in the SEAL-SHRINK test attempts allocate all hugetlb pages, it is short by the two reserved pages. Fix by making sure to unmap in mfd_fail_write. Link: https://lkml.kernel.org/r/20220219004340.56478-1-mike.kravetz@oracle.com Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com> Cc: Joel Fernandes <joel@joelfernandes.org> Cc: Shuah Khan <shuah@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> --- tools/testing/selftests/memfd/memfd_test.c | 1 + 1 file changed, 1 insertion(+) --- a/tools/testing/selftests/memfd/memfd_test.c~selftests-memfd-clean-up-mapping-in-mfd_fail_write +++ a/tools/testing/selftests/memfd/memfd_test.c @@ -455,6 +455,7 @@ static void mfd_fail_write(int fd) printf("mmap()+mprotect() didn't fail as expected\n"); abort(); } + munmap(p, mfd_def_size); } /* verify PUNCH_HOLE fails */ _
next prev parent reply other threads:[~2022-02-26 3:11 UTC|newest] Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-02-26 3:10 incoming Andrew Morton 2022-02-26 3:10 ` [patch 01/12] MAINTAINERS: add sysctl-next git tree Andrew Morton 2022-02-26 3:10 ` Andrew Morton 2022-02-26 3:10 ` [patch 02/12] mm/hugetlb: fix kernel crash with hugetlb mremap Andrew Morton 2022-02-26 3:10 ` Andrew Morton 2022-02-26 3:10 ` [patch 03/12] kasan: test: prevent cache merging in kmem_cache_double_destroy Andrew Morton 2022-02-26 3:10 ` Andrew Morton 2022-02-26 3:11 ` [patch 04/12] hugetlbfs: fix a truncation issue in hugepages parameter Andrew Morton 2022-02-26 3:11 ` Andrew Morton 2022-02-26 3:11 ` [patch 05/12] mm: fix use-after-free bug when mm->mmap is reused after being freed Andrew Morton 2022-02-26 3:11 ` Andrew Morton 2022-02-26 3:11 ` [patch 06/12] selftest/vm: fix map_fixed_noreplace test failure Andrew Morton 2022-02-26 3:11 ` Andrew Morton 2022-02-26 3:11 ` [patch 07/12] MAINTAINERS: add Roman as a memcg co-maintainer Andrew Morton 2022-02-26 3:11 ` Andrew Morton 2022-02-26 3:11 ` [patch 08/12] MAINTAINERS: remove Vladimir from memcg maintainers Andrew Morton 2022-02-26 3:11 ` Andrew Morton 2022-02-26 3:11 ` [patch 09/12] MAINTAINERS: add Shakeel as a memcg co-maintainer Andrew Morton 2022-02-26 3:11 ` Andrew Morton 2022-02-26 3:11 ` [patch 10/12] MAINTAINERS, SLAB: add Roman as reviewer, git tree Andrew Morton 2022-02-26 3:11 ` Andrew Morton 2022-02-26 3:11 ` [patch 11/12] mailmap: update Roman Gushchin's email Andrew Morton 2022-02-26 3:11 ` Andrew Morton 2022-02-26 3:11 ` Andrew Morton [this message] 2022-02-26 3:11 ` [patch 12/12] selftests/memfd: clean up mapping in mfd_fail_write Andrew Morton
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20220226031127.424C0C340EF@smtp.kernel.org \ --to=akpm@linux-foundation.org \ --cc=joel@joelfernandes.org \ --cc=linux-mm@kvack.org \ --cc=mike.kravetz@oracle.com \ --cc=mm-commits@vger.kernel.org \ --cc=patches@lists.linux.dev \ --cc=shuah@kernel.org \ --cc=torvalds@linux-foundation.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.