linux-kernel - Re: [PATCH] hugetlbfs: zero partial pages during fallocate hole punch

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] [day] [month] [year] [list]

Date:   Tue, 14 Jun 2022 23:03:55 +0800
From:   Muchun Song <songmuchun@...edance.com>
To:     Mike Kravetz <mike.kravetz@...cle.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Linux Memory Management List <linux-mm@...ck.org>,
        David Hildenbrand <david@...hat.com>,
        Naoya Horiguchi <naoya.horiguchi@...ux.dev>,
        Axel Rasmussen <axelrasmussen@...gle.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Michal Hocko <mhocko@...e.com>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] hugetlbfs: zero partial pages during fallocate hole punch

On Tue, Jun 14, 2022 at 4:46 AM Mike Kravetz <mike.kravetz@...cle.com> wrote:
>
> Below is v2 of the patch.  I was just going to change the type of start/end
> hugetlbfs_zero_partial_page arguments.  However, Matthew also convinced me
> to do the simple folio conversion.  Tested with new libhugetlbfs code.
>
>
> From 36a18e0b07c2e189092cc2d516e8cfedcb57d191 Mon Sep 17 00:00:00 2001
> From: Mike Kravetz <mike.kravetz@...cle.com>
> Date: Mon, 13 Jun 2022 13:36:48 -0700
> Subject: [Patch v2] hugetlbfs: zero partial pages during fallocate hole punch
>
> hugetlbfs fallocate support was originally added with commit 70c3547e36f5
> ("hugetlbfs: add hugetlbfs_fallocate()").  Initial support only operated
> on whole hugetlb pages.  This makes sense for populating files as other
> interfaces such as mmap and truncate require hugetlb page size alignment.
> Only operating on whole hugetlb pages for the hole punch case was a
> simplification and there was no compelling use case to zero partial pages.
>
> In a recent discussion[1] it was assumed that hugetlbfs hole punch would
> zero partial hugetlb pages as that is in line with the man page
> description saying 'partial filesystem  blocks  are  zeroed'.  However,
> the hugetlbfs hole punch code actually does this:
>
>         hole_start = round_up(offset, hpage_size);
>         hole_end = round_down(offset + len, hpage_size);
>
> Modify code to zero partial hugetlb pages in hole punch range.  It is
> possible that application code could note a change in behavior.  However,
> that would imply the code is passing in an unaligned range and expecting
> only whole pages be removed.  This is unlikely as the fallocate
> documentation states the opposite.
>
> The current hugetlbfs fallocate hole punch behavior is tested with the
> libhugetlbfs test fallocate_align[2].  This test will be updated to
> validate partial page zeroing.
>
> [1] https://lore.kernel.org/linux-mm/20571829-9d3d-0b48-817c-b6b15565f651@redhat.com/
> [2] https://github.com/libhugetlbfs/libhugetlbfs/blob/master/tests/fallocate_align.c
>
> Signed-off-by: Mike Kravetz <mike.kravetz@...cle.com>

LGTM.

Reviewed-by: Muchun Song <songmuchun@...edance.com>

Thanks.