mremap and "negative" addresses

mremap, like mmap, can return addresses in region 4 which are "negative" (when interpreted as signed values) and thus interpreted as syscall failure. The following patch implements the same workaround as for mmap and other such syscalls.

(It looks like 2.5 also has the same issue, if this seems sensible I can produce a patch for that as well.)

Matt

diff -ru linux-2.4.19-020821.orig/arch/ia64/kernel/entry.S linux-2.4.19-020821/arch/ia64/kernel/entry.S
@@ -1109,7 +1109,7 @@
 	data8 sys_mlock
 	data8 sys_mlockall
 	data8 sys_mprotect			// 1155
-	data8 sys_mremap
+	data8 ia64_mremap
 	data8 sys_msync
 	data8 sys_munlock
 	data8 sys_munlockall

diff -ru linux-2.4.19-020821.orig/arch/ia64/kernel/sys_ia64.c linux-2.4.19-020821/arch/ia64/kernel/sys_ia64.c
@@ -253,6 +253,21 @@
 	return addr;
 }
 
+asmlinkage unsigned long
+ia64_mremap (unsigned long addr, unsigned long old_len, unsigned long new_len, unsigned long flags,
+	     unsigned long new_addr, long arg5, long arg6, long arg7, long stack)
+{
+	struct pt_regs *regs = (struct pt_regs *) &stack;
+
+	down_write(&current->mm->mmap_sem);
+	addr = do_mremap(addr, old_len, new_len, flags, new_addr);
+	up_write(&current->mm->mmap_sem);
+
+	if (!IS_ERR((void *) addr))
+		regs->r8 = 0;	/* ensure large addresses are not mistaken as failures... */
+	return addr;
+}
+
 asmlinkage long
 sys_vm86 (long arg0, long arg1, long arg2, long arg3)
 {

diff -ru linux-2.4.19-020821.orig/include/linux/mm.h linux-2.4.19-020821/include/linux/mm.h
@@ -559,8 +559,10 @@
 }
 
 extern int do_munmap(struct mm_struct *, unsigned long, size_t);
-
 extern unsigned long do_brk(unsigned long, unsigned long);
+extern unsigned long do_mremap(unsigned long addr,
+	unsigned long old_len, unsigned long new_len,
+	unsigned long flags, unsigned long new_addr);
 
 static inline void __vma_unlink(struct mm_struct * mm, struct vm_area_struct * vma, struct vm_area_struct * prev)
 {

hmm.. x86 handles this kind of thing by comparing against (unsigned long)-125 instead. any reason we can't do the same?

i also notice that sys_fcntl has no workaround:

case F_GETOWN:
/*
* XXX If f_owner is a process group, the
* negative return value will get converted
* into an error. Oops. If we keep the
* current syscall conventions, the only way
* to fix this will be in libc. */
err = filp->f_owner.pid;
break;

or is the workaround for this in libc?

Revolutions do not require corporate support.

Matthew> hmm.. x86 handles this kind of thing by comparing against Matthew> (unsigned long)-125 instead. any reason we can't do the Matthew> same?

Because on ia64 (like on Alpha, for example), there _is_ a clean mechanism to return an error status and an error code at the syscall level.

Matthew> i also notice that sys_fcntl has no workaround:

That looks like a bug.

Both for mremap() and F_GETOWN, we should use the macro force_successful_syscall_return() (not that this is an accepted macro yet, but it makes the intention much clearer).

	--david