Re: [PATCH] Inconsistent mmap()/mremap() flags

[Andi Kleen <andi@firstfloor.org>]

> @@ -388,6 +392,9 @@
>  			if (vma->vm_flags & VM_MAYSHARE)
>  				map_flags |= MAP_SHARED;
>  
> +			if (flags & MAP_32BIT)
> +				map_flags |= MAP_32BIT;
> +
>  			new_addr = get_unmapped_area(vma->vm_file, 0, new_len,
>  						vma->vm_pgoff, map_flags);
>  			ret = new_addr;

That's not enough -- you would also need to fail the mremap when the result
is > 2GB (MAP_32BIT is actually a MAP_31BIT) 

But that would be ugly to implement without a new architecture wrapper
or better changing arch_get_unmapped_area()

It might be better to just not bother. MAP_32BIT is a kind of hack anyways
that at least for mmap can be easily emulated in user space anyways.
Given for mremap() it is not that easy because there is no "hint" argument
without MREMAP_FIXED; but unless someone really needs it i would prefer
to not propagate the hack. If it's really needed it's probably better
to implement a start search hint for mremap()

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/