lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 23 Nov 2021 18:19:29 -0800
From:   Yosry Ahmed <yosryahmed@...gle.com>
To:     Mike Kravetz <mike.kravetz@...cle.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Shuah Khan <shuah@...nel.org>, linux-mm@...ck.org,
        linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org,
        Mina Almasry <almasrymina@...gle.com>
Subject: Re: [PATCH] mm, hugepages: fix size in hugetlb mremap() test

On Tue, Nov 23, 2021 at 5:08 PM Mike Kravetz <mike.kravetz@...cle.com> wrote:
>
> On 11/23/21 12:46, Yosry Ahmed wrote:
> > The hugetlb vma mremap() test mentions in the header comment that it
> > uses 10MB worth of huge pages, when it actually uses 1GB. This causes
> > the test to fail on devices with smaller memories.
> >
> > Signed-off-by: Yosry Ahmed <yosryahmed@...gle.com>
> > ---
> >  tools/testing/selftests/vm/hugepage-mremap.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
>
> I'll let Mina comment, but I think I know what happened.

Thanks for taking the time to review this and explain what happened.

>
>
> The original version of the test did indeed use 10MB.  However, the mremap
> code must 'unshare' and shared pmd mappings before remapping.  Since sharing
> requires mappings of at least 1GB, the size was changed to make sure unsharing
> worked.
>
> In the end, I believe I suggested adding hugepage-mremap to run_vmtests.sh.
> The script does not try to configure a GB worth of huge pages.  And, I think
> it is somewhat unreasonable to suggest users gave a spare GB to run the test.

Alternatively, we can pass an optional argument to the test that makes it use
1GB instead of 10MB. This way, if the test is run with run_vmtests.sh the
default behavior would be to use 10MB, making sure users do not run out of
memory. Otherwise, an interested user could run the test without run_vmtest.sh
and provide the extra argument to make the test use 1GB and make sure that
unsharing works correctly. Thoughts?

>
> I'm OK with restoring the original value.
>
> Acked-by: Mike Kravetz <mike.kravetz@...cle.com>
> --
> Mike Kravetz

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ