> From: "Theo de Raadt" <[email protected]> > Date: Wed, 18 May 2022 10:05:03 -0600 > > David Gwynne <[email protected]> wrote: > > > from yet another perspective, broad use of a common lock can end up > > hurting in the long run because you may end up where everything is > > serialised and you have to go back and do a ton of work again anyway. > > > > > I think the theory is ps_kbind_addr is fixed to a shared address space > > > in "pr", if you are threaded there is only one ps_kbind_addr for all the > > > processes "p" sharing that address space. > > > > yes. > > > > > And execve() uses single_thread_set, which means you can't race? > > > > also yes. the value starts at 0, updates are serialised by the > > mutex, and the updates don't produce invalid intermediate state. > > so what is the mutex for? Is this being over-designed? > > On a shared address space, ld.so will be entered before we thread, > straight out of execve. I don't think we have constructors starting > threads, that would be very bad right?
Unfortunately code exists that creates threads in constructors. At least that was the conclusion when we had a very similar discussion some months ago. It's a seriously bad idea, but the code that actually does this probably does even worse things. > So there are two cases -- static binary and dynaamic. On one address space, > kbind is only called once, and there is only one attempt, and any other > attempt should kill you, because you are doing it manual & wrong. <-- is > this correct, guenther? So in the dynamic case there may be multiple parallel calls to kbind(). They should all come from the same address though, unless someone is doing something deliberately nasty.
