Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762256AbXKCX4F (ORCPT ); Sat, 3 Nov 2007 19:56:05 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757364AbXKCXzz (ORCPT ); Sat, 3 Nov 2007 19:55:55 -0400 Received: from pentafluge.infradead.org ([213.146.154.40]:54439 "EHLO pentafluge.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757006AbXKCXzy (ORCPT ); Sat, 3 Nov 2007 19:55:54 -0400 Date: Sat, 3 Nov 2007 16:55:25 -0700 From: Arjan van de Ven To: Linus Torvalds Cc: Ingo Molnar , Dave Hansen , Andrew Morton , Pavel Emelyanov , Ulrich Drepper , linux-kernel@vger.kernel.org, "Dinakar Guniguntala [imap]" , Sripathi Kodi Subject: Re: [patch] PID namespace design bug, workaround Message-ID: <20071103165525.2dcd55c7@laptopd505.fenrus.org> In-Reply-To: References: <20071101144307.GA29566@elte.hu> <4729E7E4.8070208@openvz.org> <4729E936.4040400@redhat.com> <4729EB3C.9050102@openvz.org> <472A6D91.1020300@redhat.com> <472AD7D6.80900@openvz.org> <20071102010419.23f3db5c.akpm@linux-foundation.org> <1194024622.6271.108.camel@localhost> <20071103201251.GB26366@elte.hu> Organization: Intel X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.1; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1398 Lines: 29 On Sat, 3 Nov 2007 15:40:48 -0700 (PDT) Linus Torvalds wrote: > I don't understand how you can call this a "PID namespace design > bug", when it clearly has nothing what-so-ever to do with pid > namespaces, and everything to do with the *futexes* that blithely > assume that pid's are unique and that made it part of the > user-visible interface. > > OF COURSE any pid namespace design will always break such > assumptions, but that's not because of any PID namespace bugs. It's > what the whole *point* of PID namespaces are. If you use pid's > (instead of some opaque cookies), you will not be able to use such > things across pid-separation. well... kind of. THere are 2 things around pid namespaces: which pids you can see/touch (in proc or signals or otherwise), and the non-uniqueness. For containers you clearly want the first part... but... is there a strong reason to not just *not* create duplicate pids even across namespaces? there's no rule in posix or anything similar to fd's afaik concerning which pids we can hand out... so we could just make then unique globally but just with limited visibility.... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/