On 11/20/2017 10:33 AM, Michal Hocko wrote:

On Mon 20-11-17 10:10:32, Florian Weimer wrote:

quoted

On 11/20/2017 09:55 AM, Michal Hocko wrote:

quoted

On Fri 17-11-17 08:30:48, Florian Weimer wrote:

quoted

On 11/16/2017 11:18 AM, Michal Hocko wrote:

quoted

+	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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>