From: Cyril Hrubis <chrubis@suse.cz>
To: Tarun Sahu <tsahu@linux.ibm.com>
Cc: sbhat@linux.ibm.com, aneesh.kumar@linux.ibm.com,
geetika@linux.ibm.com, vaibhav@linux.ibm.com, ltp@lists.linux.it,
mike.kravetz@oracle.com
Subject: Re: [LTP] [PATCH v2 3/5] Hugetlb: Migrating libhugetlbfs fadvise_reserve
Date: Wed, 9 Nov 2022 17:18:26 +0100 [thread overview]
Message-ID: <Y2vS0slepYtvWQBx@yuki> (raw)
In-Reply-To: <20221108195207.232115-4-tsahu@linux.ibm.com>
Hi!
> +/*\
> + * [Description]
> + *
> + * fadvise() on some kernels can cause the reservation counter to get
> + * corrupted. The problem is that the patches are allocated for the
> + * reservation but not faulted in at the time of allocation. The counters
> + * do not get updated and effectively "leak". This test identifies whether
> + * the kernel is vulnerable to the problem or not. It's fixed in kernel
> + * by commit f2deae9d4e70793568ef9e85d227abb7bef5b622.
> + */
> +
> +#define _GNU_SOURCE
> +#include <stdio.h>
> +#include <sys/mount.h>
> +#include <limits.h>
> +#include <sys/param.h>
> +#include <sys/types.h>
> +
> +#include "hugetlb.h"
> +
> +#define MNTPOINT "hugetlbfs/"
> +static long hpage_size;
> +static int fd = -1;
> +
> +static void run_test(void)
> +{
> + void *p;
> + unsigned long initial_rsvd, map_rsvd, fadvise_rsvd, end_rsvd;
> +
> + fd = tst_creat_unlinked(MNTPOINT);
> +
> + initial_rsvd = SAFE_READ_MEMINFO(MEMINFO_HPAGE_RSVD);
> + tst_res(TINFO, "Reserve count before map: %lu", initial_rsvd);
> +
> + p = SAFE_MMAP(NULL, hpage_size, PROT_READ|PROT_WRITE, MAP_SHARED,
> + fd, 0);
> + map_rsvd = SAFE_READ_MEMINFO(MEMINFO_HPAGE_RSVD);
> + tst_res(TINFO, "Reserve count after map: %lu", map_rsvd);
> +
> + if (posix_fadvise(fd, 0, hpage_size, POSIX_FADV_WILLNEED) == -1) {
> + tst_res(TFAIL|TERRNO, "fadvise()");
> + goto cleanup;
> + }
If we follow how SAFE_MACROS() works this should rather be:
if (posix_fadvise(...)
tst_brk(TBROK|TERRNO, "fadvise()");
> + fadvise_rsvd = SAFE_READ_MEMINFO(MEMINFO_HPAGE_RSVD);
> + tst_res(TINFO, "Reserve count after fadvise: %lu", fadvise_rsvd);
> +
> + memset(p, 1, hpage_size);
> +
> + SAFE_MUNMAP(p, hpage_size);
> + p = NULL;
> + SAFE_CLOSE(fd);
> + end_rsvd = SAFE_READ_MEMINFO(MEMINFO_HPAGE_RSVD);
> + tst_res(TINFO, "Reserve count after close: %lu", end_rsvd);
> +
> + TST_EXP_EQ_LU(end_rsvd, initial_rsvd);
> +cleanup:
> + if (p)
> + SAFE_MUNMAP(p, hpage_size);
> + if (fd > 0)
> + SAFE_CLOSE(fd);
> +}
> +
> +static void setup(void)
> +{
> + hpage_size = SAFE_READ_MEMINFO(MEMINFO_HPAGE_SIZE)*1024;
> +}
> +
> +static void cleanup(void)
> +{
> + if (fd > 0)
> + SAFE_CLOSE(fd);
> +}
> +
> +static struct tst_test test = {
> + .tags = (struct tst_tag[]) {
> + {"linux-git", "f2deae9d4e70793568ef9e85d227abb7bef5b622"},
We usually shorten the hash to first 12 characters however things should
work fine either way.
> + {}
> + },
> + .needs_root = 1,
> + .mntpoint = MNTPOINT,
> + .needs_hugetlbfs = 1,
> + .setup = setup,
> + .cleanup = cleanup,
> + .test_all = run_test,
> + .hugepages = {1, TST_NEEDS},
> +};
> --
> 2.31.1
>
--
Cyril Hrubis
chrubis@suse.cz
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2022-11-09 16:17 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-08 19:52 [LTP] [PATCH v2 0/5][PART 2] Hugetlb:Migrating the libhugetlbfs tests Tarun Sahu
2022-11-08 19:52 ` [LTP] [PATCH v2 1/5] Hugetlb: Migrating libhugetlbfs counters Tarun Sahu
2022-11-09 13:12 ` Cyril Hrubis
2022-11-09 21:26 ` Tarun Sahu
2022-11-10 8:20 ` Cyril Hrubis
2022-11-13 18:44 ` Tarun Sahu
2022-11-13 19:03 ` Tarun Sahu
2022-11-14 9:49 ` Cyril Hrubis
2022-11-14 18:51 ` Tarun Sahu
2022-11-08 19:52 ` [LTP] [PATCH v2 2/5] Hugetlb: Migrating libhugetlbfs directio Tarun Sahu
2022-11-09 13:25 ` Cyril Hrubis
2022-11-09 18:09 ` Tarun Sahu
2022-11-08 19:52 ` [LTP] [PATCH v2 3/5] Hugetlb: Migrating libhugetlbfs fadvise_reserve Tarun Sahu
2022-11-09 16:18 ` Cyril Hrubis [this message]
2022-11-09 18:40 ` Tarun Sahu
2022-11-10 7:34 ` Cyril Hrubis
2022-11-08 19:52 ` [LTP] [PATCH v2 4/5] Hugetlb: Migrating libhugetlbfs fallocate_align Tarun Sahu
2022-11-08 19:52 ` [LTP] [PATCH v2 5/5] Hugetlb: Migrating libhugetlbfs fallocate_basic Tarun Sahu
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=Y2vS0slepYtvWQBx@yuki \
--to=chrubis@suse.cz \
--cc=aneesh.kumar@linux.ibm.com \
--cc=geetika@linux.ibm.com \
--cc=ltp@lists.linux.it \
--cc=mike.kravetz@oracle.com \
--cc=sbhat@linux.ibm.com \
--cc=tsahu@linux.ibm.com \
--cc=vaibhav@linux.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.