[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170130231321.GO1533@brightrain.aerifal.cx>
Date: Mon, 30 Jan 2017 18:13:21 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Fix pthread_create on some devices failing to initialize
guard area
On Mon, Jan 30, 2017 at 01:30:00PM -0800, Eric Hassold wrote:
> >>>>>This occurs because of call to mprotect() in pthread_create fails.
> >>>>>In current implementation, if guard size is non null, memory for
> >>>>>(guard + stack + ...) is first allocated (mmap'ed) with no
> >>>>>accessibility (PROT_NONE), then mprotect() is called to re-enable
> >>>>>read/write access to (memory + guardsize). Since call to mprotect()
> >>>>>systematically fails in this scenario (returning error code EINVAL),
> >>>>>it is impossible to create thread.
> >>>>Failure is ignored and the memory is assumed to be writable in this
> >>>>case, since EINVAL is assumed to imply no MMU. Is this assumption
> >>>>wrong in your case, and if so, can you explain why?
> >>>In my case, devices exhibiting issue are not MMU-less, they are
> >>>Cortex-A9 devices with valid mmu / page protection working as
> >>>expected otherwise. Note that current Musl code assumes ENOSYS means
> >>>no MMU and handles it by assuming the system has no page protection
> >>>at all. For the case I observe, it is EINVAL which is returned, this
> >>>is not ignored, so memory is unmap'ed and pthread_create() fails.
> >>In that case I think this is a kernel bug. Do you know why EINVAL is
> >>happening? If there's an MMU, Linux should be able to replace the
> >>anon PROT_NONE pages with anon RW pages.
> >
> >Agree. Unfortunately, those are devices we don't built the kernel
> >for, so have been hardly able to track issue deeper. The point is
> >however that such devices with this issue in kernel might not be
> >that uncommon, and it concretely means impossibility at that
> >moment to deploy on them a functional static executable built with
> >musl.
> [...]
> Pinging... any comment, feedback or concern about latest version of
> the patch, attached above, keeping current behavior but falling back
> to (mmap(PROT_READ|PROT_WRITE) && mprotect(guard, none)) if and only
> if current approach detected to fail) ?
I still want to know what's going on on the kernel side, because it
looks like this a rogue/nonsensical patch to the kernel that breaks
mmap functionality in a general way that has nothing to do with the
specific cpu/board.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
