Michal Hocko <[email protected]> writes:
> On Wed 29-11-17 14:25:36, Kees Cook wrote:
>> On Wed, Nov 29, 2017 at 6:42 AM, Michal Hocko <[email protected]> wrote:
>> > The first patch introduced MAP_FIXED_SAFE which enforces the given
>> > address but unlike MAP_FIXED it fails with ENOMEM if the given range
>> > conflicts with an existing one. The flag is introduced as a completely
>>
>> I still think this name should be better. "SAFE" doesn't say what it's
>> safe from...
Yes exactly.
> It is safe in a sense it doesn't perform any address space dangerous
> operations. mmap is _inherently_ about the address space so the context
> should be kind of clear.
So now you have to define what "dangerous" means.
>> MAP_FIXED_UNIQUE
>> MAP_FIXED_ONCE
>> MAP_FIXED_FRESH
>
> Well, I can open a poll for the best name, but none of those you are
> proposing sound much better to me. Yeah, naming sucks...
I think Kees and I both previously suggested MAP_NO_CLOBBER for the
modifier.
So the obvious option for this would be MAP_FIXED_NO_CLOBBER.
Which is a bit longer sure, but says more or less exactly what it does.
cheers
On 2017-12-06 05:50, Michael Ellerman wrote:
> Michal Hocko <[email protected]> writes:
>
>> On Wed 29-11-17 14:25:36, Kees Cook wrote:
>> It is safe in a sense it doesn't perform any address space dangerous
>> operations. mmap is _inherently_ about the address space so the context
>> should be kind of clear.
>
> So now you have to define what "dangerous" means.
>
>>> MAP_FIXED_UNIQUE
>>> MAP_FIXED_ONCE
>>> MAP_FIXED_FRESH
>>
>> Well, I can open a poll for the best name, but none of those you are
>> proposing sound much better to me. Yeah, naming sucks...
I also don't like the _SAFE name - MAP_FIXED in itself isn't unsafe [1],
but I do agree that having a way to avoid clobbering (parts of) an
existing mapping is quite useful. Since we're bikeshedding names, how
about MAP_FIXED_EXCL, in analogy with the O_ flag.
[1] I like the analogy between MAP_FIXED and dup2 made in
<stackoverflow.com/questions/28575893>.
Rasmus
On Wed 06-12-17 08:33:37, Rasmus Villemoes wrote:
> On 2017-12-06 05:50, Michael Ellerman wrote:
> > Michal Hocko <[email protected]> writes:
> >
> >> On Wed 29-11-17 14:25:36, Kees Cook wrote:
> >> It is safe in a sense it doesn't perform any address space dangerous
> >> operations. mmap is _inherently_ about the address space so the context
> >> should be kind of clear.
> >
> > So now you have to define what "dangerous" means.
> >
> >>> MAP_FIXED_UNIQUE
> >>> MAP_FIXED_ONCE
> >>> MAP_FIXED_FRESH
> >>
> >> Well, I can open a poll for the best name, but none of those you are
> >> proposing sound much better to me. Yeah, naming sucks...
>
> I also don't like the _SAFE name - MAP_FIXED in itself isn't unsafe [1],
> but I do agree that having a way to avoid clobbering (parts of) an
> existing mapping is quite useful. Since we're bikeshedding names, how
> about MAP_FIXED_EXCL, in analogy with the O_ flag.
I really give up on the name discussion. I will take whatever the
majority comes up with. I just do not want this (useful) funtionality
get bikeched to death.
--
Michal Hocko
SUSE Labs
On Wed, Dec 6, 2017 at 1:08 AM, Michal Hocko <[email protected]> wrote:
> On Wed 06-12-17 08:33:37, Rasmus Villemoes wrote:
>> On 2017-12-06 05:50, Michael Ellerman wrote:
>> > Michal Hocko <[email protected]> writes:
>> >
>> >> On Wed 29-11-17 14:25:36, Kees Cook wrote:
>> >> It is safe in a sense it doesn't perform any address space dangerous
>> >> operations. mmap is _inherently_ about the address space so the context
>> >> should be kind of clear.
>> >
>> > So now you have to define what "dangerous" means.
>> >
>> >>> MAP_FIXED_UNIQUE
>> >>> MAP_FIXED_ONCE
>> >>> MAP_FIXED_FRESH
>> >>
>> >> Well, I can open a poll for the best name, but none of those you are
>> >> proposing sound much better to me. Yeah, naming sucks...
>>
>> I also don't like the _SAFE name - MAP_FIXED in itself isn't unsafe [1],
>> but I do agree that having a way to avoid clobbering (parts of) an
>> existing mapping is quite useful. Since we're bikeshedding names, how
>> about MAP_FIXED_EXCL, in analogy with the O_ flag.
>
> I really give up on the name discussion. I will take whatever the
> majority comes up with. I just do not want this (useful) funtionality
> get bikeched to death.
Yup, I really want this to land too. What do people think of Matthew
Wilcox's MAP_REQUIRED ? MAP_EXACT isn't exact, and dropping "FIXED"
out of the middle seems sensible to me.
MIchael, any suggestions with your API hat on?
-Kees
--
Kees Cook
Pixel Security
On 12/06/2017 04:19 PM, Kees Cook wrote:
> On Wed, Dec 6, 2017 at 1:08 AM, Michal Hocko <[email protected]> wrote:
>> On Wed 06-12-17 08:33:37, Rasmus Villemoes wrote:
>>> On 2017-12-06 05:50, Michael Ellerman wrote:
>>>> Michal Hocko <[email protected]> writes:
>>>>
>>>>> On Wed 29-11-17 14:25:36, Kees Cook wrote:
>>>>> It is safe in a sense it doesn't perform any address space dangerous
>>>>> operations. mmap is _inherently_ about the address space so the context
>>>>> should be kind of clear.
>>>>
>>>> So now you have to define what "dangerous" means.
>>>>
>>>>>> MAP_FIXED_UNIQUE
>>>>>> MAP_FIXED_ONCE
>>>>>> MAP_FIXED_FRESH
>>>>>
>>>>> Well, I can open a poll for the best name, but none of those you are
>>>>> proposing sound much better to me. Yeah, naming sucks...
>>>
>>> I also don't like the _SAFE name - MAP_FIXED in itself isn't unsafe [1],
>>> but I do agree that having a way to avoid clobbering (parts of) an
>>> existing mapping is quite useful. Since we're bikeshedding names, how
>>> about MAP_FIXED_EXCL, in analogy with the O_ flag.
>>
>> I really give up on the name discussion. I will take whatever the
>> majority comes up with. I just do not want this (useful) funtionality
>> get bikeched to death.
>
> Yup, I really want this to land too. What do people think of Matthew
> Wilcox's MAP_REQUIRED ? MAP_EXACT isn't exact, and dropping "FIXED"
> out of the middle seems sensible to me.
+1, MAP_REQUIRED does sound like the best one so far, yes. Sorry if I contributed
to any excessive bikeshedding. :)
thanks,
john h
>
> MIchael, any suggestions with your API hat on?
>
> -Kees
>