From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757693AbcGZTwU (ORCPT ); Tue, 26 Jul 2016 15:52:20 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:52590 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757161AbcGZTwP (ORCPT ); Tue, 26 Jul 2016 15:52:15 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Andrew Vagin Cc: "Michael Kerrisk \(man-pages\)" , Andrey Vagin , Serge Hallyn , "criu\@openvz.org" , Linux API , Linux Containers , LKML , James Bottomley , linux-fsdevel , Alexander Viro References: <1468520419-28220-1-git-send-email-avagin@openvz.org> <20160721210650.GA10989@outlook.office365.com> <1515f5f2-5a49-fcab-61f4-8b627d3ba3e2@gmail.com> <87lh0pg8jx.fsf@x220.int.ebiederm.org> <44ca0e41-dc92-45b1-2a6c-c41a048a072d@gmail.com> <87r3ahepb4.fsf@x220.int.ebiederm.org> <20160726025455.GC26206@outlook.office365.com> Date: Tue, 26 Jul 2016 14:38:28 -0500 In-Reply-To: <20160726025455.GC26206@outlook.office365.com> (Andrew Vagin's message of "Mon, 25 Jul 2016 19:54:56 -0700") Message-ID: <87fuqwqjez.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1bS8OJ-0006hc-DM;;;mid=<87fuqwqjez.fsf@x220.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=67.3.204.119;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19ek+reMxVOv6EYkzzox4rYs21vqcJtR6Q= X-SA-Exim-Connect-IP: 67.3.204.119 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.7 XMSubLong Long Subject * 1.5 XMNoVowels Alpha-numberic number with no vowels * 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.4853] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa01 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa01 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;Andrew Vagin X-Spam-Relay-Country: X-Spam-Timing: total 645 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 3.7 (0.6%), b_tie_ro: 2.6 (0.4%), parse: 1.36 (0.2%), extract_message_metadata: 26 (4.1%), get_uri_detail_list: 3.1 (0.5%), tests_pri_-1000: 9 (1.4%), tests_pri_-950: 1.99 (0.3%), tests_pri_-900: 1.60 (0.2%), tests_pri_-400: 40 (6.3%), check_bayes: 38 (6.0%), b_tokenize: 14 (2.2%), b_tok_get_all: 10 (1.6%), b_comp_prob: 5 (0.8%), b_tok_touch_all: 3.0 (0.5%), b_finish: 0.91 (0.1%), tests_pri_0: 549 (85.0%), check_dkim_signature: 0.84 (0.1%), check_dkim_adsp: 23 (3.6%), tests_pri_500: 6 (1.0%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH 0/5 RFC] Add an interface to discover relationships between namespaces X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -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 Andrew Vagin writes: > On Mon, Jul 25, 2016 at 09:59:43AM -0500, Eric W. Biederman wrote: >> "Michael Kerrisk (man-pages)" writes: > > [snip] > >> [snip] >> >>> So, from my point of view, the important piece that was missing from >> >>> your commit message was the note to use readlink("/proc/self/fd/%d") >> >>> on the returned FDs. I think that detail needs to be part of the >> >>> commit message (and also the man page text). I think it even be >> >>> helpful to include the above program as part of the commit message: >> >>> it helps people more quickly grasp the API. >> >> >> >> Please, please make the standard way to compare these things fstat. >> >> That is much less magic than a symlink, and a little more future proof. >> >> Possibly even kcmp. > > I like the idea to use kcmp to compare namespaces. I am going to add this > functionality to kcmp and describe all these in the man page. > >> > >> > As in fstat() to get the st_ino field, right? >> >> Both the st_ino and st_dev fields. >> >> The most likely change to support checkpoint/restart in the future is to >> preserve st_ino across migrations and instantiate a different instance >> of nsfs to hold the inode numbers from the previous machine. > > It sounds tricky. BTW: Actually this is not only one places where we have > this sort of problem. For example, now mount id-s are not preserved when > a container is migrated. The same problem is applied to tmpfs, where > inode numbers are not preserved for files. Agreed. Interesting. Interesting. Interesting. I am not completely convinced that improving kcmp solves it for everything but improving kcmp sounds good enough to be very interesting and enough to solve a practical case (migration in migration). Plus improving kcmp is cheap and easy. I would propose: KCMP_OBJECT Check whether a file descriptor idx1 in the process pid1 refers to the same underlying object as file descriptor idx2 in the process pid2. The default case would be checking to see if to file descriptors refer to the same inode. But for weird cases (like proc pid directories, or sysfs files) the comparison could look deeper. Eric