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:   Mon, 24 Apr 2023 18:27:21 -0700
From:   Mike Kravetz <mike.kravetz@...cle.com>
To:     Sidhartha Kumar <sidhartha.kumar@...cle.com>
Cc:     linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        akpm@...ux-foundation.org, songmuchun@...edance.com,
        willy@...radead.org
Subject: Re: [RFC PATCH 0/4] change ->index to PAGE_SIZE for hugetlb pages

On 04/13/23 16:14, Sidhartha Kumar wrote:
> This RFC patch series attempts to simplify the page cache code by removing
> special casing code for hugetlb pages. Normal pages in the page cache are
> indexed by PAGE_SIZE while hugetlb pages are indexed by their huge page
> size. This was previously tried but the xarray was not performant enough
> for the changes.
> 
> This series fails many of the hugetlb LTP test cases due to bugs in
> accounting and I was hoping to get help/suggestions about why the page
> accounting breaks from my changes. The basic mmap tests pass but the
> advanced ones which involve overcommiting pages fail.

Sorry for the late reply.

I can appreciate the desire for removing hugetlb special cases from page
cache code.  As you note above, hugetlb tracks page indicies based on
huge pages size.  Page cache page indicies are based on base page size.

Within the hugetlb code, the huge page size indicies are used in at
least two places:
- huge page reservations.  There is a rather ugly set of code managing
  hugetlb mapping reservation maps.  Since a reservation is for a single
  huge page, it makes sense to use huge page sized indicies in this code.
- hugetlb mutex table.  The table is hashed by the values 'mapping' and
  index.  This guarantees that all code performing operations on a huge
  page will use the same mutex.  So, using huge page index is a must.

I think this means there is a need to maintain/use both huge page and
base page indicies.  huge page indicies within hugetlb code and base
page indicies within the page cache.

One approach might be to add the conversion from huge page inded to base
page index for all calls into the page cache.  This could be done with
hugetlb specific wrappers.  There already are hugetlb_add_to_page_cache,
hugetlbfs_pagecache_present, and hugetlb_delete_from_page_cache.
New wrappers would be needed for at least filemap_get_folios and
filemap_lock_folio.
-- 
Mike Kravetz

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ