From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934764AbbIVVHq (ORCPT ); Tue, 22 Sep 2015 17:07:46 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:36226 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752088AbbIVVHo (ORCPT ); Tue, 22 Sep 2015 17:07:44 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Konstantin Khlebnikov Cc: "Serge E. Hallyn" , Chen Fan , linux-api@vger.kernel.org, containers@lists.linux-foundation.org, Serge Hallyn , Oleg Nesterov , linux-kernel@vger.kernel.org, Andrew Morton , Linus Torvalds References: <20150915120924.14818.49490.stgit@buzz> <87h9mvg3kw.fsf@x220.int.ebiederm.org> <55F832D2.1070605@yandex-team.ru> <20150915151729.GA144242@dakara> <20150915174143.GE4699@ubuntumail> <55F91C3D.1040209@yandex-team.ru> <20150916143939.GA32226@mail.hallyn.com> <87twquzag1.fsf@x220.int.ebiederm.org> <20150916163123.GA1039@mail.hallyn.com> <55FF7043.5020701@cn.fujitsu.com> <20150921142222.GA24005@mail.hallyn.com> <56010680.7000301@yandex-team.ru> Date: Tue, 22 Sep 2015 16:00:23 -0500 In-Reply-To: <56010680.7000301@yandex-team.ru> (Konstantin Khlebnikov's message of "Tue, 22 Sep 2015 10:42:56 +0300") Message-ID: <87eghqcgpk.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-AID: U2FsdGVkX18vrs+XJIoCTlQ4wXYak6SF9xl0QwSuyWk= X-SA-Exim-Connect-IP: 67.3.201.231 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa05 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa05 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Konstantin Khlebnikov X-Spam-Relay-Country: X-Spam-Timing: total 533 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 3.6 (0.7%), b_tie_ro: 2.5 (0.5%), parse: 0.74 (0.1%), extract_message_metadata: 11 (2.1%), get_uri_detail_list: 1.31 (0.2%), tests_pri_-1000: 4.6 (0.9%), tests_pri_-950: 1.18 (0.2%), tests_pri_-900: 0.95 (0.2%), tests_pri_-400: 20 (3.8%), check_bayes: 19 (3.6%), b_tokenize: 6 (1.1%), b_tok_get_all: 6 (1.2%), b_comp_prob: 2.0 (0.4%), b_tok_touch_all: 3.1 (0.6%), b_finish: 0.61 (0.1%), tests_pri_0: 479 (89.9%), tests_pri_500: 9 (1.6%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH RFC] pidns: introduce syscall getvpid X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Konstantin Khlebnikov writes: > On 21.09.2015 17:22, Serge E. Hallyn wrote: >> >> So please implement it, as Eric suggested, using the ns inode fds >> instead of racy pid_t hints for namespaces. >> > > I don't want to loose simple way to use it. > Sometimes caller cannot prevent races (task its child or > locked with with ptrace) or it don't care about them. > > What about this design: > > pid_t getvpid(pid_t pid, pid_t source, pid_t target) > > pid > 0 - get vpid of task > pid = 0 - current pid (= just for symmetry =) > pid < 0 - get vpid of parent task (ppid of -pid) > [ that's really useful for poking isolated pidns ] > source/target > 0 - pid of source/target task > source/target = 0 - use current as source/target > source/target < 0 - use pidns fd (1-arg) as source/target > > or the same but without =0 sugar: > > pid > 0 - get vpid of task > pid < 0 - get vpid of parent task (ppid of -arg) > source/target > 0 - pid of source/target task > source/target <= 0 - use pidns fd (-arg) as source/target > > libc caches current pid, extra getpid shouldn't be a problem. Yuck. An invalid fd like for saying use the current pid namespace is fine. Using pids to identify namespaces yuck just yuck. That just seems to add complexity for no gain except to make programs buggier. We have a couple of old interfaces that use pids because pids were the the best we had, but at this point I don't see anything at all that even suggests that pids are a good choice for identifying namespaces. If performance is important than caching file descriptors should be trivial. If performance is not important it should not be hard to open "/proc//ns/pid". I do not see the gain of using pids in this interface except to confuse people, and make the interface brittle. Eric