lkml.org 
[lkml]   [2017]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH 1/2] mm: introduce MAP_FIXED_SAFE
From
Date
On 11/20/2017 10:33 AM, Michal Hocko wrote:
> On Mon 20-11-17 10:10:32, Florian Weimer wrote:
>> On 11/20/2017 09:55 AM, Michal Hocko wrote:
>>> On Fri 17-11-17 08:30:48, Florian Weimer wrote:
>>>> On 11/16/2017 11:18 AM, Michal Hocko wrote:
>>>>> + if (flags & MAP_FIXED_SAFE) {
>>>>> + struct vm_area_struct *vma = find_vma(mm, addr);
>>>>> +
>>>>> + if (vma && vma->vm_start <= addr)
>>>>> + return -ENOMEM;
>>>>> + }
>>>>
>>>> Could you pick a different error code which cannot also be caused by a an
>>>> unrelated, possibly temporary condition? Maybe EBUSY or EEXIST?
>>>
>>> Hmm, none of those are described in the man page. I am usually very
>>> careful to not add new and potentially unexpected error codes but it is
>>
>> I think this is a bad idea. It leads to bizarre behavior, like open failing
>> with EOVERFLOW with certain namespace configurations (which have nothing to
>> do with file sizes).
>
> Ohh, I agree but breaking userspace is, you know, no-no. And an
> unexpected error codes can break things terribly.

On the glibc side, we see a lot of changes in error codes depending on
kernel version, build and run-time configuration. It never occurred to
me that you guys think the precise error code is part of the userspace
ABI. Personally, I even assume that failure itself can disappear at any
time (evidence: the f* functions which accept O_PATH in their non-*at
variants).

Thanks,
Florian

\
 
 \ /
  Last update: 2017-11-20 10:46    [W:0.152 / U:1.776 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site