Messages in this thread | | | Subject | Re: [RFC PATCH 1/2] mm: introduce MAP_FIXED_SAFE | From | Florian Weimer <> | Date | Mon, 20 Nov 2017 10:45:56 +0100 |
| |
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
| |