linux-kernel - Re: [PATCH v1] mm: Add /proc/$PID/pageflags

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 2 Nov 2021 12:42:40 +0100
From:   David Hildenbrand <david@...hat.com>
To:     Mina Almasry <almasrymina@...gle.com>
Cc:     Nathan Lewis <npl@...gle.com>, Yu Zhao <yuzhao@...gle.com>,
        "Paul E . McKenney" <paulmckrcu@...com>,
        Jonathan Corbet <corbet@....net>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Peter Xu <peterx@...hat.com>,
        Ivan Teterevkov <ivan.teterevkov@...anix.com>,
        Florian Schmidt <florian.schmidt@...anix.com>,
        linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-mm@...ck.org
Subject: Re: [PATCH v1] mm: Add /proc/$PID/pageflags

>> Bit 58-60 are still free, no? Bit 57 was recently added for uffd-wp
>> purposes I think.
>>
>> #define PM_SOFT_DIRTY           BIT_ULL(55)
>> #define PM_MMAP_EXCLUSIVE       BIT_ULL(56)
>> #define PM_UFFD_WP              BIT_ULL(57)
>> #define PM_FILE                 BIT_ULL(61)
>> #define PM_SWAP                 BIT_ULL(62)
>> #define PM_PRESENT              BIT_ULL(63)
>>
>> PM_MMAP_EXCLUSIVE and PM_FILE already go into the direction of "what is
>> mapped" IMHO. So just a thought if something in there (PM_HUGE? PM_THP?)
>> ... could make sense.
>>
> 
> Thanks! I _think_ that would work for us, I'll look into confirming.
> To be honest I still wonder if eventually different folks will find
> uses for other page flags and eventually we'll run out of pagemaps
> bits, but I'll yield to whatever you think is best here.

Using one of the remaining 3 bits should be fine. In the worst case,
we'll need pagemap_ext at some point that provides more bits per PFN, if
we ever run out of bits.

But as mentioned by Matthew, extending mincore() could also work: not
only indicating if the page is resident, but also in which "form" it is
resident.

We could separate the cases "cont PTE huge page" vs. "PMD huge page".

I recall that the information (THP / !THP) might be valuable for users:
there was a discussion to let user space decide where to place THP.
(IIRC madvise() extension to have something like MADV_COLLAPSE_THP /
MADV_DISSOLVE_THP)

-- 
Thanks,

David / dhildenb