From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2301 invoked by alias); 18 Dec 2014 00:15:35 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 2217 invoked by uid 48); 18 Dec 2014 00:15:29 -0000 From: "jld at mozilla dot com" To: glibc-bugs@sourceware.org Subject: [Bug nptl/17214] Expose a function to reset the PID cache Date: Thu, 18 Dec 2014 00:15:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: nptl X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jld at mozilla dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-12/txt/msg00156.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=17214 Jed Davis changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jld at mozilla dot com --- Comment #10 from Jed Davis --- (In reply to Ricky Zhou from comment #9) > We cannot unshare(CLONE_NEWPID); fork(); for each new process because Linux > does not support calling unshare(CLONE_NEWPID) multiple times. As Steven > said, I think either of the following would solve our problems: > > - Expose a way to invalidate glibc's PID cache > - Allow child_stack to be NULL (leading to fork-like behavior) when > CLONE_VM is not set. Another alternative: expose a variant of fork() which can be passed additional flags to pass to clone; __fork_with_flags(0) would be equivalent to fork(), and it could fail with EINVAL if inappropriate bits are set (CLONE_VM, any of the tid set/clear flags, anything in the signal number field). There may be a better name than __fork_with_flags, but hopefully the idea is clear enough. The advantage over __clone with no child_stack is that it would run pthread_atfork handlers; this would allow taking advantage of, for example, malloc implementations that use pthread_atfork to allow allocation on the child side of a multithreaded fork. Gecko is more or less able to work around this without too much effort because the child process creation already had to be refactored to work in the absence of pthread_atfork (https://bugzilla.mozilla.org/show_bug.cgi?id=772734#c15), but it would be nice to have the possibility of eventually getting away from that requirement. -- You are receiving this mail because: You are on the CC list for the bug.