linux-kernel - Re: [PATCH 1/2] mm: hugetlb: proc: check for hugetlb shared PMD in /proc/PID/smaps

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]

Message-ID: <Y9g/70m15SwxkLfc@monkey>
Date:   Mon, 30 Jan 2023 14:08:47 -0800
From:   Mike Kravetz <mike.kravetz@...cle.com>
To:     Michal Hocko <mhocko@...e.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        David Hildenbrand <david@...hat.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org,
        Naoya Horiguchi <naoya.horiguchi@...ux.dev>,
        James Houghton <jthoughton@...gle.com>,
        Peter Xu <peterx@...hat.com>, Yang Shi <shy828301@...il.com>,
        Vishal Moola <vishal.moola@...il.com>,
        Matthew Wilcox <willy@...radead.org>,
        Muchun Song <songmuchun@...edance.com>, stable@...r.kernel.org
Subject: Re: [PATCH 1/2] mm: hugetlb: proc: check for hugetlb shared PMD in
 /proc/PID/smaps

On 01/30/23 13:36, Michal Hocko wrote:
> On Fri 27-01-23 17:12:05, Mike Kravetz wrote:
> > On 01/27/23 15:04, Andrew Morton wrote:
> > > On Fri, 27 Jan 2023 17:23:39 +0100 David Hildenbrand <david@...hat.com> wrote:
> > > > On 26.01.23 23:27, Mike Kravetz wrote:
> 
> Yes, this looks simple enough. My only concern would be that this
> special casing might be required on other places which is hard to
> evaluate. I thought PSS reported by smaps would be broken as well but it
> seems pss is not really accounted for hugetlb mappings at all.
> 
> Have you tried to look into {in,de}creasing the map count of the page when
> the the pte is {un}shared for it?

A quick thought is that it would not be too difficult.  It would need
to include the following:
- At PMD share time in huge_pmd_share(),
  Go through all entries in the PMD, and increment map and ref count for
  all referenced pages.  huge_pmd_share is just adding another sharing
  process.
- At PMD unshare time in huge_pmd_unshare(),
  Go through all entries in the PMD, and decrement map and ref count for
  all referenced pages.  huge_pmd_unshare is just removing one sharing
  process.
- At page fault time, check if we are adding a new entry to a shared PMD.
  If yes, add 'num_of_sharing__processes - 1' to the ref and map count.

In each of the above operations, we are holding the PTL lock (which is
really the split/PMD lock) so synchronization should not be an issue.

Although I mention processes sharing the PMD above, it is really mappings/vmas
sharing the PMD.  You could have two mappings of the same object in the same
process sharing PMDs.

I'll code this up and see how it looks.

However, unless you have an objection I would prefer the simple patches
move forward, especially for stable backports.
-- 
Mike Kravetz