Query: ARM64: A random failure with hugetlbfs linked mmap() of a stack area

[panand@redhat.com (Pratyush Anand)]

On Friday 24 March 2017 10:55 PM, Mark Rutland wrote:
>> Moreover, even if mmap() in test routine crosses over many other
>> text/rd/rw area mappings, should it fail? We are not writing
>> anything to mmaped area. So, why should just a creation of another
>> map result in segmentation fault?
> The new mapping replaces the old mappings that it clobbers, so all the
> old data/code is gone. Loads or instruction fetches will see data from
> the new mapping.
>

Humm..I see..But in that case mmap() should have failed and return 
MAP_FAILED instead of remapping and which could cause a segfault.
I see that upstream test case, has mmap() in a loop and it goes further 
only with a successful mapping. So, if it would have failed then 
probably test would have tried next address for mmaping until it would 
have touched heap area.

> In my case, since the libc code was clobbered, the CPU tried to execute
> the zeroes it was clobbered with, and took an illegal instruction abort.
>
> For your report, it's not clear to me what's going on. Did you take the
> /proc/pid/maps data from teh exact same process that the segfault
> occurred in? and/or did you disable ASLR?

Yes, it is from the same process. Since, I was not able to reproduce 
with gdb so, I had inserted a scanf() just before mmap() and then had 
read /proc/pid/maps.

~Pratyush