OpenVZ Forum - RDF feed
type: channel
items: [netns] sysfs: issues porting shadow directories on top of 2.6.21-mm2
items: Re: [netns] [PATCH 1/4] sysfs: porting shadow directories on top of 2.6.21-mm2
items: Re: [netns] [PATCH 2/4] sysfs: issues porting shadow directories on top of 2.6.21-mm2
items: Re: [netns] [PATCH 3/4] sysfs: issues porting shadow directories on top of 2.6.21-mm2
items: Re: [netns] sysfs: issues porting shadow directories on top of 2.6.21-mm2
items: [PATCH 1/4] sysfs: Remove first pass at shadow directory support
items: [PATCH 2/4] sysfs: Implement sysfs manged shadow directory support.
items: [PATCH 3/4] sysfs: Implement sysfs_delete_link and sysfs_rename_link
items: PATCH 4/4] driver core: Implement shadow directory support for device classes.
items: Re: [PATCH 1/4] sysfs: Remove first pass at shadow directory support
items: [PATCH 4/4] driver core: Implement shadow directory support for device classes.
items: patch driver-core-implement-shadow-directory-support-for-device-classes.patch added to gregkh-2.6 tr
items: patch sysfs-implement-sysfs-manged-shadow-directory-support.patch added to gregkh-2.6 tree
items: patch sysfs-implement-sysfs_delete_link-and-sysfs_rename_link.patch added to gregkh-2.6 tree
items: patch sysfs-remove-first-pass-at-shadow-directory-support.patch added to gregkh-2.6 tree
items: Re: patch driver-core-implement-shadow-directory-support-for-device-classes.patch added to gregkh-2.
items: Re: [PATCH 2/4] sysfs: Implement sysfs manged shadow directory support.
items: Re: Re: [PATCH 2/4] sysfs: Implement sysfs manged shadow directory support.

[netns] sysfs: issues porting shadow directories on top of 2.6.21-mm2
type: item
description: Hi Eric, For the past few weeks, I've been trying to port your netns patchset on top of 2.6.21-mm2. It took me a lot more time than I first expected to have something working. I started the port based on your latest public git repository tag: "netns/v2.6.21-rc6-netns17". I met a few difficulties during the port the worst being porting the shadow directories patches on top of Greg's sysfs patches. Greg modified a lot of things in sysfs and I had to "rewrite"/adapt most of your "sysfs: Implement sysfs manged shadow directory support" patch. My knowledge of sysfs approaching zero, the result isn't that great. Any chance you've updated the patchset for a recent version of the -mm kernel? Here are some issues I have with the sysfs part of the netns patchset: * The first thing I'm not sure to understand in your patch is how shadow dirs and there "real" counterpart are supposed to be linked (via dentry and via sysfs_dirent). Is it something like: /sys/class/net/ ("real" net class) /sys/class/net-shadow1/ /sys/class/net-shadow2/ or: /sys/class/net/ /sys/class/net/net-shadow1/ /sys/class/net/net-shadow2/ In add_shadow_dir(), it seems the shadow dentry parent is "class" : shadow = d_alloc(dir->d_parent, &dir->d_name); and the shadow sysfs_dirent parent is the real "net": sysfs_make_dirent(dir->d_fsdata, ....); On 2.6.21-mm2, if I attach the dentry to "class" (dir->d_parent) as you did initially, then the shadow directory lookup "fails": it always returns the same shadow dir, whatever network namespace is current. Indeed, sysfs_shadow_follow_link() is never called with a SYSFS_DIR dentry, but always directly with a SYSFS_SHADOW one, and the tag comparison is never done. In add_shadow_dir(), I changed the d_alloc() call and passed dir instead of dir->d_parent, and it "solved" the issue: sysfs_shadow_follow_link() is called with the SYSFS_DIR dentry, and the shadow dir lookup is done. * I also have some issues with symlinks. Indeed, the way symlinks are "resolved" have changed. …
creator: Benjamin Thery
date: 2007-06-18T17:57:44-00:00

Re: [netns] [PATCH 1/4] sysfs: porting shadow directories on top of 2.6.21-mm2
type: item
description: Here are the patches for the sysfs shadow directories ported to 2.6.21-mm2 in case you want to look at them to spot the issues. They are extracted from the full netns patchset. Benjamin -- B e n j a m i n T h e r y - BULL/DT/Open Software R&D http://www.bull.com _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Benjamin Thery
date: 2007-06-18T18:06:19-00:00

Re: [netns] [PATCH 2/4] sysfs: issues porting shadow directories on top of 2.6.21-mm2
type: item
description: This is the big piece. Benjamin _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Benjamin Thery
date: 2007-06-18T18:08:16-00:00

Re: [netns] [PATCH 3/4] sysfs: issues porting shadow directories on top of 2.6.21-mm2
type: item
description: Third one. Benjamin _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Benjamin Thery
date: 2007-06-18T18:09:16-00:00

Re: [netns] sysfs: issues porting shadow directories on top of 2.6.21-mm2
type: item
description: Last one, that contains the dirty hack that "fixes" symlinks through shadow directories in my pacthset. If you have time to help me port/fix these patches that would be great. If you already have an updated version pf the patchset that would be even better. Thanks for your help. Benjamin _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Benjamin Thery
date: 2007-06-18T18:14:04-00:00

Re: [netns] sysfs: issues porting shadow directories on top of 2.6.21-mm2
type: item
description: Benjamin Thery <benjamin.thery@bull.net> writes: > Hi Eric, > > For the past few weeks, I've been trying to port your netns patchset on top of > 2.6.21-mm2. It took me a lot more time than I first expected to have something > working. > > I started the port based on your latest public git repository tag: > "netns/v2.6.21-rc6-netns17". > > I met a few difficulties during the port the worst being porting the shadow > directories patches on top of Greg's sysfs patches. > > Greg modified a lot of things in sysfs and I had to "rewrite"/adapt most of your > "sysfs: Implement sysfs manged shadow directory support" patch. My knowledge of > sysfs approaching zero, the result isn't that great. Grrr. I will try and take a look shortly. > Any chance you've updated the patchset for a recent version of the -mm kernel? I haven't I will have to take a look. It sounds like more has changed then I anticipated. > Here are some issues I have with the sysfs part of the netns patchset: > > * The first thing I'm not sure to understand in your patch is how shadow dirs > and there "real" counterpart are supposed to be linked (via dentry and via > sysfs_dirent). > > Is it something like: > > /sys/class/net/ ("real" net class) > /sys/class/net-shadow1/ > /sys/class/net-shadow2/ Yes. At least as far as dentry are concerned. > or: > > /sys/class/net/ > /sys/class/net/net-shadow1/ > /sys/class/net/net-shadow2/ Not as far as dentries are concerned. The basic concept is that you get a different result depending who you are. > In add_shadow_dir(), it seems the shadow dentry parent is "class" : > shadow = d_alloc(dir->d_parent, &dir->d_name); > and the shadow sysfs_dirent parent is the real "net": > sysfs_make_dirent(dir->d_fsdata, ....); > > On 2.6.21-mm2, if I attach the dentry to "class" (dir->d_parent) as you did > initially, then the shadow directory lookup "fails": it always returns the same > shadow dir, whatever network namespace is current. Indeed, > sysfs_shadow_follow_link() is never call…
creator: ebiederm
date: 2007-06-19T17:32:05-00:00

Re: [netns] sysfs: issues porting shadow directories on top of 2.6.21-mm2
type: item
description: Benjamin Thery <benjamin.thery@bull.net> writes: > Hi Eric, > > For the past few weeks, I've been trying to port your netns patchset on top of > 2.6.21-mm2. It took me a lot more time than I first expected to have something > working. Ok. Interesting. There are a few pieces missing to make it work on the latest -mm. The removal of the doubly linked lists.. > I started the port based on your latest public git repository tag: > "netns/v2.6.21-rc6-netns17". > > I met a few difficulties during the port the worst being porting the shadow > directories patches on top of Greg's sysfs patches. > > Greg modified a lot of things in sysfs and I had to "rewrite"/adapt most of your > "sysfs: Implement sysfs manged shadow directory support" patch. My knowledge of > sysfs approaching zero, the result isn't that great. > > Any chance you've updated the patchset for a recent version of the -mm kernel? I'm looking at it. > Here are some issues I have with the sysfs part of the netns patchset: > > * The first thing I'm not sure to understand in your patch is how shadow dirs > and there "real" counterpart are supposed to be linked (via dentry and via > sysfs_dirent). > > Is it something like: > > /sys/class/net/ ("real" net class) > /sys/class/net-shadow1/ > /sys/class/net-shadow2/ > > or: > > /sys/class/net/ > /sys/class/net/net-shadow1/ > /sys/class/net/net-shadow2/ In the pure sysfs dirent data structures it does look like this so I don't think your ``hack'' patch is a hack. > In add_shadow_dir(), it seems the shadow dentry parent is "class" : > shadow = d_alloc(dir->d_parent, &dir->d_name); > and the shadow sysfs_dirent parent is the real "net": > sysfs_make_dirent(dir->d_fsdata, ....); > > On 2.6.21-mm2, if I attach the dentry to "class" (dir->d_parent) as you did > initially, then the shadow directory lookup "fails": it always returns the same > shadow dir, whatever network namespace is current. Indeed, > sysfs_shadow_follow_link() is never called with a SYSFS_DIR dentry, but alw…
creator: ebiederm
date: 2007-06-20T00:19:06-00:00

Re: [netns] sysfs: issues porting shadow directories on top of 2.6.21-mm2
type: item
description: On Mon, 2007-06-18 at 19:57 +0200, Benjamin Thery wrote: > /sys/class/net/ ("real" net class) > /sys/class/net-shadow1/ > /sys/class/net-shadow2/ This seems like a nice "quick fix", but do we really want to be hacking sysfs around like this? We have the backing sysfs_* entries that are separate from the vfs entities already. Why can't we simply have different /sys vfsmounts with different views of the backing sysfs_* entries? -- Dave _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Dave Hansen
date: 2007-06-21T17:22:57-00:00

Re: [netns] sysfs: issues porting shadow directories on top of 2.6.21-mm2
type: item
description: Dave Hansen <hansendc@us.ibm.com> writes: > On Mon, 2007-06-18 at 19:57 +0200, Benjamin Thery wrote: >> /sys/class/net/ ("real" net class) >> /sys/class/net-shadow1/ >> /sys/class/net-shadow2/ > > This seems like a nice "quick fix", but do we really want to be hacking > sysfs around like this? > > We have the backing sysfs_* entries that are separate from the vfs > entities already. Why can't we simply have different /sys vfsmounts > with different views of the backing sysfs_* entries? So far this has been easier. sysfs is so tightly coupled to the kobject tree decoupling them is seriously non-trivial. When I can I do prefer separate mounts because that fixes a lot of cache issues. For /proc we may be able to go as far as breaking up all of it's pieces into separate filesystems, and do magic mounts and umounts behind the users back. We can't even contemplate that with sysfs as it has symlinks all over the place. A remount of sysfs that displays just the information from the current processes namespaces would be possible. If you can figure how to make those mods to sysfs I will be happy to use it. We actually must modify /proc to do multiple mounts because a follow link method on the root directory entry is not honored. With a magic follow link method we can use the dcache as intended except for the handful of magic directories. So since I have working code today (baring one or two bugs I'm in the process of fixing) and that greg has given his basic nod of acceptance I figure I will pursue this route and we can update things later if we need to. Eric _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: ebiederm
date: 2007-06-21T20:48:10-00:00

Re: [netns] sysfs: issues porting shadow directories on top of 2.6.21-mm2
type: item
description: Dave Hansen <hansendc@us.ibm.com> writes: > On Mon, 2007-06-18 at 19:57 +0200, Benjamin Thery wrote: >> /sys/class/net/ ("real" net class) >> /sys/class/net-shadow1/ >> /sys/class/net-shadow2/ > > This seems like a nice "quick fix", but do we really want to be hacking > sysfs around like this? > > We have the backing sysfs_* entries that are separate from the vfs > entities already. Why can't we simply have different /sys vfsmounts > with different views of the backing sysfs_* entries? Dave. Another and probably better way of looking at this is we need essentially the same code in sysfs however we implement it. The only practical difference is do we get the namespaces from the mount of sysfs or from the current process doing the reading. If you would like to take this in the direction of looking at the mount point for the information and seeing if there are optimizations we can apply with static information free. Wherever we end up I think this code is a fairly decent starting place. Eric _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: ebiederm
date: 2007-06-21T21:02:38-00:00

Re: [netns] sysfs: issues porting shadow directories on top of 2.6.21-mm2
type: item
description: On Thu, Jun 21, 2007 at 02:48:10PM -0600, Eric W. Biederman wrote: > Dave Hansen <hansendc@us.ibm.com> writes: > > > On Mon, 2007-06-18 at 19:57 +0200, Benjamin Thery wrote: > >> /sys/class/net/ ("real" net class) > >> /sys/class/net-shadow1/ > >> /sys/class/net-shadow2/ > > > > This seems like a nice "quick fix", but do we really want to be hacking > > sysfs around like this? > > > > We have the backing sysfs_* entries that are separate from the vfs > > entities already. Why can't we simply have different /sys vfsmounts > > with different views of the backing sysfs_* entries? > > So far this has been easier. sysfs is so tightly coupled to the kobject > tree decoupling them is seriously non-trivial. Tejun just decoupled them, that's why this all changed in the -mm tree, so it might be a whole lot easier to do now. thanks, greg k-h _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: gregkh
date: 2007-06-21T21:16:37-00:00

Re: [netns] sysfs: issues porting shadow directories on top of 2.6.21-mm2
type: item
description: On Thu, 2007-06-21 at 15:02 -0600, Eric W. Biederman wrote: > Dave. Another and probably better way of looking at this is we need > essentially the same code in sysfs however we implement it. The only > practical difference is do we get the namespaces from the mount of > sysfs or from the current process doing the reading. Yeah, both approaches would definitely have the same result: changing the view of /sys based on process context. I'll look at it in a bit more detail and see if it is practical. -- Dave _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Dave Hansen
date: 2007-06-21T21:27:13-00:00

Re: [netns] sysfs: issues porting shadow directories on top of 2.6.21-mm2
type: item
description: Greg KH <gregkh@suse.de> writes: > On Thu, Jun 21, 2007 at 02:48:10PM -0600, Eric W. Biederman wrote: >> Dave Hansen <hansendc@us.ibm.com> writes: >> >> > On Mon, 2007-06-18 at 19:57 +0200, Benjamin Thery wrote: >> >> /sys/class/net/ ("real" net class) >> >> /sys/class/net-shadow1/ >> >> /sys/class/net-shadow2/ >> > >> > This seems like a nice "quick fix", but do we really want to be hacking >> > sysfs around like this? >> > >> > We have the backing sysfs_* entries that are separate from the vfs >> > entities already. Why can't we simply have different /sys vfsmounts >> > with different views of the backing sysfs_* entries? >> >> So far this has been easier. sysfs is so tightly coupled to the kobject >> tree decoupling them is seriously non-trivial. > > Tejun just decoupled them, that's why this all changed in the -mm tree, > so it might be a whole lot easier to do now. Right. And I was able to simply the code by using more extensively using the improved sysfs_dirent. However we still have kobj->dentry. Which makes a one to many situation tricky. Eric _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: ebiederm
date: 2007-06-21T21:54:13-00:00

Re: [netns] sysfs: issues porting shadow directories on top of 2.6.21-mm2
type: item
description: On Thu, Jun 21, 2007 at 03:54:13PM -0600, Eric W. Biederman wrote: > Greg KH <gregkh@suse.de> writes: > > > On Thu, Jun 21, 2007 at 02:48:10PM -0600, Eric W. Biederman wrote: > >> Dave Hansen <hansendc@us.ibm.com> writes: > >> > >> > On Mon, 2007-06-18 at 19:57 +0200, Benjamin Thery wrote: > >> >> /sys/class/net/ ("real" net class) > >> >> /sys/class/net-shadow1/ > >> >> /sys/class/net-shadow2/ > >> > > >> > This seems like a nice "quick fix", but do we really want to be hacking > >> > sysfs around like this? > >> > > >> > We have the backing sysfs_* entries that are separate from the vfs > >> > entities already. Why can't we simply have different /sys vfsmounts > >> > with different views of the backing sysfs_* entries? > >> > >> So far this has been easier. sysfs is so tightly coupled to the kobject > >> tree decoupling them is seriously non-trivial. > > > > Tejun just decoupled them, that's why this all changed in the -mm tree, > > so it might be a whole lot easier to do now. > > Right. And I was able to simply the code by using more extensively using > the improved sysfs_dirent. However we still have kobj->dentry. Which > makes a one to many situation tricky. Ah, yeah, that is still there. Well, any suggestions you might have for removing that limitation (if it is one), is appreciated. thanks, greg k-h _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: gregkh
date: 2007-06-22T00:13:28-00:00

Re: [netns] sysfs: issues porting shadow directories on top of 2.6.21-mm2
type: item
description: Greg KH <gregkh@suse.de> writes: > Ah, yeah, that is still there. Well, any suggestions you might have for > removing that limitation (if it is one), is appreciated. There can be some benefit in mounting filesystems so you can see what another user sees. So I think it is worth looking at. However all of the user that care are at best CONFIG_EXPERIMENTAL for the next while. Therefore as long as we have something that is close we can fix the last couple of details after we have the bulk of the code changes made. Eric _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: ebiederm
date: 2007-06-22T07:00:00-00:00

[PATCH 1/4] sysfs: Remove first pass at shadow directory support
type: item
description: While shadow directories appear to be a good idea, the current scheme of controlling their creation and destruction outside of sysfs appears to be a locking and maintenance nightmare in the face of sysfs directories dynamically coming and going. Which can now occur for directories containing network devices when CONFIG_SYSFS_DEPRECATED is not set. This patch removes everything from the initial shadow directory support that allowed the shadow directory creation to be controlled at a higher level. So except for a few bits of sysfs_rename_dir everything from commit b592fcfe7f06c15ec11774b5be7ce0de3aa86e73 is now gone. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> --- These patches are against 2.6.22-rc4-mm2 Hopefully that is new enough to catch all of the in flight sysfs patches. fs/sysfs/dir.c | 172 ++++++++++------------------------------------- fs/sysfs/group.c | 1 - fs/sysfs/inode.c | 10 --- fs/sysfs/mount.c | 2 +- fs/sysfs/sysfs.h | 6 -- include/linux/kobject.h | 4 - include/linux/sysfs.h | 24 +------ lib/kobject.c | 44 ++---------- 8 files changed, 48 insertions(+), 215 deletions(-) diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c index b4074ad..b1da4fc 100644 --- a/fs/sysfs/dir.c +++ b/fs/sysfs/dir.c @@ -415,10 +415,9 @@ int sysfs_create_subdir(struct kobject * k, const char * n, struct dentry ** d) /** * sysfs_create_dir - create a directory for an object. * @kobj: object we're creating directory for. - * @shadow_parent: parent parent object. */ -int sysfs_create_dir(struct kobject * kobj, struct dentry *shadow_parent) +int sysfs_create_dir(struct kobject * kobj) { struct dentry * dentry = NULL; struct dentry * parent; @@ -426,9 +425,7 @@ int sysfs_create_dir(struct kobject * kobj, struct dentry *shadow_parent) BUG_ON(!kobj); - if (shadow_parent) - parent = shadow_parent; - else if (kobj->parent) + if (kobj->parent) parent = kobj->parent->dentry; else if (sysfs_mount && sysfs_mount->mnt_sb) parent = sysfs_mount->mnt_sb->s_root; @@ -516,12 +513,26 @@ void…
creator: ebiederm
date: 2007-06-22T07:33:42-00:00

[PATCH 2/4] sysfs: Implement sysfs manged shadow directory support.
type: item
description: The problem. When implementing a network namespace I need to be able to have multiple network devices with the same name. Currently this is a problem for /sys/class/net/*, /sys/devices/virtual/net/*, and potentially a few other directories of the form /sys/ ... /net/*. What I want is for each network namespace to have it's own separate set of directories. /sys/class/net/, /sys/devices/virtual/net, and /sys/ ... /net/, and in each set I want to name them /sys/class/net/, sys/devices/virtual/net/ and /sys/ ... /net/ respectively. I looked and the VFS actually allows that. All that is needed is for /sys/class/net to implement a follow link method to redirect lookups to the real directory you want. I am calling the concept of multiple directories all at the same path in the filesystem shadow directories, the directory entry that implements the follow_link method the shadow master, and the directories that are the target of the follow link method shadow directories. It turns out that just implementing a follow_link method is not quite enough. The existince of directories of the form /sys/ ... /net/ can depend on the presence or absence of hotplug hardware, which means I need a simple race free way to create and destroy these directories. To achieve a race free design all shadow directories are created and managed by sysfs itself. The upper level code that knows what shadow directories we need provides just two methods that enable this: current_tag() - that returns a "void *" tag that identifies the context of the current process. kobject_tag(kobj) - that returns a "void *" tag that identifies the context a kobject should be in. Everything else is left up to sysfs. For the network namespace current_tag and kobject_tag are essentially one line functions, and look to remain that. The work needed in sysfs is more extensive. At each directory or symlink creation I need to check if the shadow directory it belongs in exists and if it does not create it. Likewise at each symlink…
creator: ebiederm
date: 2007-06-22T07:35:51-00:00

[PATCH 3/4] sysfs: Implement sysfs_delete_link and sysfs_rename_link
type: item
description: When removing a symlink sysfs_remove_link does not provide enough information to figure out which shadow directory the symlink falls in. So I need sysfs_delete_link which is passed the target of the symlink to delete. Further half the time when we are removing a symlink the code is actually renaming the symlink but not doing so explicitly because we don't have a symlink rename method. So I have added sysfs_rename_link as well. Both of these functions now have enough information to find a symlink in a shadow directory. The only restriction is that they must be called before the target kobject is renamed or deleted. If they are called later I loose track of which tag the target kobject was marked with and can no longer find the old symlink to remove it. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> --- fs/sysfs/symlink.c | 31 +++++++++++++++++++++++++++++++ include/linux/sysfs.h | 18 ++++++++++++++++++ 2 files changed, 49 insertions(+), 0 deletions(-) diff --git a/fs/sysfs/symlink.c b/fs/sysfs/symlink.c index ae2129c..d483d6d 100644 --- a/fs/sysfs/symlink.c +++ b/fs/sysfs/symlink.c @@ -119,6 +119,21 @@ int sysfs_create_link(struct kobject * kobj, struct kobject * target, const char /** + * sysfs_delete_link - remove symlink in object's directory. + * @kobj: object we're acting for. + * @targ: object we're pointing to. + * @name: name of the symlink to remove. + * + * Unlike sysfs_remove_link sysfs_delete_link has enough information + * to successfully delete symlinks in shadow directories. + */ +void sysfs_delete_link(struct kobject *kobj, struct kobject *targ, + const char *name) +{ + sysfs_hash_and_remove(targ, kobj->dentry,name); +} + +/** * sysfs_remove_link - remove symlink in object's directory. * @kobj: object we're acting for. * @name: name of the symlink to remove. @@ -129,6 +144,22 @@ void sysfs_remove_link(struct kobject * kobj, const char * name) sysfs_hash_and_remove(kobj, kobj->dentry,name); } +/** + * sysfs_rename_link - rename symlink in obj…
creator: ebiederm
date: 2007-06-22T07:37:30-00:00

PATCH 4/4] driver core: Implement shadow directory support for device classes.
type: item
description: This patch enables shadowing on every class directory if struct class has shadow_ops. In addition device_del and device_rename were modified to use sysfs_delete_link and sysfs_rename_link respectively to ensure when these operations happen on devices whos classes have shadow operations that they work properly. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> --- drivers/base/class.c | 30 ++++++++++++++++++++++++++---- drivers/base/core.c | 45 ++++++++++++++++++++++++--------------------- include/linux/device.h | 2 ++ 3 files changed, 52 insertions(+), 25 deletions(-) diff --git a/drivers/base/class.c b/drivers/base/class.c index 4d22226..c981f75 100644 --- a/drivers/base/class.c +++ b/drivers/base/class.c @@ -134,6 +134,17 @@ static void remove_class_attrs(struct class * cls) } } +static int class_setup_shadowing(struct class *cls) +{ + const struct shadow_dir_operations *shadow_ops; + + shadow_ops = cls->shadow_ops; + if (!shadow_ops) + return 0; + + return sysfs_enable_shadowing(&cls->subsys.kobj, shadow_ops); +} + int class_register(struct class * cls) { int error; @@ -152,11 +163,22 @@ int class_register(struct class * cls) subsys_set_kset(cls, class_subsys); error = subsystem_register(&cls->subsys); - if (!error) { - error = add_class_attrs(class_get(cls)); - class_put(cls); - } + if (error) + goto out; + + error = class_setup_shadowing(cls); + if (error) + goto out_unregister; + + error = add_class_attrs(cls); + if (error) + goto out_unregister; + +out: return error; +out_unregister: + subsystem_unregister(&cls->subsys); + goto out; } void class_unregister(struct class * cls) diff --git a/drivers/base/core.c b/drivers/base/core.c index c7543bc..b1a5241 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -622,8 +622,14 @@ static struct kobject * get_device_parent(struct device *dev, return kobj; /* or create a new class-directory at the parent device */ - return kobject_kset_add_dir(&dev->class->class_dirs, + kobj = kobject_kset_add_dir(&dev->…
creator: ebiederm
date: 2007-06-22T07:39:06-00:00

Re: [PATCH 1/4] sysfs: Remove first pass at shadow directory support
type: item
description: Eric, Thanks a lot for the updated patchset. I haven't look at the details yet, but I've already integrated it to your network namespaces patchset and ported the whole thing to 2.6.22-rc4-mm2 today. It is far easier to do when you don't have to think about the sysfs stuff :) I only performed some basic testing on it so far as I'm home today, but it already seems to work better than the patchset I ported to 2.6.21-mm2. It solves the issues I still had with sysfs. Thanks again. Regards, Benjamin Eric W. Biederman wrote: > While shadow directories appear to be a good idea, the current scheme > of controlling their creation and destruction outside of sysfs appears > to be a locking and maintenance nightmare in the face of sysfs > directories dynamically coming and going. Which can now occur for > directories containing network devices when CONFIG_SYSFS_DEPRECATED is > not set. > > This patch removes everything from the initial shadow directory > support that allowed the shadow directory creation to be controlled at > a higher level. So except for a few bits of sysfs_rename_dir > everything from commit b592fcfe7f06c15ec11774b5be7ce0de3aa86e73 is now > gone. > > Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> > --- > These patches are against 2.6.22-rc4-mm2 Hopefully that is new enough > to catch all of the in flight sysfs patches. > > fs/sysfs/dir.c | 172 ++++++++++------------------------------------- > fs/sysfs/group.c | 1 - > fs/sysfs/inode.c | 10 --- > fs/sysfs/mount.c | 2 +- > fs/sysfs/sysfs.h | 6 -- > include/linux/kobject.h | 4 - > include/linux/sysfs.h | 24 +------ > lib/kobject.c | 44 ++---------- > 8 files changed, 48 insertions(+), 215 deletions(-) > > diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c > index b4074ad..b1da4fc 100644 > --- a/fs/sysfs/dir.c > +++ b/fs/sysfs/dir.c > @@ -415,10 +415,9 @@ int sysfs_create_subdir(struct kobject * k, const char * n, struct dentry ** d) > /** > * sysfs_create_dir - create a directory for an object. > * @kobj: obje…
creator: Benjamin Thery
date: 2007-06-22T14:42:01-00:00

Re: [PATCH 1/4] sysfs: Remove first pass at shadow directory support
type: item
description: On Fri, Jun 22, 2007 at 01:33:42AM -0600, Eric W. Biederman wrote: > > While shadow directories appear to be a good idea, the current scheme > of controlling their creation and destruction outside of sysfs appears > to be a locking and maintenance nightmare in the face of sysfs > directories dynamically coming and going. Which can now occur for > directories containing network devices when CONFIG_SYSFS_DEPRECATED is > not set. > > This patch removes everything from the initial shadow directory > support that allowed the shadow directory creation to be controlled at > a higher level. So except for a few bits of sysfs_rename_dir > everything from commit b592fcfe7f06c15ec11774b5be7ce0de3aa86e73 is now > gone. > > Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> > --- > These patches are against 2.6.22-rc4-mm2 Hopefully that is new enough > to catch all of the in flight sysfs patches. Ick, no, it isn't and doesn't apply at all :( Can you try the next -mm release? thanks, greg k-h _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Greg KH
date: 2007-06-25T21:23:39-00:00

Re: [PATCH 1/4] sysfs: Remove first pass at shadow directory support
type: item
description: Greg KH <greg@kroah.com> writes: > Ick, no, it isn't and doesn't apply at all :( Groan. I wonder what changed this time... > Can you try the next -mm release? Ok. As soon as I get back from OLS, I will rebase against whatever is current. Eric _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: ebiederm
date: 2007-06-26T00:50:19-00:00

[PATCH 1/4] sysfs: Remove first pass at shadow directory support
type: item
description: While shadow directories appear to be a good idea, the current scheme of controlling their creation and destruction outside of sysfs appears to be a locking and maintenance nightmare in the face of sysfs directories dynamically coming and going. Which can now occur for directories containing network devices when CONFIG_SYSFS_DEPRECATED is not set. This patch removes everything from the initial shadow directory support that allowed the shadow directory creation to be controlled at a higher level. So except for a few bits of sysfs_rename_dir everything from commit b592fcfe7f06c15ec11774b5be7ce0de3aa86e73 is now gone. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> --- This patchset is against 589f1e81bde732dd0b1bc5d01b6bddd4bcb4527b in Linus's tree. I took a quick skim through your tree and all of the sysfs patches appear to be merged. Sorry for taking so long getting this done but the locking changes in the last round for Tejun were significant. Plus there was some additional work needed to actually test the shadow directory support. fs/sysfs/dir.c | 167 ++++++---------------------------------------- fs/sysfs/group.c | 1 - fs/sysfs/inode.c | 10 --- fs/sysfs/mount.c | 2 +- fs/sysfs/sysfs.h | 6 -- include/linux/kobject.h | 5 -- include/linux/sysfs.h | 27 +------- lib/kobject.c | 44 ++----------- 8 files changed, 33 insertions(+), 229 deletions(-) diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c index 048e605..f88130c 100644 --- a/fs/sysfs/dir.c +++ b/fs/sysfs/dir.c @@ -569,9 +569,6 @@ static void sysfs_drop_dentry(struct sysfs_dirent *sd) spin_unlock(&dcache_lock); spin_unlock(&sysfs_assoc_lock); - /* dentries for shadowed inodes are pinned, unpin */ - if (dentry && sysfs_is_shadowed_inode(dentry->d_inode)) - dput(dentry); dput(dentry); /* adjust nlink and update timestamp */ @@ -723,19 +720,15 @@ int sysfs_create_subdir(struct kobject *kobj, const char *name, /** * sysfs_create_dir - create a directory for an object. * @kobj: object we're creating directory for. …
creator: ebiederm
date: 2007-07-19T04:43:46-00:00

[PATCH 2/4] sysfs: Implement sysfs manged shadow directory support.
type: item
description: The problem. When implementing a network namespace I need to be able to have multiple network devices with the same name. Currently this is a problem for /sys/class/net/*, /sys/devices/virtual/net/*, and potentially a few other directories of the form /sys/ ... /net/*. What I want is for each network namespace to have it's own separate set of directories. /sys/class/net/, /sys/devices/virtual/net, and /sys/ ... /net/, and in each set I want to name them /sys/class/net/, sys/devices/virtual/net/ and /sys/ ... /net/ respectively. I looked and the VFS actually allows that. All that is needed is for /sys/class/net to implement a follow link method to redirect lookups to the real directory you want. I am calling the concept of multiple directories all at the same path in the filesystem shadow directories, the directory entry that implements the follow_link method the shadow master, and the directories that are the target of the follow link method shadow directories. It turns out that just implementing a follow_link method is not quite enough. The existince of directories of the form /sys/ ... /net/ can depend on the presence or absence of hotplug hardware, which means I need a simple race free way to create and destroy these directories. To achieve a race free design all shadow directories are created and managed by sysfs itself. The upper level code that knows what shadow directories we need provides just two methods that enable this: current_tag() - that returns a "void *" tag that identifies the context of the current process. kobject_tag(kobj) - that returns a "void *" tag that identifies the context a kobject should be in. Everything else is left up to sysfs. For the network namespace current_tag and kobject_tag are essentially one line functions, and look to remain that. The work needed in sysfs is more extensive. At each directory or symlink creation I need to check if the shadow directory it belongs in exists and if it does not create it. Likewise at each symlink…
creator: ebiederm
date: 2007-07-19T04:45:13-00:00

[PATCH 3/4] sysfs: Implement sysfs_delete_link and sysfs_rename_link
type: item
description: When removing a symlink sysfs_remove_link does not provide enough information to figure out which shadow directory the symlink falls in. So I need sysfs_delete_link which is passed the target of the symlink to delete. Further half the time when we are removing a symlink the code is actually renaming the symlink but not doing so explicitly because we don't have a symlink rename method. So I have added sysfs_rename_link as well. Both of these functions now have enough information to find a symlink in a shadow directory. The only restriction is that they must be called before the target kobject is renamed or deleted. If they are called later I loose track of which tag the target kobject was marked with and can no longer find the old symlink to remove it. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> --- fs/sysfs/symlink.c | 31 +++++++++++++++++++++++++++++++ include/linux/sysfs.h | 18 ++++++++++++++++++ 2 files changed, 49 insertions(+), 0 deletions(-) diff --git a/fs/sysfs/symlink.c b/fs/sysfs/symlink.c index e52d3ef..62b0aeb 100644 --- a/fs/sysfs/symlink.c +++ b/fs/sysfs/symlink.c @@ -126,6 +126,21 @@ addrm_finish: /** + * sysfs_delete_link - remove symlink in object's directory. + * @kobj: object we're acting for. + * @targ: object we're pointing to. + * @name: name of the symlink to remove. + * + * Unlike sysfs_remove_link sysfs_delete_link has enough information + * to successfully delete symlinks in shadow directories. + */ +void sysfs_delete_link(struct kobject *kobj, struct kobject *targ, + const char *name) +{ + sysfs_hash_and_remove(targ, kobj->sd, name); +} + +/** * sysfs_remove_link - remove symlink in object's directory. * @kobj: object we're acting for. * @name: name of the symlink to remove. @@ -136,6 +151,22 @@ void sysfs_remove_link(struct kobject * kobj, const char * name) sysfs_hash_and_remove(kobj, kobj->sd, name); } +/** + * sysfs_rename_link - rename symlink in object's directory. + * @kobj: object we're acting for. + * @targ: object we…
creator: ebiederm
date: 2007-07-19T04:46:39-00:00

[PATCH 4/4] driver core: Implement shadow directory support for device classes.
type: item
description: This patch enables shadowing on every class directory if struct class has shadow_ops. In addition device_del and device_rename were modified to use sysfs_delete_link and sysfs_rename_link respectively to ensure when these operations happen on devices whos classes have shadow operations that they work properly. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> --- drivers/base/class.c | 30 ++++++++++++++++++++++++++---- drivers/base/core.c | 45 ++++++++++++++++++++++++--------------------- include/linux/device.h | 2 ++ 3 files changed, 52 insertions(+), 25 deletions(-) diff --git a/drivers/base/class.c b/drivers/base/class.c index 4d22226..c981f75 100644 --- a/drivers/base/class.c +++ b/drivers/base/class.c @@ -134,6 +134,17 @@ static void remove_class_attrs(struct class * cls) } } +static int class_setup_shadowing(struct class *cls) +{ + const struct shadow_dir_operations *shadow_ops; + + shadow_ops = cls->shadow_ops; + if (!shadow_ops) + return 0; + + return sysfs_enable_shadowing(&cls->subsys.kobj, shadow_ops); +} + int class_register(struct class * cls) { int error; @@ -152,11 +163,22 @@ int class_register(struct class * cls) subsys_set_kset(cls, class_subsys); error = subsystem_register(&cls->subsys); - if (!error) { - error = add_class_attrs(class_get(cls)); - class_put(cls); - } + if (error) + goto out; + + error = class_setup_shadowing(cls); + if (error) + goto out_unregister; + + error = add_class_attrs(cls); + if (error) + goto out_unregister; + +out: return error; +out_unregister: + subsystem_unregister(&cls->subsys); + goto out; } void class_unregister(struct class * cls) diff --git a/drivers/base/core.c b/drivers/base/core.c index 3599ab2..5b03842 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -639,8 +639,14 @@ static struct kobject * get_device_parent(struct device *dev, return kobj; /* or create a new class-directory at the parent device */ - return kobject_kset_add_dir(&dev->class->class_dirs, + kobj = kobject_kset_add_dir(&dev->…
creator: ebiederm
date: 2007-07-19T04:47:27-00:00

patch driver-core-implement-shadow-directory-support-for-device-classes.patch added to gregkh-2.6 tr
type: item
description: This is a note to let you know that I've just added the patch titled Subject: [PATCH 4/4] driver core: Implement shadow directory support for device classes. to my gregkh-2.6 tree. Its filename is driver-core-implement-shadow-directory-support-for-device-classes.patch This tree can be found at http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/ >From ebiederm@xmission.com Fri Jul 20 23:21:18 2007 From: ebiederm@xmission.com (Eric W. Biederman) Date: Wed, 18 Jul 2007 22:47:27 -0600 Subject: [PATCH 4/4] driver core: Implement shadow directory support for device classes. To: Greg KH <greg@kroah.com> Cc: Greg KH <gregkh@suse.de>, Dave Hansen <hansendc@us.ibm.com>, Benjamin Thery <benjamin.thery@bull.net>, Linux Containers <containers@lists.osdl.org>, Tejun Heo <htejun@gmail.com> Message-ID: <m1r6n52e5c.fsf_-_@ebiederm.dsl.xmission.com> This patch enables shadowing on every class directory if struct class has shadow_ops. In addition device_del and device_rename were modified to use sysfs_delete_link and sysfs_rename_link respectively to ensure when these operations happen on devices whos classes have shadow operations that they work properly. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Cc: Tejun Heo <htejun@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- drivers/base/class.c | 30 ++++++++++++++++++++++++++---- drivers/base/core.c | 45 ++++++++++++++++++++++++--------------------- include/linux/device.h | 2 ++ 3 files changed, 52 insertions(+), 25 deletions(-) --- a/drivers/base/class.c +++ b/drivers/base/class.c @@ -134,6 +134,17 @@ static void remove_class_attrs(struct cl } } +static int class_setup_shadowing(struct class *cls) +{ + const struct shadow_dir_operations *shadow_ops; + + shadow_ops = cls->shadow_ops; + if (!shadow_ops) + return 0; + + return sysfs_enable_shadowing(&cls->subsys.kobj, shadow_ops); +} + int class_register(struct class * cls) { int error; @@ -152,11 +163,22 @@ int class_register(struct class *…
creator: gregkh
date: 2007-07-21T06:36:02-00:00

patch sysfs-implement-sysfs-manged-shadow-directory-support.patch added to gregkh-2.6 tree
type: item
description: This is a note to let you know that I've just added the patch titled Subject: [PATCH 2/4] sysfs: Implement sysfs manged shadow directory support. to my gregkh-2.6 tree. Its filename is sysfs-implement-sysfs-manged-shadow-directory-support.patch This tree can be found at http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/ >From ebiederm@xmission.com Fri Jul 20 23:20:42 2007 From: ebiederm@xmission.com (Eric W. Biederman) Date: Wed, 18 Jul 2007 22:45:13 -0600 Subject: [PATCH 2/4] sysfs: Implement sysfs manged shadow directory support. To: Greg KH <greg@kroah.com> Cc: Greg KH <gregkh@suse.de>, Dave Hansen <hansendc@us.ibm.com>, Benjamin Thery <benjamin.thery@bull.net>, Linux Containers <containers@lists.osdl.org>, Tejun Heo <htejun@gmail.com> Message-ID: <m1zm1t2e92.fsf_-_@ebiederm.dsl.xmission.com> The problem. When implementing a network namespace I need to be able to have multiple network devices with the same name. Currently this is a problem for /sys/class/net/*, /sys/devices/virtual/net/*, and potentially a few other directories of the form /sys/ ... /net/*. What I want is for each network namespace to have it's own separate set of directories. /sys/class/net/, /sys/devices/virtual/net, and /sys/ ... /net/, and in each set I want to name them /sys/class/net/, sys/devices/virtual/net/ and /sys/ ... /net/ respectively. I looked and the VFS actually allows that. All that is needed is for /sys/class/net to implement a follow link method to redirect lookups to the real directory you want. I am calling the concept of multiple directories all at the same path in the filesystem shadow directories, the directory entry that implements the follow_link method the shadow master, and the directories that are the target of the follow link method shadow directories. It turns out that just implementing a follow_link method is not quite enough. The existince of directories of the form /sys/ ... /net/ can depend on the presence or absence of hotplug hardware, w…
creator: gregkh
date: 2007-07-21T06:36:16-00:00

patch sysfs-implement-sysfs_delete_link-and-sysfs_rename_link.patch added to gregkh-2.6 tree
type: item
description: This is a note to let you know that I've just added the patch titled Subject: [PATCH 3/4] sysfs: Implement sysfs_delete_link and sysfs_rename_link to my gregkh-2.6 tree. Its filename is sysfs-implement-sysfs_delete_link-and-sysfs_rename_link.patch This tree can be found at http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/ >From ebiederm@xmission.com Fri Jul 20 23:21:06 2007 From: ebiederm@xmission.com (Eric W. Biederman) Date: Wed, 18 Jul 2007 22:46:39 -0600 Subject: [PATCH 3/4] sysfs: Implement sysfs_delete_link and sysfs_rename_link To: Greg KH <greg@kroah.com> Cc: Greg KH <gregkh@suse.de>, Dave Hansen <hansendc@us.ibm.com>, Benjamin Thery <benjamin.thery@bull.net>, Linux Containers <containers@lists.osdl.org>, Tejun Heo <htejun@gmail.com> Message-ID: <m1vech2e6o.fsf_-_@ebiederm.dsl.xmission.com> When removing a symlink sysfs_remove_link does not provide enough information to figure out which shadow directory the symlink falls in. So I need sysfs_delete_link which is passed the target of the symlink to delete. Further half the time when we are removing a symlink the code is actually renaming the symlink but not doing so explicitly because we don't have a symlink rename method. So I have added sysfs_rename_link as well. Both of these functions now have enough information to find a symlink in a shadow directory. The only restriction is that they must be called before the target kobject is renamed or deleted. If they are called later I loose track of which tag the target kobject was marked with and can no longer find the old symlink to remove it. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Cc: Tejun Heo <htejun@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- fs/sysfs/symlink.c | 31 +++++++++++++++++++++++++++++++ include/linux/sysfs.h | 18 ++++++++++++++++++ 2 files changed, 49 insertions(+) --- a/fs/sysfs/symlink.c +++ b/fs/sysfs/symlink.c @@ -126,6 +126,21 @@ addrm_finish: /** + * sysfs_delete_link - remove syml…
creator: gregkh
date: 2007-07-21T06:36:23-00:00

patch sysfs-remove-first-pass-at-shadow-directory-support.patch added to gregkh-2.6 tree
type: item
description: This is a note to let you know that I've just added the patch titled Subject: [PATCH 1/4] sysfs: Remove first pass at shadow directory support to my gregkh-2.6 tree. Its filename is sysfs-remove-first-pass-at-shadow-directory-support.patch This tree can be found at http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/ >From ebiederm@xmission.com Fri Jul 20 23:20:07 2007 From: ebiederm@xmission.com (Eric W. Biederman) Date: Wed, 18 Jul 2007 22:43:46 -0600 Subject: [PATCH 1/4] sysfs: Remove first pass at shadow directory support To: Greg KH <greg@kroah.com> Cc: Greg KH <gregkh@suse.de>, Dave Hansen <hansendc@us.ibm.com>, Benjamin Thery <benjamin.thery@bull.net>, Linux Containers <containers@lists.osdl.org>, Tejun Heo <htejun@gmail.com> Message-ID: <m14pk13svx.fsf@ebiederm.dsl.xmission.com> While shadow directories appear to be a good idea, the current scheme of controlling their creation and destruction outside of sysfs appears to be a locking and maintenance nightmare in the face of sysfs directories dynamically coming and going. Which can now occur for directories containing network devices when CONFIG_SYSFS_DEPRECATED is not set. This patch removes everything from the initial shadow directory support that allowed the shadow directory creation to be controlled at a higher level. So except for a few bits of sysfs_rename_dir everything from commit b592fcfe7f06c15ec11774b5be7ce0de3aa86e73 is now gone. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- fs/sysfs/dir.c | 167 ++++++------------------------------------------ fs/sysfs/group.c | 1 fs/sysfs/inode.c | 10 -- fs/sysfs/mount.c | 2 fs/sysfs/sysfs.h | 6 - include/linux/kobject.h | 5 - include/linux/sysfs.h | 27 +------ lib/kobject.c | 44 +----------- 8 files changed, 33 insertions(+), 229 deletions(-) --- a/fs/sysfs/dir.c +++ b/fs/sysfs/dir.c @@ -569,9 +569,6 @@ static void sysfs_drop_dentry(struct sys spin_unlock(&dcache_lock); spin_unl…
creator: gregkh
date: 2007-07-21T06:36:28-00:00

Re: patch driver-core-implement-shadow-directory-support-for-device-classes.patch added to gregkh-2.
type: item
description: <gregkh@suse.de> writes: > This is a note to let you know that I've just added the patch titled > > Subject: [PATCH 4/4] driver core: Implement shadow directory support for > device classes. > > to my gregkh-2.6 tree. Its filename is > > driver-core-implement-shadow-directory-support-for-device-classes.patch > > This tree can be found at > http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/ Hip hip hooray. The patches finally apply!!!! Eric _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: ebiederm
date: 2007-07-21T10:00:43-00:00

Re: [PATCH 1/4] sysfs: Remove first pass at shadow directory support
type: item
description: Hello, Hope my late review isn't too late. Eric W. Biederman wrote: > While shadow directories appear to be a good idea, the current scheme > of controlling their creation and destruction outside of sysfs appears > to be a locking and maintenance nightmare in the face of sysfs > directories dynamically coming and going. Yeah, shadow directory was a real PITA while restructuring sysfs. I tried hard to keep it working but, without test case and detailed documentation, I'm pretty sure I broke something. My feeling was that it was merged too early and implementation was too tightly coupled with other more regular paths. Anyways, glad shadow dirs are getting some loving care. If properly done, we should be able to simplify sysfs_get_dentry(), removal logic and save a pointer in sysfs_dirent. > Which can now occur for > directories containing network devices when CONFIG_SYSFS_DEPRECATED is > not set. Shadow directories were always pinned - both the shadowed one and shadows. Well, that was the theory at least. > -int sysfs_rename_dir(struct kobject *kobj, struct sysfs_dirent *new_parent_sd, > - const char *new_name) > +int sysfs_rename_dir(struct kobject * kobj, const char *new_name) > { > - struct sysfs_dirent *sd = kobj->sd; > - struct dentry *new_parent = NULL; > + struct sysfs_dirent *sd; > + struct dentry *parent = NULL; > struct dentry *old_dentry = NULL, *new_dentry = NULL; > + struct sysfs_dirent *parent_sd; > const char *dup_name = NULL; > int error; > > + if (!kobj->parent) > + return -EINVAL; Please don't do this. The goal is to decouple sysfs and kobj. > /* get dentries */ > + sd = kobj->sd; > old_dentry = sysfs_get_dentry(sd); > if (IS_ERR(old_dentry)) { > error = PTR_ERR(old_dentry); > goto out_dput; > } > > - new_parent = sysfs_get_dentry(new_parent_sd); > - if (IS_ERR(new_parent)) { > - error = PTR_ERR(new_parent); > + parent_sd = kobj->parent->sd; > + parent = sysfs_get_dentry(parent_sd); > + if (IS_ERR(parent)) { > + error = PTR_ERR(parent); > goto out_dp…
creator: Tejun Heo
date: 2007-07-22T18:35:27-00:00

Re: [PATCH 1/4] sysfs: Remove first pass at shadow directory support
type: item
description: Tejun Heo <htejun@gmail.com> writes: > Hello, > > Hope my late review isn't too late. > > Eric W. Biederman wrote: >> While shadow directories appear to be a good idea, the current scheme >> of controlling their creation and destruction outside of sysfs appears >> to be a locking and maintenance nightmare in the face of sysfs >> directories dynamically coming and going. > > Yeah, shadow directory was a real PITA while restructuring sysfs. I > tried hard to keep it working but, without test case and detailed > documentation, I'm pretty sure I broke something. > > My feeling was that it was merged too early and implementation was too > tightly coupled with other more regular paths. It's a problem because sysfs has this tendency especially before your cleanups to be tightly coupled. But yes the original implementation was probably factored at the wrong level, not giving sysfs enough responsibility. Which became apparent when the single objects started living all over the sysfs tree. > Anyways, glad shadow > dirs are getting some loving care. If properly done, we should be able > to simplify sysfs_get_dentry(), removal logic and save a pointer in > sysfs_dirent. Hopefully. The logic in sysfs_resolve_for_create (i.e. which shadow dir do you intend to create something is tricky with the current locking logic). >> Which can now occur for >> directories containing network devices when CONFIG_SYSFS_DEPRECATED is >> not set. > > Shadow directories were always pinned - both the shadowed one and > shadows. Well, that was the theory at least. Yes. The difference I was referring to was: /sys/class/net/ used to be the only directory I needed to shadow. Now there is one net/ in each networking device and several other little things. >> -int sysfs_rename_dir(struct kobject *kobj, struct sysfs_dirent > *new_parent_sd, >> - const char *new_name) >> +int sysfs_rename_dir(struct kobject * kobj, const char *new_name) >> { >> - struct sysfs_dirent *sd = kobj->sd; >> - struct dentry *new_p…
creator: ebiederm
date: 2007-07-22T19:17:18-00:00

Re: [PATCH 2/4] sysfs: Implement sysfs manged shadow directory support.
type: item
description: Hello, Eric W. Biederman wrote: > diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c > +static struct sysfs_dirent *find_shadow_sd(struct sysfs_dirent *parent_sd, const void *target) > +{ > + /* Find the shadow directory for the specified tag */ > + struct sysfs_dirent *sd; > + > + for (sd = parent_sd->s_children; sd; sd = sd->s_sibling) { > + if (sd->s_name != target) > + continue; This is way too cryptic and, plus, no comment. This kind of stuff can cause a lot of confusion later when other people wanna work on the code. Please move s_name into sysfs_elem_* which need s_name and create sysfs_elem_shadow which doesn't have ->name but has ->tag. > +static const void *find_shadow_tag(struct kobject *kobj) > +{ > + /* Find the tag the current kobj is cached with */ > + return kobj->sd->s_parent->s_name; > +} Please don't use kobj inside sysfs. Use sysfs_dirent instead. > @@ -414,7 +436,8 @@ static void sysfs_attach_dentry(struct sysfs_dirent *sd, struct dentry *dentry) > sd->s_dentry = dentry; > spin_unlock(&sysfs_assoc_lock); > > - d_rehash(dentry); > + if (dentry->d_flags & DCACHE_UNHASHED) > + d_rehash(dentry); I think we can use some comment for subtle things like this. DCACHE_UNHASHED is being tested without holding dcache_lock which also can use some comment. > @@ -569,6 +592,10 @@ static void sysfs_drop_dentry(struct sysfs_dirent *sd) > spin_unlock(&dcache_lock); > spin_unlock(&sysfs_assoc_lock); > > + /* dentries for shadowed directories are pinned, unpin */ > + if ((sysfs_type(sd) == SYSFS_SHADOW_DIR) || > + (sd->s_flags & SYSFS_FLAG_SHADOWED)) > + dput(dentry); > dput(dentry); > > /* adjust nlink and update timestamp */ > @@ -622,6 +649,7 @@ int sysfs_addrm_finish(struct sysfs_addrm_cxt *acxt) > acxt->removed = sd->s_sibling; > sd->s_sibling = NULL; > > + sysfs_prune_shadow_sd(sd->s_parent); > sysfs_drop_dentry(sd); > sysfs_deactivate(sd); > sysfs_put(sd); > @@ -687,6 +715,7 @@ static int create_dir(struct kobject *kobj, struct sysfs_dirent *parent_sd, > umode_t m…
creator: Tejun Heo
date: 2007-07-22T19:47:21-00:00

Re: [PATCH 2/4] sysfs: Implement sysfs manged shadow directory support.
type: item
description: On Mon, Jul 23, 2007 at 04:47:21AM +0900, Tejun Heo wrote: > Sorry but I don't think the current approach is the correct one. It's > too painful and too much complexity is scattered all over the place. > I'm afraid this implementation is going to be a maintenance nightmare. In looking over this again, and due to the fact that there are no in-kernel users of this code, I'm going to drop the other patches in this series and only keep the first one that removes the current implementation. Eric, is that ok? It gives you time to revisit these changes. thanks, greg k-h _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: gregkh
date: 2007-07-22T20:25:08-00:00

Re: [PATCH 2/4] sysfs: Implement sysfs manged shadow directory support.
type: item
description: Tejun Heo <htejun@gmail.com> writes: > Hello, > > Eric W. Biederman wrote: >> diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c >> +static struct sysfs_dirent *find_shadow_sd(struct sysfs_dirent > *parent_sd, const void *target) >> +{ >> + /* Find the shadow directory for the specified tag */ >> + struct sysfs_dirent *sd; >> + >> + for (sd = parent_sd->s_children; sd; sd = sd->s_sibling) { >> + if (sd->s_name != target) >> + continue; > > This is way too cryptic and, plus, no comment. This kind of stuff can > cause a lot of confusion later when other people wanna work on the > code. Please move s_name into sysfs_elem_* which need s_name and > create sysfs_elem_shadow which doesn't have ->name but has ->tag. I'm been staring at this to long to know. I just know the name is more or less reasonable and following how it is called tends to show what it is used for. In one sense the name is very much the tag. So I don't feel bad about using it that way. In another sense if we can cleanup the code by having the s_name field be a string that would be an improvement and be appreciated. >> +static const void *find_shadow_tag(struct kobject *kobj) >> +{ >> + /* Find the tag the current kobj is cached with */ >> + return kobj->sd->s_parent->s_name; >> +} > > Please don't use kobj inside sysfs. Use sysfs_dirent instead. The interface to sysfs is kobjects and names, so I'm limited in what I can do. Where this is used I know a directory and a name I want to remove. What I don't necessarily know is which shadow of that directory I want to remove from without looking at the kobject. sysfs_delete_link is a good code path to follow to understand this. >> @@ -414,7 +436,8 @@ static void sysfs_attach_dentry(struct > sysfs_dirent *sd, struct dentry *dentry) >> sd->s_dentry = dentry; >> spin_unlock(&sysfs_assoc_lock); >> >> - d_rehash(dentry); >> + if (dentry->d_flags & DCACHE_UNHASHED) >> + d_rehash(dentry); > > I think we can use some comment for subtle things like this. > DCACHE_UNHASHED is…
creator: ebiederm
date: 2007-07-22T22:07:32-00:00

Re: [PATCH 2/4] sysfs: Implement sysfs manged shadow directory support.
type: item
description: Greg KH <gregkh@suse.de> writes: > On Mon, Jul 23, 2007 at 04:47:21AM +0900, Tejun Heo wrote: >> Sorry but I don't think the current approach is the correct one. It's >> too painful and too much complexity is scattered all over the place. >> I'm afraid this implementation is going to be a maintenance nightmare. > > In looking over this again, and due to the fact that there are no > in-kernel users of this code, I'm going to drop the other patches in > this series and only keep the first one that removes the current > implementation. > > Eric, is that ok? It gives you time to revisit these changes. Greg a big part of the reason I don't have internal kernel users is keeping up with changes of sysfs has meant I haven't had time to clean up and submit the patches for the users. With a little luck I will have users by 2.6.24. I am in the process of cleaning up those patches right now. So I can send the off to Dave Miller. So please can we try and at least keep these sysfs patches in a development tree so that people will see them. Further while there are a few little nits I think mostly Tejun is mostly objecting to the fundamental complexity of the problem rather then to things that can be fixed by a cleaner implementation. If it didn't take me a week every time I had to update this code after Tejun changes the locking rules in fs/sysfs/dir.c or if there was someone I could delegate the work of maintaining this code to I probably would not mind dropping the patches for a little bit. As it stands I am having horrible nightmares about how the internals of sysfs will be completely different if you drop the last 3 patches by the time I come back and I will need to spend several more weeks just catching up. Eric _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: ebiederm
date: 2007-07-22T22:19:42-00:00

Re: [PATCH 2/4] sysfs: Implement sysfs manged shadow directory support.
type: item
description: Eric W. Biederman wrote: > Further while there are a few little nits I think mostly Tejun is > mostly objecting to the fundamental complexity of the problem rather > then to things that can be fixed by a cleaner implementation. Oh well, I don't think so but I might be wrong. > If it didn't take me a week every time I had to update this code > after Tejun changes the locking rules in fs/sysfs/dir.c or if there > was someone I could delegate the work of maintaining this code to > I probably would not mind dropping the patches for a little bit. As > it stands I am having horrible nightmares about how the internals > of sysfs will be completely different if you drop the last 3 patches > by the time I come back and I will need to spend several more weeks > just catching up. Yeah, sysfs has gone through a lot of changes but I think most of internal restructuring is complete now. What's left is removing kobj completely from sysfs internals and interface. We kind of share the pain here although yours seems much worse than mine. Shadow directories have been major pain in the ass while restructuring sysfs and I basically had to shoot in the dark because there was no in-kernel user. I guess the blame falls on the timing. I'll give a shot at the no intermediate shadowed directory implementation. I think things will fit a lot easier that way but I really dunno till I try. I'll try to post prototype early. As long as the current shadow implementation doesn't get into mainline. I'm okay with it staying in Greg's tree until this is resolved. Thanks. -- tejun _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Tejun Heo
date: 2007-07-23T03:52:25-00:00

Re: [PATCH 2/4] sysfs: Implement sysfs manged shadow directory support.
type: item
description: On Mon, Jul 23, 2007 at 12:52:25PM +0900, Tejun Heo wrote: > Eric W. Biederman wrote: > > Further while there are a few little nits I think mostly Tejun is > > mostly objecting to the fundamental complexity of the problem rather > > then to things that can be fixed by a cleaner implementation. > > Oh well, I don't think so but I might be wrong. > > > If it didn't take me a week every time I had to update this code > > after Tejun changes the locking rules in fs/sysfs/dir.c or if there > > was someone I could delegate the work of maintaining this code to > > I probably would not mind dropping the patches for a little bit. As > > it stands I am having horrible nightmares about how the internals > > of sysfs will be completely different if you drop the last 3 patches > > by the time I come back and I will need to spend several more weeks > > just catching up. > > Yeah, sysfs has gone through a lot of changes but I think most of > internal restructuring is complete now. What's left is removing kobj > completely from sysfs internals and interface. > > We kind of share the pain here although yours seems much worse than > mine. Shadow directories have been major pain in the ass while > restructuring sysfs and I basically had to shoot in the dark because > there was no in-kernel user. I guess the blame falls on the timing. > > I'll give a shot at the no intermediate shadowed directory > implementation. I think things will fit a lot easier that way but I > really dunno till I try. I'll try to post prototype early. > > As long as the current shadow implementation doesn't get into mainline. > I'm okay with it staying in Greg's tree until this is resolved. Don't worry, I will not be sending it on to Linus unless you give the ok to do so :) thanks, greg k-h _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: gregkh
date: 2007-07-24T07:26:19-00:00

Re: [PATCH 2/4] sysfs: Implement sysfs manged shadow directory support.
type: item
description: Hello, Okay, some questions. * What do you think about not allowing duplicate names across different tags? ie. there's only one ethX anywhere but it's visible only in a specific namespace (and maybe in the default global one). Or does everyone need its own eth0. If this is acceptable, the problem becomes _much_ simpler. * I think we can do away with the magic tag and use a pointer to vfsmount instead. So, a process which wants to be in certain namespace can bind-mount /sysfs to its own /sysfs and make needed sysfs nodes bound to the mount. Does this sound okay? Such process should probably be in its own chrooted environment to function properly. * I haven't really followed the containers thread. Do people generally agree on including it in mainline when we have all the fancy virtualization stuff? Thanks. -- tejun _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Tejun Heo
date: 2007-07-26T08:00:05-00:00

Re: Re: [PATCH 2/4] sysfs: Implement sysfs manged shadow directory support.
type: item
description: Tejun Heo wrote: > Hello, > > Okay, some questions. > > * What do you think about not allowing duplicate names across different > tags? ie. there's only one ethX anywhere but it's visible only in a > specific namespace (and maybe in the default global one). Or does > everyone need its own eth0. If this is acceptable, the problem becomes > _much_ simpler. at least on checkpoint/restart names should be restored as is and conflicts are unavoidable. this includes ifindex as well by the way. > * I think we can do away with the magic tag and use a pointer to > vfsmount instead. So, a process which wants to be in certain namespace > can bind-mount /sysfs to its own /sysfs and make needed sysfs nodes > bound to the mount. Does this sound okay? Such process should probably > be in its own chrooted environment to function properly. > > * I haven't really followed the containers thread. Do people generally > agree on including it in mainline when we have all the fancy > virtualization stuff? Thanks, Kirill _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: dev
date: 2007-07-27T10:58:23-00:00

Re: [PATCH 2/4] sysfs: Implement sysfs manged shadow directory support.
type: item
description: Hi, On 26.07.2007 10:00, Tejun Heo wrote: > Okay, some questions. > > * What do you think about not allowing duplicate names across different > tags? ie. there's only one ethX anywhere but it's visible only in a > specific namespace (and maybe in the default global one). Or does > everyone need its own eth0. If this is acceptable, the problem becomes > _much_ simpler. Duplicating names across different namespaces (eth0 for everyone) is a feature which allows me to use a very similar configurations for different namespaces. There's also a security argument saying that one namespace shouldn't be able to infer information about other namespaces. If an interface name must not be reused across namespaces you can enumerate the obvious interface name list from any namespace and find out which interface names are used by other namespaces. I'm not suggesting that this argument is valid, but it needs to be considered and if we decide it is invalid, we should document why. Regards, Carl-Daniel _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Carl-Daniel Hailfinge
date: 2007-07-27T20:59:30-00:00

Re: [PATCH 2/4] sysfs: Implement sysfs manged shadow directory support.
type: item
description: Hello, Eric. Tejun Heo wrote: > Eric W. Biederman wrote: >> Further while there are a few little nits I think mostly Tejun is >> mostly objecting to the fundamental complexity of the problem rather >> then to things that can be fixed by a cleaner implementation. > > Oh well, I don't think so but I might be wrong. And I'm wrong. Mine didn't turn out to be much cleaner than yours. What I did was (still broken)... * No shadower/shadowee. Each dentry is tagged. * dentries of tagged sd's are taken out of dcache and always go through ->lookup() where the correct sd is looked up considering the current tag. Tagging and adding new entries could be done rather cleanly but shooting down existing dentries on rename/move turned out to be a mess. Things will be much simpler if no sysfs dentry is hashed on dcache and always go through ->lookup() but that will hurt big machines. The basic problem here is that dcache layer doesn't allow different views and sysfs shadow is trying to work behind its back. I don't think this is a viable approach. Both implementations bend too many rules and are too fragile. It will be a genuine pain in the ass to maintain. Sorry that I can't come up with an alternative but NACK. -- tejun _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Tejun Heo
date: 2007-07-30T07:09:06-00:00

Re: [PATCH 2/4] sysfs: Implement sysfs manged shadow directory support.
type: item
description: Tejun Heo wrote: > Hello, Eric. > > Tejun Heo wrote: > >>Eric W. Biederman wrote: >> >>>Further while there are a few little nits I think mostly Tejun is >>>mostly objecting to the fundamental complexity of the problem rather >>>then to things that can be fixed by a cleaner implementation. >> >>Oh well, I don't think so but I might be wrong. > > > And I'm wrong. Mine didn't turn out to be much cleaner than yours. > What I did was (still broken)... > > * No shadower/shadowee. Each dentry is tagged. > * dentries of tagged sd's are taken out of dcache and always go through > ->lookup() where the correct sd is looked up considering the current tag. > > Tagging and adding new entries could be done rather cleanly but shooting > down existing dentries on rename/move turned out to be a mess. Things > will be much simpler if no sysfs dentry is hashed on dcache and always > go through ->lookup() but that will hurt big machines. > > The basic problem here is that dcache layer doesn't allow different > views and sysfs shadow is trying to work behind its back. I don't think > this is a viable approach. Both implementations bend too many rules and > are too fragile. It will be a genuine pain in the ass to maintain. > > Sorry that I can't come up with an alternative but NACK. Imho then OpenOVZ approach with multiple sysfs trees is better. it allows to use cached dentries with moultiple sysfs mounts each having different view. It also allows to hide hw-related entries and events from the containers and has quite little modifications in the code. Thanks, Kirill _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: dev
date: 2007-07-30T12:41:35-00:00

Re: [PATCH 2/4] sysfs: Implement sysfs manged shadow directory support.
type: item
description: Hello, Kirill. Kirill Korotaev wrote: > Imho then OpenOVZ approach with multiple sysfs trees is better. > it allows to use cached dentries with moultiple sysfs mounts > each having different view. > It also allows to hide hw-related entries and events from the containers > and has quite little modifications in the code. I thought something like supermount plus some twists or fuse based sysfs proxy would fit better. Dunno whether or how uevent and polling stuff can work that way tho. Note that sysfs no longer keeps dentries and inodes pinned. It might make the shared dentry stuff harder. Thanks. -- tejun _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Tejun Heo
date: 2007-07-30T13:06:22-00:00

Re: [PATCH 2/4] sysfs: Implement sysfs manged shadow directory support.
type: item
description: Tejun Heo <htejun@gmail.com> writes: > Hello, > > Okay, some questions. > > * What do you think about not allowing duplicate names across different > tags? ie. there's only one ethX anywhere but it's visible only in a > specific namespace (and maybe in the default global one). Or does > everyone need its own eth0. If this is acceptable, the problem becomes > _much_ simpler. I agree, and unfortunately this is the problem I am really trying to solve. Everyone namespace has it's own loopback interface. > * I think we can do away with the magic tag and use a pointer to > vfsmount instead. So, a process which wants to be in certain namespace > can bind-mount /sysfs to its own /sysfs and make needed sysfs nodes > bound to the mount. Does this sound okay? Such process should probably > be in its own chrooted environment to function properly. That would actually be preferable. > * I haven't really followed the containers thread. Do people generally > agree on including it in mainline when we have all the fancy > virtualization stuff? Generally. Assuming all of the i's are dotted and all of the t's crossed. Eric _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: ebiederm
date: 2007-07-30T15:36:48-00:00