> From: Philip Guenther <[email protected]> > Date: Wed, 15 Jun 2022 10:07:06 -0900 > > On Mon, 13 Jun 2022, Theo de Raadt wrote: > > Scott Cheloha <[email protected]> wrote: > > > > Am I wrong that kbind is never called twice in the same address space? > > > > > > Isn't this exactly what happened the last time we tried this? > > > > Tried what? kbind has never been NOLOCK. > > Scott's referring to rev 1.237 of kern_fork.c, where we tried to require the > first use of kbind be before __tfork(2) was called. This blew up because > there's at least two ways to legitimately call pthread_create(3) before > doing your first lazy binding: > > 1) build with -znow, then dlopen() something not linked with -znow after > calling pthread_create() > > 2) pass address of pthread_create() to another function which calls > through the pointer, no special link options required (just need to > split up the &pthread_create and *funcptr enough that the compiler > won't optimize to a direct call) > > I've thought about how to possibly force a lazy resolution and haven't > thought up anything that wasn't unmaintainable, and probably > unimplementable.
Well, I believe that Scott was trying to fix a race condition that can only happen if code is using kbind(2) incorrectly, i.e. when the threads deliberately pass different cookies to kbind(2) or execute kbind(2) from different "text" addresses. I still think the solution is simply to accept that race condition.
