bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fixing gnumachs vm_map


From: Samuel Thibault
Subject: Re: Fixing gnumachs vm_map
Date: Sun, 9 Nov 2014 23:56:37 +0100
User-agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)

Samuel Thibault, le Sat 06 Sep 2014 11:39:34 +0200, a écrit :
> Justus Winter, le Fri 05 Sep 2014 14:53:52 +0200, a écrit :
> > there is a bug affecting vm_map.  Contrary to the documentation,
> > address is not ignored if anywhere is given, leading to spurious
> > KERN_NO_SPACE errors.
> 
> Uh, that's bad indeed.
> 
> Apparently most of our source code copes with that by explicitly setting
> address to 0, but some places such as pager_memcpy don't.
> 
> I'm tempted to rather fix the behavior according to the documentation,
> and go with something like this:
> 
> diff --git a/vm/vm_user.c b/vm/vm_user.c
> index f7c87cc..f741705 100644
> --- a/vm/vm_user.c
> +++ b/vm/vm_user.c
> @@ -336,6 +336,9 @@ kern_return_t vm_map(
>       if (size == 0)
>               return KERN_INVALID_ARGUMENT;
>  
> +     if (anywhere)
> +             *address = 0;
> +
>       *address = trunc_page(*address);
>       size = round_page(size);
>  
> I don't see any place in our source code which would depend on 'address'
> being a hint for the map address. glibc's mmap() copes with the kernel
> behavior for instance.

Actually it seems the defpager does depend on the behavior, so I have
reverted the change in the debian gnumach=2:1.4+git20141109-1 package
for now, which fixes swapping out to disk.  I'll also upload a hurd
package with vm_map fixes according to the undocumented behavior, along
other packaging fixes.

Samuel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]