kernel.git/fs/configfs, branch linux-2.6.25.y

Introduce path_put()

2008-02-15T05:13:33Z

* Add path_put() functions for releasing a reference to the dentry and vfsmount of a struct path in the right order * Switch from path_release(nd) to path_put(&nd->path) * Rename dput_path() to path_put_conditional() [akpm@linux-foundation.org: fix cifs] Signed-off-by: Jan Blunck Signed-off-by: Andreas Gruenbacher Acked-by: Christoph Hellwig Cc: Cc: Al Viro Cc: Steven French Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Embed a struct path into struct nameidata instead of nd->{dentry,mnt}

2008-02-15T05:13:33Z

This is the central patch of a cleanup series. In most cases there is no good reason why someone would want to use a dentry for itself. This series reflects that fact and embeds a struct path into nameidata. Together with the other patches of this series - it enforced the correct order of getting/releasing the reference count on pairs - it prepares the VFS for stacking support since it is essential to have a struct path in every place where the stack can be traversed - it reduces the overall code size: without patch series: text data bss dec hex filename 5321639 858418 715768 6895825 6938d1 vmlinux with patch series: text data bss dec hex filename 5320026 858418 715768 6894212 693284 vmlinux This patch: Switch from nd->{dentry,mnt} to nd->path.{dentry,mnt} everywhere. [akpm@linux-foundation.org: coding-style fixes] [akpm@linux-foundation.org: fix cifs] [akpm@linux-foundation.org: fix smack] Signed-off-by: Jan Blunck Signed-off-by: Andreas Gruenbacher Acked-by: Christoph Hellwig Cc: Al Viro Cc: Casey Schaufler Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

configfs: file.c fix possible recursive locking

2008-01-25T23:05:47Z

configfs_register_subsystem() with default_groups triggers recursive locking. it seems that mutex_lock_nested is needed. ============================================= [ INFO: possible recursive locking detected ] 2.6.24-rc6 #145 --------------------------------------------- swapper/1 is trying to acquire lock: (&sb->s_type->i_mutex_key#3){--..}, at: [] configfs_add_file+0x2e/0x70 but task is already holding lock: (&sb->s_type->i_mutex_key#3){--..}, at: [] configfs_register_subsystem+0x55/0x130 other info that might help us debug this: 1 lock held by swapper/1: #0: (&sb->s_type->i_mutex_key#3){--..}, at: [] configfs_register_subsystem+0x55/0x130 stack backtrace: Pid: 1, comm: swapper Not tainted 2.6.24-rc6 #145 [] show_trace_log_lvl+0x1a/0x30 [] show_trace+0x12/0x20 [] dump_stack+0x6e/0x80 [] __lock_acquire+0xe62/0x1120 [] lock_acquire+0x82/0xa0 [] mutex_lock_nested+0x98/0x2e0 [] configfs_add_file+0x2e/0x70 [] configfs_create_file+0x2c/0x40 [] configfs_attach_item+0x139/0x220 [] configfs_attach_group+0x14/0x140 [] configfs_attach_group+0xc9/0x140 [] configfs_register_subsystem+0xc6/0x130 [] init_netconsole+0x2b6/0x300 [] kernel_init+0x142/0x320 [] kernel_thread_helper+0x7/0x14 ======================= Signed-off-by: Joonwoo Park Signed-off-by: Joel Becker Signed-off-by: Mark Fasheh

configfs: dir.c fix possible recursive locking

2008-01-25T23:05:47Z

configfs_register_subsystem() with default_groups triggers recursive locking. it seems that mutex_lock_nested is needed. ============================================= [ INFO: possible recursive locking detected ] 2.6.24-rc6 #141 --------------------------------------------- swapper/1 is trying to acquire lock: (&sb->s_type->i_mutex_key#3){--..}, at: [] configfs_attach_group+0x4f/0x190 but task is already holding lock: (&sb->s_type->i_mutex_key#3){--..}, at: [] configfs_register_subsystem+0x55/0x130 other info that might help us debug this: 1 lock held by swapper/1: #0: (&sb->s_type->i_mutex_key#3){--..}, at: [] configfs_register_subsystem+0x55/0x130 stack backtrace: Pid: 1, comm: swapper Not tainted 2.6.24-rc6 #141 [] show_trace_log_lvl+0x1a/0x30 [] show_trace+0x12/0x20 [] dump_stack+0x6e/0x80 [] __lock_acquire+0xe62/0x1120 [] lock_acquire+0x82/0xa0 [] mutex_lock_nested+0x98/0x2e0 [] configfs_attach_group+0x4f/0x190 [] configfs_register_subsystem+0xc6/0x130 [] init_netconsole+0x2b6/0x300 [] kernel_init+0x142/0x320 [] kernel_thread_helper+0x7/0x14 ======================= Signed-off-by: Joonwoo Park Signed-off-by: Joel Becker Signed-off-by: Mark Fasheh

Kobject: convert fs/* from kobject_unregister() to kobject_put()

2008-01-25T04:40:40Z

There is no need for kobject_unregister() anymore, thanks to Kay's kobject cleanup changes, so replace all instances of it with kobject_put(). Cc: Kay Sievers Signed-off-by: Greg Kroah-Hartman

kobject: convert kernel_kset to be a kobject

2008-01-25T04:40:24Z

kernel_kset does not need to be a kset, but a much simpler kobject now that we have kobj_attributes. We also rename kernel_kset to kernel_kobj to catch all users of this symbol with a build error instead of an easy-to-ignore build warning. Cc: Kay Sievers Signed-off-by: Greg Kroah-Hartman

kset: convert kernel_subsys to use kset_create

2008-01-25T04:40:14Z

Dynamically create the kset instead of declaring it statically. We also rename kernel_subsys to kernel_kset to catch all users of this symbol with a build error instead of an easy-to-ignore build warning. Cc: Kay Sievers Signed-off-by: Greg Kroah-Hartman

kobject: convert configfs to use kobject_create

2008-01-25T04:40:11Z

We don't need a kset here, a simple kobject will do just fine, so dynamically create the kobject and use it. Cc: Kay Sievers Signed-off-by: Joel Becker Signed-off-by: Greg Kroah-Hartman

kobject: remove struct kobj_type from struct kset

2008-01-25T04:40:10Z

We don't need a "default" ktype for a kset. We should set this explicitly every time for each kset. This change is needed so that we can make ksets dynamic, and cleans up one of the odd, undocumented assumption that the kset/kobject/ktype model has. This patch is based on a lot of help from Kay Sievers. Nasty bug in the block code was found by Dave Young Cc: Kay Sievers Cc: Dave Young Signed-off-by: Greg Kroah-Hartman

r/o bind mounts: filesystem helpers for custom 'struct file's

2007-10-17T15:43:04Z

Why do we need r/o bind mounts? This feature allows a read-only view into a read-write filesystem. In the process of doing that, it also provides infrastructure for keeping track of the number of writers to any given mount. This has a number of uses. It allows chroots to have parts of filesystems writable. It will be useful for containers in the future because users may have root inside a container, but should not be allowed to write to somefilesystems. This also replaces patches that vserver has had out of the tree for several years. It allows security enhancement by making sure that parts of your filesystem read-only (such as when you don't trust your FTP server), when you don't want to have entire new filesystems mounted, or when you want atime selectively updated. I've been using the following script to test that the feature is working as desired. It takes a directory and makes a regular bind and a r/o bind mount of it. It then performs some normal filesystem operations on the three directories, including ones that are expected to fail, like creating a file on the r/o mount. This patch: Some filesystems forego the vfs and may_open() and create their own 'struct file's. This patch creates a couple of helper functions which can be used by these filesystems, and will provide a unified place which the r/o bind mount code may patch. Also, rename an existing, static-scope init_file() to a less generic name. Signed-off-by: Dave Hansen Cc: Christoph Hellwig Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds