Re: Caching of PID/TID after fork

[Robert Święcki <robert at swiecki dot net>]

HI all,

> The stack check seems just error-prone one and I see it might be
> justifiable to remove it.  I am not sure how we should act on
> semantic change for Linux-only syscall, so it might require to
> add compatibility symbol I would try to avoid it.

I was thinking that maybe the following would work (in asm), without
the need to introduce additional files / codepaths.
ENTRY(clone):
  check_for_newsp_nonnull
  check_for_fn_nonnull
ENTRY(__clone3):
 clone_logic_wo_checks
END(__clone3)
END(clone)

EXPORT(clone)
EXPORT(__clone3)

But, all in all, I agree that doing it (TM) right way (with support
for pthread_at_fork) might be a better choice.

>
> > Thefore I'd like to ask for one of the following solutions:
> >
> > 1. Don't cache PID/TID
> >
> > 2. Provide some kind of symbol, which would force for TID/PID to be
> > reloaded in glibc.
>
> I think we need a different design.
>
> For example, when you clone a process, you really want that all
> cryptographic random number generators are reinitialized.  Making this
> depend on getpid does not really work, so we need a more general
> solution.

Agreed.

>
> The other question I have is whether we talk about clone-as-fork
> exclusively.  Introducing a new thread into the process on which
> non-free-standing code can run using clone is a different matter
> altogether.

To my knowledge, in the vast majority of cases (or even, in all
cases), where the TID/PID caching problem surfaced, it could have been
solved by fork_with_flags() indeed.

Though, one useful feature which could be potentially useful for some
porjects would be to create a detached process (for which the kernel
doesn't send termination signal - usually SIGCHLD - to the parent
process). And this cannot be solved by ORing custom flags with fork
ones, because SIGCHLD is already there. But, it's just a guess.

-- 
Robert Święcki