summaryrefslogtreecommitdiff
path: root/debian/patches/20_zeromap.patch
blob: 726844836e0c2c6fdb24f9dbc54c636b8f1afa92 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
As discussed on IRC already, the 'diff != 0' GNU Mach assertion failure
(vm/vm_map.c:1002), that came in with the recent allocator improvement
patch, is as easy as follows to reproduce:

    vm_map(mach_task_self(), 0, 0, 0, 1, 0, 0, 0, 0, 0, 0);

Before that patch, GNU Mach accepted such a call and returnd 0 -- though
I did not check what effect it actually has.  (And I don't think it has
any useful one.)  I'm also reading that as of lately (Linux 2.6.12), mmap
with length = 0 is to return EINVAL; and mmap is, I think, the foremost
user of vm_map.

Richard wants to address this problem, but in the mean time, I'm using
the following patch, which makes such a vm_map call return
KERN_INVALID_ARGUMENT, translated to EINVAL for mmap
(hurd/hurd.h:__hurd_fail).

--- a/vm/vm_user.c~	2012-11-19 13:02:18.000000000 +0100
+++ b/vm/vm_user.c	2012-11-19 13:11:32.000000000 +0100
@@ -342,6 +342,10 @@ kern_return_t vm_map(
                 return(KERN_INVALID_ARGUMENT);
         }
 
+	/* Avoid 'diff != 0' assertion failure later on.  */
+	if (size == 0)
+		return KERN_INVALID_ARGUMENT;
+
 	*address = trunc_page(*address);
 	size = round_page(size);