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

From: panand@redhat.com (Pratyush Anand)
To: linux-arm-kernel@lists.infradead.org
Subject: Query: ARM64: A random failure with hugetlbfs linked mmap() of a stack area
Date: Mon, 27 Mar 2017 18:50:53 +0530	[thread overview]
Message-ID: <dfddf8fa-6e61-9d94-46ef-34bad1c8c632@redhat.com> (raw)
In-Reply-To: <20170327121806.GA12578@leverpostej>

Hi Mark,

Thanks a lot for your explanations!!

On Monday 27 March 2017 05:48 PM, Mark Rutland wrote:
> So far, I have not managed to trigger a single SIGSEGV while running
> under GDB.
>
> However, I have a theory that could explain that. I suspect that my
> toolchain has built the binary with an executable stack, while yours has
> not. Linux automatically sets READ_IMPLIES_EXEC for binaries with
> executable stacks, which IIUC would implicitly make the mmap RWX rather
> than RW.
>
> So in my case, the huge page is executable, and I get a SIGILL when
> trying to execute from it. In your case, the huge page is not
> executable, so you get a SIGSEGV.

Yes, your theory seems  convincing.
I passed PROT_EXEC as well along with PROT_READ|PROT_WRITE to mmap(),and 
then I received SIGILL.

[...]

>> Program received signal SIGSEGV, Segmentation fault.
>> 0x0000ffffadb45a44 in __mmap (addr=<optimized out>, len=536870912,
>> prot=3, flags=17, fd=7, offset=0)
> That address falls within libc-2.17.so, which is clobbered by the mmap.
>
> Do you happen to know how to parse that 'prot=3' in the SEGV report? I'm
> guessing that means RW, !X.

Yes, it seems like that.

https://sourceware.org/git/?p=glibc.git;a=blob;f=bits/mman-linux.h;h=8126ce836947718576f09cd8f874a25b2c1340f7;hb=HEAD

~Pratyush