[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 21 Dec 2020 19:00:02 -0500
From: Jesse DeGuire <jesse.a.deguire@...il.com>
To: musl@...ts.openwall.com
Cc: Markus Wichmann <nullplan@....net>
Subject: Re: Musl on Cortex-M Devices
On Fri, Dec 18, 2020 at 3:35 PM Rich Felker <dalias@...c.org> wrote:
>
> 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.
Should I just go ahead and remove this so the generic C version is
used instead since I'm already here?
-Jesse
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.
