Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756849AbZAFXof (ORCPT ); Tue, 6 Jan 2009 18:44:35 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756707AbZAFXnr (ORCPT ); Tue, 6 Jan 2009 18:43:47 -0500 Received: from mail-out2.uio.no ([129.240.10.58]:51760 "EHLO mail-out2.uio.no" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753191AbZAFXnp (ORCPT ); Tue, 6 Jan 2009 18:43:45 -0500 Subject: Re: [RFC][PATCH 2/4] sunrpc: Use utsnamespaces From: Trond Myklebust To: Matt Helsley Cc: "Serge E. Hallyn" , Linux Containers , linux-nfs@vger.kernel.org, Linux Kernel Mailing List , "J. Bruce Fields" , Chuck Lever , "Eric W. Biederman" , Linux Containers , Cedric Le Goater In-Reply-To: <1231283935.14345.142.camel@localhost> References: <20090106011314.534653345@us.ibm.com> <20090106011314.961946803@us.ibm.com> <20090106200229.GA17031@us.ibm.com> <1231274682.20316.65.camel@heimdal.trondhjem.org> <1231283935.14345.142.camel@localhost> Content-Type: text/plain Date: Tue, 06 Jan 2009 18:43:37 -0500 Message-Id: <1231285417.8041.15.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.24.2 Content-Transfer-Encoding: 7bit X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 7A6D40FBF67D2DAA2547B374A705FD2CBE7C0B63 X-UiO-SPAM-Test: remote_host: 68.40.183.129 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 3 total 330 max/h 9 blacklist 0 greylist 0 ratelimit 0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1005 Lines: 21 On Tue, 2009-01-06 at 15:18 -0800, Matt Helsley wrote: > Yes, I was aware that the inode might be dirtied by another container. I > was thinking that, at least in the case of NFS, it makes sense to report > the node name of the container that did the original mount. Of course > this doesn't address the general RPC client case and, like patch 3, it > makes the superblock solution rather NFS-specific. That brings me to a > basic question: Are there any RPC clients in the kernel that do not > operate on behalf of NFS? Yes. There is, for instance, the portmapper/rpcbind client. The NFS and lockd servers also sometime needs to send RPC callbacks. Assuming that you can convert the RPC client into something NFS-specific is therefore not an option. Trond -- 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/