Hi Rene,
On Fri, Aug 31, 2018 at 08:58:27AM +0000, Rene.Nielsen@xxxxxxxxxxxxx wrote:
> With the error-producing version of vdso-chk-X.patch applied, apply
> Paul's patch and run the 'provoke' program again.
>
> This also works.
Thanks - can I add your Tested-by?
> Paul's patch allocates twice the amount of needed VM, but I guess
> that's fine, as it's also less intrusive (no changes to mmap.c).
Note that get_unmapped_area() only finds an unmapped area - it doesn't
allocate it in the sense that further calls to get_unmapped_area() can
return the exact same memory. The actual use of the virtual address
ranges takes place when we call _install_special_mapping, and we still
use the same sizes there that we were before.
So my patch just causes us to look for a larger unmapped area (which
will typically be easy to find since we haven't even executed the
program yet), it doesn't actually use any more memory. We just find a
large area & then use only the part of it that we need to.
Since James' patch constrained get_unmapped_area() to look for a
suitably aligned piece of memory the result would have been much the
same - see the code in unmapped_area() where it also adds align_mask to
the length of the area we're looking for. It's just that with my patch
the alignment is being done by arch_setup_additional_pages() rather than
get_unmapped_area()/vm_unmapped_area(). That's not unprecedented either
- arch/nds32 already does something similar.
Thanks,
Paul
