linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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: Sat, 25 Mar 2017 17:44:58 +0530	[thread overview]
Message-ID: <4796e7df-808c-b07b-209d-ea02ecf74888@redhat.com> (raw)
In-Reply-To: <20170324181652.GC10746@leverpostej>



On Friday 24 March 2017 11:46 PM, Mark Rutland wrote:
>>> 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.
> That is troubling; I cannot explain that.

Can you pl try in an infinite loop for some time and see if "SIGSEGV" is 
received in any of the run at your end.

# while [[ 1 ]]; do  ./hugetlb_test_stack 536870912 
/mnt/hugetlbfs/test;done

>
>> 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.
> That might be because GDB disables ASLR by default. Did you re-enable
> ASLR within GDB with:
>
> 	set disable-randomization off
>
> If not, could you give that a go?

Yes, with ASLR enabled, it reproduced in GDB as well. I do not see 
SIGILL, it is SIGSEGV there too.

(gdb) set disable-randomization off
(gdb) b main
Breakpoint 1 at 0x400884
(gdb) r
Starting program: /home/panand/work/hugetlb/./hugetlb_test_stack 
536870912 /mnt/hugetlbfs/test

Breakpoint 1, 0x0000000000400884 in main ()
(gdb) info proc mappings
process 2949
Mapped address spaces:

           Start Addr           End Addr       Size     Offset objfile
             0x400000           0x410000    0x10000        0x0 
/home/panand/work/hugetlb/hugetlb_test_stack
             0x410000           0x420000    0x10000        0x0 
/home/panand/work/hugetlb/hugetlb_test_stack
             0x420000           0x430000    0x10000    0x10000 
/home/panand/work/hugetlb/hugetlb_test_stack
       0xffffada70000     0xffffadbd0000   0x160000        0x0 
/usr/lib64/libc-2.17.so
       0xffffadbd0000     0xffffadbe0000    0x10000   0x150000 
/usr/lib64/libc-2.17.so
       0xffffadbe0000     0xffffadbf0000    0x10000   0x160000 
/usr/lib64/libc-2.17.so
       0xffffadc10000     0xffffadc20000    0x10000        0x0 [vvar]
       0xffffadc20000     0xffffadc30000    0x10000        0x0 [vdso]
       0xffffadc30000     0xffffadc50000    0x20000        0x0 
/usr/lib64/ld-2.17.so
       0xffffadc50000     0xffffadc60000    0x10000    0x10000 
/usr/lib64/ld-2.17.so
       0xffffadc60000     0xffffadc70000    0x10000    0x20000 
/usr/lib64/ld-2.17.so
       0xffffcb1d0000     0xffffcb200000    0x30000        0x0 [stack]
(gdb) c
Continuing.
hpage_size is 20000000
file path is /mnt/hugetlbfs/test
stack_address is 0xffffcb1facc0
Address to be mapped is 0xffffa0000000

Program received signal SIGSEGV, Segmentation fault.
0x0000ffffadb45a44 in __mmap (addr=<optimized out>, len=536870912, 
prot=3, flags=17, fd=7, offset=0)
     at ../ports/sysdeps/unix/sysv/linux/aarch64/mmap.c:29
29        return (__ptr_t) INLINE_SYSCALL (mmap, 6, addr, len, prot, 
flags, fd, offset);
(gdb)

~Pratyush

  reply	other threads:[~2017-03-25 12:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-24 14:21 Query: ARM64: A random failure with hugetlbfs linked mmap() of a stack area Pratyush Anand
2017-03-24 16:15 ` Mark Rutland
2017-03-24 16:41   ` Pratyush Anand
2017-03-24 17:25     ` Mark Rutland
2017-03-24 18:02       ` Pratyush Anand
2017-03-24 18:16         ` Mark Rutland
2017-03-25 12:14           ` Pratyush Anand [this message]
2017-03-27 12:18             ` Mark Rutland
2017-03-27 13:20               ` Pratyush Anand
2017-03-27 17:45                 ` Mark Rutland

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4796e7df-808c-b07b-209d-ea02ecf74888@redhat.com \
    --to=panand@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).