From: Richard Palethorpe <rpalethorpe@suse.de>
To: Samir Mulani <samir@linux.vnet.ibm.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v2] Migrating the libhugetlbfs/testcases/truncate_sigbus_versus_oom.c test
Date: Mon, 20 Nov 2023 10:34:48 +0000 [thread overview]
Message-ID: <87a5r8adr8.fsf@suse.de> (raw)
In-Reply-To: <20230919072022.93034-1-samir@linux.vnet.ibm.com>
Hello,
Samir Mulani <samir@linux.vnet.ibm.com> writes:
> In this test case, we are verifying the bug fix commit that is attached as
> a part of the test case structure,
>
> Some kernel have a bug in the positioning of the test against
> i_size. This bug means that attempting to instantiate a page
> beyond the end of a hugepage file can result in an OOM and SIGKILL
> instead of the correct SIGBUS.
>
> Signed-off-by: Samir Mulani <samir@linux.vnet.ibm.com>
> ---
> v2:
> -Corrected typo.
> -Fixed the make check warnings.
> ---
> runtest/hugetlb | 1 +
> testcases/kernel/mem/.gitignore | 1 +
> .../kernel/mem/hugetlb/hugemmap/hugemmap37.c | 88 +++++++++++++++++++
> 3 files changed, 90 insertions(+)
> create mode 100644 testcases/kernel/mem/hugetlb/hugemmap/hugemmap37.c
>
> diff --git a/runtest/hugetlb b/runtest/hugetlb
> index 299c07ac9..7b7c44b77 100644
> --- a/runtest/hugetlb
> +++ b/runtest/hugetlb
> @@ -35,6 +35,7 @@ hugemmap29 hugemmap29
> hugemmap30 hugemmap30
> hugemmap31 hugemmap31
> hugemmap32 hugemmap32
> +hugemmap37 hugemmap37
> hugemmap05_1 hugemmap05 -m
> hugemmap05_2 hugemmap05 -s
> hugemmap05_3 hugemmap05 -s -m
> diff --git a/testcases/kernel/mem/.gitignore b/testcases/kernel/mem/.gitignore
> index 7258489ed..7b923c8fd 100644
> --- a/testcases/kernel/mem/.gitignore
> +++ b/testcases/kernel/mem/.gitignore
> @@ -34,6 +34,7 @@
> /hugetlb/hugemmap/hugemmap30
> /hugetlb/hugemmap/hugemmap31
> /hugetlb/hugemmap/hugemmap32
> +/hugetlb/hugemmap/hugemmap37
> /hugetlb/hugeshmat/hugeshmat01
> /hugetlb/hugeshmat/hugeshmat02
> /hugetlb/hugeshmat/hugeshmat03
> diff --git a/testcases/kernel/mem/hugetlb/hugemmap/hugemmap37.c b/testcases/kernel/mem/hugetlb/hugemmap/hugemmap37.c
> new file mode 100644
> index 000000000..66990db25
> --- /dev/null
> +++ b/testcases/kernel/mem/hugetlb/hugemmap/hugemmap37.c
> @@ -0,0 +1,88 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2005-2006 David Gibson & Adam Litke, IBM Corporation.
> + */
> +
> +/*\
> + * [Description]
> + *
> + * Test Name: Truncate_sigbus_versus_oom
> + *
> + * Some kernel have a bug in the positioning of the test against
> + * i_size. This bug means that attempting to instantiate a page
> + * beyond the end of a hugepage file can result in an OOM and SIGKILL
> + * instead of the correct SIGBUS.
> + */
> +
> +#include "hugetlb.h"
> +
> +#define MNTPOINT "hugetlbfs/"
> +#define PTS_PASS 0
> +static int fd = -1, fdx = -1;
> +
> +static unsigned long long hpage_size;
> +static unsigned long totpages;
> +struct sigaction sa;
> +
> +static void sigbus_handler(int signum)
> +{
> + if (signum == SIGBUS) {
> + tst_res(TPASS, "Test PASSED\n");
> + _exit(PTS_PASS);
In LTP we try to do as little as possible in signal handlers. In rare
cases some library functions don't work as expected.
Here we should just set a volatile variable with the signal number that
was caught. Then inspect it later.
> + }
> +}
> +
> +static void run_test(void)
> +{
> + void *p, *q;
> + unsigned long i;
> +
> + fd = tst_creat_unlinked(MNTPOINT, 0);
> + p = SAFE_MMAP(NULL, hpage_size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
> + SAFE_FTRUNCATE(fd, 0);
> +
> + fdx = tst_creat_unlinked(MNTPOINT, 0);
> + q = SAFE_MMAP(NULL, totpages * hpage_size, PROT_READ|PROT_WRITE, MAP_SHARED, fdx, 0);
> + /* Touch the pages to ensure they're removed from the pool */
> + for (i = 0; i < totpages; i++) {
> + volatile char *x = (volatile char *)q + i*hpage_size;
> + *x = 0;
> + }
> + /* SIGBUS is what *should* happen */
> + SAFE_FTRUNCATE(fdx, 0);
> + *((volatile unsigned int *)p);
> + tst_res(TFAIL, "Didn't SIGBUS or OOM");
Here we could check a variable we set in the signal handler.
There is nothing here to free the mapped pages or close the files. So
most likely SAFE_MMAP will fail on the second iteration (i.e. with -i 2)
and eventually we would run out of file descriptors.
> +}
> +
> +void setup(void)
> +{
> + sa.sa_flags = SA_SIGINFO;
> + sa.sa_handler = sigbus_handler;
> + SAFE_SIGACTION(SIGBUS, &sa, NULL);
> + totpages = SAFE_READ_MEMINFO(MEMINFO_HPAGE_FREE);
There is a possible TOCTOU problem here. I don't think it can be avoided
completely, but perhaps we should read the number of free pages just
before calling the second mmap?
> + hpage_size = tst_get_hugepage_size();
> +}
> +
> +void cleanup(void)
> +{
> + if (fd > 0)
> + SAFE_CLOSE(fd);
> + if (fdx > 0)
> + SAFE_CLOSE(fdx);
> +}
> +
> +
> +static struct tst_test test = {
> + .tags = (struct tst_tag[]) {
> + {"linux-git", "0d59a01bc461"},
I think this is the wrong commit. It prevents the stack from growing
into a huge page region.
> + {}
> + },
> + .needs_root = 1,
> + .mntpoint = MNTPOINT,
> + .needs_hugetlbfs = 1,
> + .needs_tmpdir = 1,
> + .setup = setup,
> + .cleanup = cleanup,
> + .test_all = run_test,
> + .hugepages = {2, TST_NEEDS},
> +};
> --
> 2.39.3
--
Thank you,
Richard.
--
Mailing list info: https://lists.linux.it/listinfo/ltp
prev parent reply other threads:[~2023-11-20 11:03 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-19 7:20 [LTP] [PATCH v2] Migrating the libhugetlbfs/testcases/truncate_sigbus_versus_oom.c test Samir Mulani
2023-11-20 10:34 ` Richard Palethorpe [this message]
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=87a5r8adr8.fsf@suse.de \
--to=rpalethorpe@suse.de \
--cc=ltp@lists.linux.it \
--cc=samir@linux.vnet.ibm.com \
/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: link
Be 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.