linux-kernel - Re: [RFC PATCH 3/3] mm: shm: Use new hugetlb size encoding definitions

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:   Wed, 26 Jul 2017 10:39:30 -0700
From:   Mike Kravetz <mike.kravetz@...cle.com>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Matthew Wilcox <willy@...radead.org>,
        akpm@...ux-foundation.org, ak@...ux.intel.com,
        mtk.manpages@...il.com, Davidlohr Bueso <dbueso@...e.de>,
        khandual@...ux.vnet.ibm.com, aneesh.kumar@...ux.vnet.ibm.com,
        aarcange@...hat.com
Subject: Re: [RFC PATCH 3/3] mm: shm: Use new hugetlb size encoding
 definitions

On 07/26/2017 03:07 AM, Michal Hocko wrote:
> On Wed 26-07-17 11:53:38, Michal Hocko wrote:
>> On Mon 17-07-17 15:28:01, Mike Kravetz wrote:
>>> Use the common definitions from hugetlb_encode.h header file for
>>> encoding hugetlb size definitions in shmget system call flags.  In
>>> addition, move these definitions to the from the internal to user
>>> (uapi) header file.
>>
>> s@to the from@...m@
>>
>>>
>>> Suggested-by: Matthew Wilcox <willy@...radead.org>
>>> Signed-off-by: Mike Kravetz <mike.kravetz@...cle.com>
>>
>> with s@...ETLB_FLAG_ENCODE__16GB@...ETLB_FLAG_ENCODE_16GB@
>>
>> Acked-by: Michal Hocko <mhocko@...e.com>
> 
> Btw. man page mentions only 2MB and 1GB, we should document others and
> note that each arch might support only subset of them

Thanks for looking at these Michal.
BTW, those definitions below are wrong.  They should be SHM_HUGE_*. :(

In the overview of this RFC, I mentioned still needing to address the
comment from Aneesh about splitting SHM_HUGE_* definitions into arch
specific header files.  This is how it is done for mmap.  If an arch
supports multiple huge page sizes, the 'asm/mman.h' contains definitions
for those sizes.  There will be a bit of churn (such as header file
renaming) to do this for shm as well.  So, I keep going back and forth
asking myself 'is it worth it'?  Some things to consider.

- We should be consistent between mmap and shm.  Also remember, that I
  will propose adding the same type of encoding to memfd_create.  So,
  three system calls will use the encoding.  They should be consistent.
- Adding the arch specific definitions seems the 'most correct', as a
  user can not use a definition not supported by the arch.  However,
  even if an arch supports a huge page size it does not mean that the
  running kernel supports that size.  Therefore, the folllowing is in
  the man page.
  "The  range  of  huge page sizes that are supported by the system
   can be discovered by listing  the  subdirectories  in
   /sys/kernel/mm/hugepages."
- Another alternative is to make all known huge page sizes available
  to all users.  This is 'easier' as the definitions can likely reside
  in a common header file.  The user will  need to determine what
  huge page sizes are supported by the running kernel as mentioned in
  the man page.

Any thoughts/suggestions on these alternatives?  I'll send out another
patch set based on comments.  In any case, I think mmap and shm need to
be the same.
-- 
Mike Kravetz

>>> +#define MAP_HUGE_512KB	HUGETLB_FLAG_ENCODE_512KB
>>> +#define MAP_HUGE_1MB	HUGETLB_FLAG_ENCODE_1MB
>>> +#define MAP_HUGE_2MB	HUGETLB_FLAG_ENCODE_2MB
>>> +#define MAP_HUGE_8MB	HUGETLB_FLAG_ENCODE_8MB
>>> +#define MAP_HUGE_16MB	HUGETLB_FLAG_ENCODE_16MB
>>> +#define MAP_HUGE_1GB	HUGETLB_FLAG_ENCODE_1GB
>>> +#define MAP_HUGE_16GB	HUGETLB_FLAG_ENCODE__16GB