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]

Message-ID: <20170727075051.GJ20970@dhcp22.suse.cz>
Date:   Thu, 27 Jul 2017 09:50:51 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Mike Kravetz <mike.kravetz@...cle.com>
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 Wed 26-07-17 10:39:30, Mike Kravetz wrote:
> 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_*. :(

Ups, and I completely missed that.

> 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'?

Why cannot we use a generic header? Btw. I think it would be better for
MMAP definitions as well.

> 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.

agreed

> - 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."

Doesn't the respective call return -EINVAL on the unsupported hugepage
size?

> - 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.

yes I think this makes more sense.
-- 
Michal Hocko
SUSE Labs