From: John Hubbard <jhubbard@nvidia.com>
To: Pavel Machek <pavel@ucw.cz>, Michal Hocko <mhocko@kernel.org>
Cc: Cyril Hrubis <chrubis@suse.cz>,
Michael Kerrisk <mtk.manpages@gmail.com>,
linux-man <linux-man@vger.kernel.org>,
<linux-api@vger.kernel.org>,
Michael Ellerman <mpe@ellerman.id.au>, <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>, <linux-arch@vger.kernel.org>,
Jann Horn <jannh@google.com>,
Matthew Wilcox <willy@infradead.org>
Subject: Re: [PATCH v2] mmap.2: MAP_FIXED updated documentation
Date: Sat, 9 Dec 2017 23:44:29 -0800 [thread overview]
Message-ID: <8b9de658-81f4-f09b-cc7d-cef8ea0bd1ff@nvidia.com> (raw)
In-Reply-To: <20171209171958.GB19862@localhost>
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
>
next prev parent reply other threads:[~2017-12-10 7:44 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-04 2:14 [PATCH v2] mmap.2: MAP_FIXED updated documentation john.hubbard
2017-12-04 10:55 ` Cyril Hrubis
2017-12-05 2:14 ` John Hubbard
2017-12-05 7:05 ` Michal Hocko
2017-12-05 7:42 ` John Hubbard
2017-12-05 8:52 ` Michal Hocko
2017-12-06 10:01 ` Cyril Hrubis
2017-12-06 21:21 ` John Hubbard
2017-12-07 12:58 ` Cyril Hrubis
2017-12-07 14:02 ` Michal Hocko
2017-12-09 17:19 ` Pavel Machek
2017-12-10 7:44 ` John Hubbard [this message]
2017-12-04 11:31 ` Mike Rapoport
2017-12-05 2:52 ` John Hubbard
2017-12-05 7:08 ` Michal Hocko
2017-12-05 7:43 ` John Hubbard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8b9de658-81f4-f09b-cc7d-cef8ea0bd1ff@nvidia.com \
--to=jhubbard@nvidia.com \
--cc=chrubis@suse.cz \
--cc=jannh@google.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=mtk.manpages@gmail.com \
--cc=pavel@ucw.cz \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).