OpenVZ Forum - RDF feed
type: channel
items: [RFC PATCH 0/5] SUNRPC: "RPC pipefs per network namespace" preparations
items: Re: [RFC PATCH 0/5] SUNRPC: "RPC pipefs per network namespace" preparations

[RFC PATCH 0/5] SUNRPC: "RPC pipefs per network namespace" preparations
type: item
description: Hello to everyone. RPC pipefs file system have to work per network namespace context is required prior to any NFS modifications. This is a way how to do it. I'll really appreciate for any comments. There are several statements about how to make RPC pipefs working per network namespace context. Here they are: 1) RPC pipefs should be mounted per network namespace context. 2) RPC pipefs superblock should holds network namespace while active. 3) RPC pipefs lookup and readir should be perfomed in network namespace context it was mounted. IOW, user-space process, working in another network namespace context, should see RPC pipefs dentries from network namespace context this mount-point was created (like it was done for sysfs). These statement leads to some restrictions which we must follow during implementation. Here are they: 1) RPC pipefs mount can't be performed in kernel context since new super block will holds networks namespace reference and it's impossible to recognize, when and how we have to release this mount point. IOW rpc_get_mount() and rpc_put_mount() have to be removed. 2) RPC pipefs should provide some new helpers to lookup directory dentry for those modules which creates pipes, because without RPC pipefs mount point general lookup can't be performed. 3) These methods must garantee, that pipefs superblock will be active during pipes creation and destruction. So, here is the idea of making RPC pipefs works per network namespace context: 1) RPC pipefs superblock should holds network namespcae context while active. 2) RPC pipefs should send notification events on superblock creation and destruction. 3) RPC pipefs should provide "lookup dentry by name" method for notification subscribers. 4) RPC pipefs should place superblock reference on current network namespace context on creation and remove it on destruction. 5) RPC pipefs should provide safe "lookup dentry by name" method for per-net operations, which garantees, that superblock is active, while per-net-op…
creator: Stanislav Kinsbursky
date: 2011-10-17T12:13:09-00:00

Re: [RFC PATCH 0/5] SUNRPC: "RPC pipefs per network namespace" preparations
type: item
description: Guys, please, spend some of your expensive time to review this patch-set briefly. This is not for commit, but just an idea representation. I really need some opinions about it, since all my further work aroud RPC pipefs depends on it. IOW I need to now, does anyone has something against this idea. Trond, please, respond, does this idea suits you in general or not? 17.10.2011 17:10, Stanislav Kinsbursky пишет: > Hello to everyone. > RPC pipefs file system have to work per network namespace context is required > prior to any NFS modifications. > This is a way how to do it. I'll really appreciate for any comments. > > There are several statements about how to make RPC pipefs working per network > namespace context. > Here they are: > 1) RPC pipefs should be mounted per network namespace context. > 2) RPC pipefs superblock should holds network namespace while active. > 3) RPC pipefs lookup and readir should be perfomed in network namespace context > it was mounted. IOW, user-space process, working in another network namespace > context, should see RPC pipefs dentries from network namespace context this > mount-point was created (like it was done for sysfs). > > These statement leads to some restrictions which we must follow during > implementation. Here are they: > 1) RPC pipefs mount can't be performed in kernel context since new super block > will holds networks namespace reference and it's impossible to recognize, when > and how we have to release this mount point. IOW rpc_get_mount() and > rpc_put_mount() have to be removed. > 2) RPC pipefs should provide some new helpers to lookup directory dentry for > those modules which creates pipes, because without RPC pipefs mount point > general lookup can't be performed. > 3) These methods must garantee, that pipefs superblock will be active during > pipes creation and destruction. > > So, here is the idea of making RPC pipefs works per network namespace context: > 1) RPC pipefs superblock should holds network namespcae con…
creator: Stanislav Kinsbursky
date: 2011-10-20T11:06:46-00:00

Re: [RFC PATCH 0/5] SUNRPC: "RPC pipefs per network namespace" preparations
type: item
description: On Thu, Oct 20, 2011 at 03:06:46PM +0400, Stanislav Kinsbursky wrote: > Guys, please, spend some of your expensive time to review this patch-set briefly. I'll try to take a look soon, but I'm travelling tomorrow through the 31st, and things will be a little hectic. Just one quick comment: > >The only problem about I'm not sure how to solve properly yet, is auth gss > >pipes creations operations. Hoping for some help with it. I suspect one reason it may be a little complicated is the upcall-version switching. The old version is deprecated, and there's no need to support the combination of the old version with the a new feature like containers. And now that it's been there a while the version-switching code already achieved its goal of avoiding a flag day. So, one approach might be: - move all the code for the old gss upcall and for the version switching under a new CONFIG_DEPRECATED_GSS, or similar. - print a warning if the old stuff is used, and plan to rip it out completely in a future kernel version. - do something that works just in the !CONFIG_DEPRECATED_GSS case. Would that help? --b.
creator: bfields
date: 2011-10-20T12:32:42-00:00

Re: [RFC PATCH 0/5] SUNRPC: "RPC pipefs per network namespace" preparations
type: item
description: 20.10.2011 16:32, bfields@fieldses.org пишет: > On Thu, Oct 20, 2011 at 03:06:46PM +0400, Stanislav Kinsbursky wrote: >> Guys, please, spend some of your expensive time to review this patch-set briefly. > > I'll try to take a look soon, but I'm travelling tomorrow through the > 31st, and things will be a little hectic. > Thanks for your time, Bruce. > Just one quick comment: > >>> The only problem about I'm not sure how to solve properly yet, is auth gss >>> pipes creations operations. Hoping for some help with it. > > I suspect one reason it may be a little complicated is the > upcall-version switching. The old version is deprecated, and there's no > need to support the combination of the old version with the a new > feature like containers. And now that it's been there a while the > version-switching code already achieved its goal of avoiding a flag day. > So, one approach might be: > > - move all the code for the old gss upcall and for the version > switching under a new CONFIG_DEPRECATED_GSS, or similar. > - print a warning if the old stuff is used, and plan to rip it > out completely in a future kernel version. > - do something that works just in the !CONFIG_DEPRECATED_GSS > case. > Thanks for this comment. I'll check the code for problem you mentioned here. But I was actually talking about other thing. Currently we create pipe in gss without any checks since we assume, that pipefs client dir is created already. But with approach, represented in this patch set, pipes and dirs will be created only when pipefs was mounted from user-space. I.e. clients with gss auth may already present and some callback is required for creating gss pipes. And also this approch assumes existence of gss auth without pipe. > Would that help? > > --b. -- Best regards, Stanislav Kinsbursky
creator: Stanislav Kinsbursky
date: 2011-10-20T12:56:02-00:00