From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933779AbYCDWvf (ORCPT ); Tue, 4 Mar 2008 17:51:35 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755466AbYCDWvX (ORCPT ); Tue, 4 Mar 2008 17:51:23 -0500 Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:34753 "EHLO ebiederm.dsl.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754573AbYCDWvW (ORCPT ); Tue, 4 Mar 2008 17:51:22 -0500 From: ebiederm@xmission.com (Eric W. Biederman) To: Pavel Emelyanov Cc: serge@hallyn.com, Andrew Morton , David Miller , Alexey Dobriyan , Linux Netdev List , Linux Kernel Mailing List Subject: Re: [PATCH 0/2] Fix /proc/net in presence of net namespaces References: <47C6D743.1050802@openvz.org> <20080228211720.GA1232@vino.hallyn.com> <47C7BB1B.9060906@openvz.org> <47CBBFBC.3010607@openvz.org> Date: Tue, 04 Mar 2008 15:49:11 -0700 In-Reply-To: <47CBBFBC.3010607@openvz.org> (Pavel Emelyanov's message of "Mon, 03 Mar 2008 12:07:08 +0300") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Pavel Emelyanov writes: >>>> - Have readdir and lookup filter the directory entries by the pid >>>> namespace of the proc mount. >>> So, how are you going to filter the lookup? The problem I see - you have >>> a process that opened the /proc/.netns/X directory (he onws that namespace) >>> and the other one trying to do the same. The VFS layer finds the hashed >>> dentry corresponding to this /proc/.netns/X. The only way you can prevent >>> VFS from giving one to the second task is to override .d_revalidate method >>> and drop that dentry.... >>> >>> But we've already tried to walk this way with no luck. >> >> I meant a per mount filtering. Exactly like we do for the pids now. > > We (me) do not perform any "filtering" in /proc. I just make /proc play > the VFS rules - one super-block one tree of dentries. Exactly. For different super blocks we return a different set of processes and a different set of numbers of those processes. If you do use ids that do not live in a namespace I agree you do not need to do different things for different mounts, but that seems ugly and problematic. >>>> If we make namespaces show up anywhere besides under >>>> "/proc//task//" we have to do something like this, and pids >>>> are largely designed for this kind of use. >>> Proc consists of two parts - the -s one with generated-on-the-fly >>> entries and the static one that is represented by proc_dir_entry tree. >>> Do you propose to mix those two? >> >> Yes. Because the static entries are beginning to depend on process >> specific attributes. We have already started with /proc/mounts. > > /proc//mounts is not represented with any proc_dir_entry, but > what you're proposing with /proc//net seems like doing this > representation. Yes. I am talking about placing things represented with a prod_dir_entry and having them show up under a hierarchy not represented with proc_dir_entries under /proc/. As that is clean, worked well for /proc/mounts, does not require ids at all, and is essentially the optimal form for monitoring processes. /proc/mounts used to have a proc_dir_entry. When it was reimplemented to be per fs namespace that was removed. >>>> just need a non-global id for our directory entries so we don't paint >>>> ourselves into a corner. >>> What namespace do you mean by "non-global"? >> >> The best is an id I can take with me when I migrate from machine A >> to machine B. An id in some namespace or a form that doesn't need >> an id at all is the core requirement. > > If we're OK in having a /proc/netns/ for each namespace, then > this is an id, regardless whatever it is - a pre-generated > number, a pointer, etc. > > That said, your only wish is to make this be preservable across > migration, right? No, that is not my only wish. - I wish for a clean maintainable interface. - I wish for an interface that we can use for monitoring programs like top and ps. - I wish for an interface that is migration safe. It is my opinion that using an id is simply an optimization to reduce the number of cached proc dentries. I gave a full run down of what I wish and the reasons for it earlier in this thread. I have not seen you respond to that message. Currently I am NOT ok having a /proc/netns/. It appears to be a contentious premature optimization. VFS clean, maintainable, and usable for monitoring is /proc//task//net. We can always figure out how to optimize that form later. Eric