Hi Rene,
On Fri, Aug 31, 2018 at 08:58:27AM +0000, Rene.Nielsen@microchip.com 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