linux-kernel - Re: [PATCH] mm,hugetlb: compute page_size

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:   Thu, 9 Mar 2017 08:54:55 +0530
From:   Anshuman Khandual <khandual@...ux.vnet.ibm.com>
To:     Andi Kleen <ak@...ux.intel.com>,
        Davidlohr Bueso <dave@...olabs.net>
Cc:     akpm@...ux-foundation.org, mhocko@...e.com, mtk.manpages@...il.com,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Davidlohr Bueso <dbueso@...e.de>
Subject: Re: [PATCH] mm,hugetlb: compute page_size_log properly

On 03/09/2017 01:09 AM, Andi Kleen wrote:
>> One example of the problems with extra layers what this patch fixes:
>> mmap_pgoff() should never be using SHM_HUGE_* logic. This was
>> introduced by:
>>
>>    091d0d55b28 (shm: fix null pointer deref when userspace specifies invalid hugepage size)
>>
>> It is obviously harmless but lets just rip out the whole thing --
>> the shmget.2 manpage will need updating, as it should not be
>> describing kernel internals.
> 
> The SHM_* defines were supposed to be exported to user space,
> but somehow they didn't make it into uapi.

Yeah, its not part of UAPI which it should have been. Now we
need to ilog2(page_size) and shift it before using them in
the user space. BTW, mmap() interface also would want this
encoding should we choose to use non default HugeTLB page
sizes.

> 
> But something like this is useful, it's a much nicer 
> interface for users than to hard code the bit position

Right. But as we need this both for shm and mmap() interface,
we can only have one set of values exported to the UAPI. The
other set needs to be removed IMHO. BTW, we need to add the
encoding for other arch supported HugeTLB supported sizes as
well like 16MB, 16GB etc (on POWER).

> 
> So I would rather if you move it to uapi instead of 
> removing. What the kernel uses internally doesn't
> really matter.

Had a sent a clean up patch last year which unfortunately I
forgot to resend though it has got ACK from Michal Hocko
and Balbir Singh.

https://lkml.org/lkml/2016/4/7/43

I had also tried to add POWER HugeTLB size encoding in the
arch specific header files. Probably its time to move all
of them to generic header.

https://lkml.org/lkml/2016/4/7/48