This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Caching of PID/TID after fork
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Florian Weimer <fweimer at redhat dot com>, libc-alpha at sourceware dot org
- Date: Fri, 4 Nov 2016 14:03:40 -0200
- Subject: Re: Caching of PID/TID after fork
- Authentication-results: sourceware.org; auth=none
- References: <CAP145pj+yVz_7ZF8_dNqZ2NE22A_O5QyT195Gy0TgvKq1j3skw@mail.gmail.com> <87y4202blm.fsf@mid.deneb.enyo.de> <CAP145phqU29-vMNkS6zzWRJn4L_F9+zHQkybiirQndBcxJGp8g@mail.gmail.com> <87mvidj0qw.fsf@mid.deneb.enyo.de> <CAP145pjSBEgWS6dQ2u741m1z0VZYZ49ydLe-yvmjj1FuC_zqpQ@mail.gmail.com> <ecb5be63-de88-f05c-38ad-65e20f17a274@linaro.org> <03127072-f944-86de-da85-cd889ce5ed76@redhat.com>
On 04/11/2016 13:14, Florian Weimer wrote:
> On 10/10/2016 08:03 PM, Adhemerval Zanella wrote:
>> + /* Some sanity checks for clone syscall: returned ppid should be currernt
>
> Typo: “currernt”
>
> On its own, this approach looks okay, but I am worried that it sends a message that it's okay to clone processes without additional measures to protect PRNGs and things like that.
>
> Florian
I am not sure if you referring you to my initial RFC patch or the one
complete I sent [1] since you replied to the original thread.
Anyway, I see that with current fixes on some algorithm (execv not
using dynamic memory allocation and various issues with posix_spawn)
clone direct usage should be really required in very specific
scanerios (mostly on new containers projects and such alike). And
I would expect that these very projects to know the constraints and
limitations of using the syscall directly.
[1] https://sourceware.org/ml/libc-alpha/2016-10/msg00233.html