[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201218203444.GS534@brightrain.aerifal.cx>
Date: Fri, 18 Dec 2020 15:34:48 -0500
From: Rich Felker <dalias@...c.org>
To: Markus Wichmann <nullplan@....net>
Cc: musl@...ts.openwall.com
Subject: Re: Musl on Cortex-M Devices
On Fri, Dec 18, 2020 at 08:38:49PM +0100, Markus Wichmann wrote:
> On Wed, Dec 16, 2020 at 07:23:49PM -0500, Rich Felker wrote:
> > On Wed, Dec 16, 2020 at 06:43:15PM -0500, Jesse DeGuire wrote:
> > > diff --git a/src/thread/arm/__unmapself.s b/src/thread/arm/__unmapself..s
> > > index 29c2d07b..fe0406e3 100644
> > > --- a/src/thread/arm/__unmapself.s
> > > +++ b/src/thread/arm/__unmapself.s
> > > @@ -3,7 +3,7 @@
> > > .global __unmapself
> > > .type __unmapself,%function
> > > __unmapself:
> > > - mov r7,#91
> > > + movs r7,#91
> > > svc 0
> > > - mov r7,#1
> > > + movs r7,#1
> > > svc 0
> >
> > OK, but this file can't be used on nommu anyway. Instead the generic C
> > version has to be used.
> >
>
> Speaking of that (C) version, maybe someone should note down somewhere
> that it is only safe to call if simultaneous calls from other threads
> are precluded somehow. That function uses global variables, so if
> multiple threads call it at the same time, there will be blood (well,
> there will be clobbering in any case). Which is fulfilled at the moment:
> The only call site of __unmapself() is pthread_exit(), after getting the
> thread list lock. That is a global lock, so further threads also
> exitting would have to queue up there. But I think it is rather
> non-intuitive that the thread-list lock happens to also protect the
> global variables in __unmapself.c. And that is a property of the C
> version not shared by the assembler versions, which are all thread-safe.
Prior to commit 8f11e6127fe93093f81a52b15bb1537edc3fc8af,
__unmapself.c had its own lock and had to explicitly modify the exit
futex address to unlock that lock. Now it can (and must, since neither
can be unlocked before the kernel-level task exits) share the thread
list lock for this purpose.
FWIW there's arguably no reason to even keep the asm versions of this
function now that the thread list lock exists. We could just remove
them all.
> Also, why can't this be used on nommu? I thought the only differences
> between nommu and mmu were that you can't call mmap() except for
> MAP_ANON, and you can't call fork(). This merely runs munmap() on a
> MAP_ANON region, and exit(), and so does the C version, except the C
> version sets up its own stack to do so, in order to not saw off the
> branch it is sitting on. What am I missing?
Most nommu cpu archs do not have hardware user/kernel stack switching
on interrupt. Instead the interrupt handler starts on the existing
stack. Linux immediately moves to the proper kernel stack at the entry
point, but one or more slots on the stack have already been written at
this point (either by hardware, or by necessity since there's no work
space to start switching to the kernel stack without spilling some
state).
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.
