linux-kernel - Re: [PATCH v2] mmap.2: MAP_FIXED updated documentation

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] [day] [month] [year] [list]

Message-ID: <8b9de658-81f4-f09b-cc7d-cef8ea0bd1ff@nvidia.com>
Date:   Sat, 9 Dec 2017 23:44:29 -0800
From:   John Hubbard <jhubbard@...dia.com>
To:     Pavel Machek <pavel@....cz>, Michal Hocko <mhocko@...nel.org>
CC:     Cyril Hrubis <chrubis@...e.cz>,
        Michael Kerrisk <mtk.manpages@...il.com>,
        linux-man <linux-man@...r.kernel.org>,
        <linux-api@...r.kernel.org>, Michael Ellerman <mpe@...erman.id.au>,
        <linux-mm@...ck.org>, LKML <linux-kernel@...r.kernel.org>,
        <linux-arch@...r.kernel.org>, Jann Horn <jannh@...gle.com>,
        Matthew Wilcox <willy@...radead.org>
Subject: Re: [PATCH v2] mmap.2: MAP_FIXED updated documentation

On 12/09/2017 09:19 AM, Pavel Machek wrote:
> On Thu 2017-12-07 15:02:21, Michal Hocko wrote:
>> On Thu 07-12-17 13:58:05, Cyril Hrubis wrote:
>>> Hi!
>>>>>> (It does seem unfortunate that the man page cannot help the programmer
>>>>>> actually write correct code here. He or she is forced to read the kernel
>>>>>> implementation, in order to figure out the true alignment rules. I was
>>>>>> hoping we could avoid that.)
>>>>>
>>>>> It would be nice if we had this information exported somehere so that we
>>>>> do not have to rely on per-architecture ifdefs.
>>>>>
>>>>> What about adding MapAligment or something similar to the /proc/meminfo?
>>>>>
>>>>
>>>> What's the use case you envision for that? I don't see how that would be
>>>> better than using SHMLBA, which is available at compiler time. Because 
>>>> unless someone expects to be able to run an app that was compiled for 
>>>> Arch X, on Arch Y (surely that's not requirement here?), I don't see how
>>>> the run-time check is any better.
>>>
>>> I guess that some kind of compile time constant in uapi headers will do
>>> as well, I'm really open to any solution that would expose this constant
>>> as some kind of official API.
>>
>> I am not sure this is really feasible. It is not only a simple alignment
>> thing. Look at ppc for example (slice_get_unmapped_area). Other
>> architectures might have even more complicated rules e.g. arm and its
>> cache_is_vipt_aliasing. Also this applies only on MAP_SHARED || file
>> backed mappings.
>>
>> I would really leave dogs sleeping... Trying to document all this in the
>> man page has chances to confuse more people than it has chances to help
>> those who already know all these nasty details.
> 
> You don't have to provide all the details, but warning that there's arch-
> specific magic would be nice...

Hi Pavel,

In version 4 of this patch (which oddly enough, I have trouble finding via
google, it only seems to show up in patchwork.kernel.org [1]), I phrased it 
like this:

    Don't interpret addr as a hint: place the mapping at  exactly  that
    address.   addr  must be suitably aligned: for most architectures a
    multiple of page size is sufficient;  however,  some  architectures
    may  impose additional restrictions. 

...which is basically what Cyril was asking for, in his early feedback.
Does that work for you?

(Maybe I need to repost that patch. In any case the CC's need updating,
at least.)

[1] https://patchwork.kernel.org/patch/10094905/

thanks,
-- 
John Hubbard
NVIDIA

> 								Pavel
> 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>