11 Sep, 2009
1 commit
-
This enables us to track who does what and print info. Its main use
is catching dirty inodes on the default_backing_dev_info, so we can
fix that up.Signed-off-by: Jens Axboe
01 May, 2009
2 commits
-
configfs_depend_item() recursively locks all inodes mutex from configfs root to
the target item, which makes lockdep unhappy. The purpose of this recursive
locking is to ensure that the item tree can be safely parsed and that the target
item, if found, is not about to leave.This patch reworks configfs_depend_item() locking using configfs_dirent_lock.
Since configfs_dirent_lock protects all changes to the configfs_dirent tree, and
protects tagging of items to be removed, this lock can be used instead of the
inodes mutex lock chain.
This needs that the check for dependents be done atomically with
CONFIGFS_USET_DROPPING tagging.Now lockdep looks happy with configfs.
[ Lifted the setting of s_type into configfs_new_dirent() to satisfy the
atomic setting of CONFIGFS_USET_CREATING -- Joel ]Signed-off-by: Louis Rilling
Signed-off-by: Joel Becker -
When attaching default groups (subdirs) of a new group (in mkdir() or
in configfs_register()), configfs recursively takes inode's mutexes
along the path from the parent of the new group to the default
subdirs. This is needed to ensure that the VFS will not race with
operations on these sub-dirs. This is safe for the following reasons:- the VFS allows one to lock first an inode and second one of its
children (The lock subclasses for this pattern are respectively
I_MUTEX_PARENT and I_MUTEX_CHILD);
- from this rule any inode path can be recursively locked in
descending order as long as it stays under a single mountpoint and
does not follow symlinks.Unfortunately lockdep does not know (yet?) how to handle such
recursion.I've tried to use Peter Zijlstra's lock_set_subclass() helper to
upgrade i_mutexes from I_MUTEX_CHILD to I_MUTEX_PARENT when we know
that we might recursively lock some of their descendant, but this
usage does not seem to fit the purpose of lock_set_subclass() because
it leads to several i_mutex locked with subclass I_MUTEX_PARENT by
the same task.>From inside configfs it is not possible to serialize those recursive
locking with a top-level one, because mkdir() and rmdir() are already
called with inodes locked by the VFS. So using some
mutex_lock_nest_lock() is not an option.I am proposing two solutions:
1) one that wraps recursive mutex_lock()s with
lockdep_off()/lockdep_on().
2) (as suggested earlier by Peter Zijlstra) one that puts the
i_mutexes recursively locked in different classes based on their
depth from the top-level config_group created. This
induces an arbitrary limit (MAX_LOCK_DEPTH - 2 == 46) on the
nesting of configfs default groups whenever lockdep is activated
but this limit looks reasonably high. Unfortunately, this also
isolates VFS operations on configfs default groups from the others
and thus lowers the chances to detect locking issues.Nobody likes solution 1), which I can understand.
This patch implements solution 2). However lockdep is still not happy with
configfs_depend_item(). Next patch reworks the locking of
configfs_depend_item() and finally makes lockdep happy.[ Note: This hides a few locking interactions with the VFS from lockdep.
That was my big concern, because we like lockdep's protection. However,
the current state always dumps a spurious warning. The locking is
correct, so I tell people to ignore the warning and that we'll keep
our eyes on the locking to make sure it stays correct. With this patch,
we eliminate the warning. We do lose some of the lockdep protections,
but this only means that we still have to keep our eyes on the locking.
We're going to do that anyway. -- Joel ]Signed-off-by: Louis Rilling
Signed-off-by: Joel Becker
22 Apr, 2009
1 commit
-
I observed the following build warning with fs/configfs/symlink.c:
fs/configfs/symlink.c: In function 'configfs_symlink':
fs/configfs/symlink.c:138: warning: 'target_item' may be used uninitialized in this functionHere is a small fix for this.
Cc: Patrick Mochel
Cc: Balbir Singh
Cc: Sachin P Sant
Signed-Off-By: Subrata Modak
Signed-off-by: Joel Becker
28 Mar, 2009
1 commit
-
Signed-off-by: Al Viro
05 Feb, 2009
1 commit
-
This reverts commit 0e0333429a6280e6eb3c98845e4eed90d5f8078a.
I committed this by accident - Joel and Louis are working with the lockdep
maintainer to provide a better solution than just turning lockdep off.Signed-off-by: Mark Fasheh
Acked-by:
03 Feb, 2009
1 commit
-
When attaching default groups (subdirs) of a new group (in mkdir() or
in configfs_register()), configfs recursively takes inode's mutexes
along the path from the parent of the new group to the default
subdirs. This is needed to ensure that the VFS will not race with
operations on these sub-dirs. This is safe for the following reasons:- the VFS allows one to lock first an inode and second one of its
children (The lock subclasses for this pattern are respectively
I_MUTEX_PARENT and I_MUTEX_CHILD);
- from this rule any inode path can be recursively locked in
descending order as long as it stays under a single mountpoint and
does not follow symlinks.Unfortunately lockdep does not know (yet?) how to handle such
recursion.I've tried to use Peter Zijlstra's lock_set_subclass() helper to
upgrade i_mutexes from I_MUTEX_CHILD to I_MUTEX_PARENT when we know
that we might recursively lock some of their descendant, but this
usage does not seem to fit the purpose of lock_set_subclass() because
it leads to several i_mutex locked with subclass I_MUTEX_PARENT by
the same task.>From inside configfs it is not possible to serialize those recursive
locking with a top-level one, because mkdir() and rmdir() are already
called with inodes locked by the VFS. So using some
mutex_lock_nest_lock() is not an option.I am proposing two solutions:
1) one that wraps recursive mutex_lock()s with
lockdep_off()/lockdep_on().
2) (as suggested earlier by Peter Zijlstra) one that puts the
i_mutexes recursively locked in different classes based on their
depth from the top-level config_group created. This
induces an arbitrary limit (MAX_LOCK_DEPTH - 2 == 46) on the
nesting of configfs default groups whenever lockdep is activated
but this limit looks reasonably high. Unfortunately, this alos
isolates VFS operations on configfs default groups from the others
and thus lowers the chances to detect locking issues.This patch implements solution 1).
Solution 2) looks better from lockdep's point of view, but fails with
configfs_depend_item(). This needs to rework the locking
scheme of configfs_depend_item() by removing the variable lock recursion
depth, and I think that it's doable thanks to the configfs_dirent_lock.
For now, let's stick to solution 1).Signed-off-by: Louis Rilling
Acked-by: Joel Becker
Signed-off-by: Mark Fasheh
22 Jan, 2009
1 commit
-
Signed-off-by: Alexey Dobriyan
06 Jan, 2009
1 commit
-
... and don't bother in callers. Don't bother with zeroing i_blocks,
while we are at it - it's already been zeroed.i_mode is not worth the effort; it has no common default value.
Signed-off-by: Al Viro
23 Oct, 2008
1 commit
-
more nameidata eviction
Signed-off-by: Al Viro
23 Aug, 2008
1 commit
-
It appears that configfs_rmdir() can protect configfs_detach_prep() retries with
less calls to {spin,mutex}_{lock,unlock}, and a cleaner code.This patch does not change any behavior, except that it removes two useless
lock/unlock pairs having nothing inside to protect and providing a useless
barrier.Signed-off-by: Louis Rilling
Signed-off-by: Joel Becker
Signed-off-by: Mark Fasheh
01 Aug, 2008
7 commits
-
configfs_mkdir() creates a new item by calling its parent's
->make_item/group() functions. Once that object is created,
configfs_mkdir() calls try_module_get() on the new item's module. If it
succeeds, the module owning the new item cannot be unloaded, and
configfs is safe to reference the item.If the item and the subsystem it belongs to are part of the same module,
the subsystem is also pinned. This is the common case.However, if the subsystem is made up of multiple modules, this may not
pin the subsystem. Thus, it would be possible to unload the toplevel
subsystem module while there is still a child item. Thus, we now
try_module_get() the subsystem's module. This only really affects
children of the toplevel subsystem group. Deeper children already have
their parents pinned.Signed-off-by: Joel Becker
Signed-off-by: Mark Fasheh -
When checking for user-created elements under an item to be removed by rmdir(),
configfs_detach_prep() counts fake configfs_dirents created by dir_open() as
user-created and fails when finding one. It is however perfectly valid to remove
a directory that is open.Simply make configfs_detach_prep() skip fake configfs_dirent, like it already
does for attributes, and like detach_groups() does.Signed-off-by: Louis Rilling
Signed-off-by: Joel Becker
Signed-off-by: Mark Fasheh -
Once a new configfs directory is created by configfs_attach_item() or
configfs_attach_group(), a failure in the remaining initialization steps leads
to removing a directory which inode the VFS may have already accessed.This commit adds the necessary inode locking to safely remove configfs
directories while cleaning up after a failure. As an advantage, the locking
rules of populate_groups() and detach_groups() become the same: the caller must
have the group's inode mutex locked.Signed-off-by: Louis Rilling
Signed-off-by: Joel Becker
Signed-off-by: Mark Fasheh -
process 1: process 2:
configfs_mkdir("A")
attach_group("A")
attach_item("A")
d_instantiate("A")
populate_groups("A")
mutex_lock("A")
attach_group("A/B")
attach_item("A")
d_instantiate("A/B")
mkdir("A/B/C")
do_path_lookup("A/B/C", LOOKUP_PARENT)
ok
lookup_create("A/B/C")
mutex_lock("A/B")
ok
configfs_mkdir("A/B/C")
ok
attach_group("A/C")
attach_item("A/C")
d_instantiate("A/C")
populate_groups("A/C")
mutex_lock("A/C")
attach_group("A/C/D")
attach_item("A/C/D")
failure
mutex_unlock("A/C")
detach_groups("A/C")
nothing to do
mkdir("A/C/E")
do_path_lookup("A/C/E", LOOKUP_PARENT)
ok
lookup_create("A/C/E")
mutex_lock("A/C")
ok
configfs_mkdir("A/C/E")
ok
detach_item("A/C")
d_delete("A/C")
mutex_unlock("A")
detach_groups("A")
mutex_lock("A/B")
detach_group("A/B")
detach_groups("A/B")
nothing since no _default_ group
detach_item("A/B")
mutex_unlock("A/B")
d_delete("A/B")
detach_item("A")
d_delete("A")Two bugs:
1/ "A/B/C" and "A/C/E" are created, but never removed while their parent are
removed in the end. The same could happen with symlink() instead of mkdir().2/ "A" and "A/C" inodes are not locked while detach_item() is called on them,
which may probably confuse VFS.This commit fixes 1/, tagging new directories with CONFIGFS_USET_CREATING before
building the inode and instantiating the dentry, and validating the whole
group+default groups hierarchy in a second pass by clearing
CONFIGFS_USET_CREATING.
mkdir(), symlink(), lookup(), and dir_open() simply return -ENOENT if
called in (or linking to) a directory tagged with CONFIGFS_USET_CREATING. This
does not prevent userspace from calling stat() successfuly on such directories,
but this prevents userspace from adding (children to | symlinking from/to |
read/write attributes of | listing the contents of) not validated items. In
other words, userspace will not interact with the subsystem on a new item until
the new item creation completes correctly.
It was first proposed to re-use CONFIGFS_USET_IN_MKDIR instead of a new
flag CONFIGFS_USET_CREATING, but this generated conflicts when checking the
target of a new symlink: a valid target directory in the middle of attaching
a new user-created child item could be wrongly detected as being attached.2/ is fixed by next commit.
Signed-off-by: Louis Rilling
Signed-off-by: Joel Becker
Signed-off-by: Mark Fasheh -
On a similar pattern as mkdir() vs rmdir(), a failing symlink() may make rmdir()
fail for the symlink's parent and the symlink's target as well.failing symlink() making target's rmdir() fail:
process 1: process 2:
symlink("A/S" -> "B")
allow_link()
create_link()
attach to "B" links list
rmdir("B")
detach_prep("B")
error because of new link
configfs_create_link("A", "S")
error (eg -ENOMEM)failing symlink() making parent's rmdir() fail:
process 1: process 2:
symlink("A/D/S" -> "B")
allow_link()
create_link()
attach to "B" links list
configfs_create_link("A/D", "S")
make_dirent("A/D", "S")
rmdir("A")
detach_prep("A")
detach_prep("A/D")
error because of "S"
create("S")
error (eg -ENOMEM)We cannot use the same solution as for mkdir() vs rmdir(), since rmdir() on the
target cannot wait on the i_mutex of the new symlink's parent without risking a
deadlock (with other symlink() or sys_rename()). Instead we define a global
mutex protecting all configfs symlinks attachment, so that rmdir() can avoid the
races above.Signed-off-by: Louis Rilling
Signed-off-by: Joel Becker
Signed-off-by: Mark Fasheh -
The rule for configfs symlinks is that symlinks always point to valid
config_items, and prevent the target from being removed. However,
configfs_symlink() only checks that it can grab a reference on the target item,
without ensuring that it remains alive until the symlink is correctly attached.This patch makes configfs_symlink() fail whenever the target is being removed,
using the CONFIGFS_USET_DROPPING flag set by configfs_detach_prep() and
protected by configfs_dirent_lock.This patch introduces a similar (weird?) behavior as with mkdir failures making
rmdir fail: if symlink() races with rmdir() of the parent directory (or its
youngest user-created ancestor if parent is a default group) or rmdir() of the
target directory, and then fails in configfs_create(), this can make the racing
rmdir() fail despite the concerned directory having no user-created entry (resp.
no symlink pointing to it or one of its default groups) in the end.
This behavior is fixed in later patches.Signed-off-by: Louis Rilling
Signed-off-by: Joel Becker
Signed-off-by: Mark Fasheh -
We now use PTR_ERR() in the ->make_item() and ->make_group() operations.
Folks including configfs.h need err.h.Signed-off-by: Joel Becker
Signed-off-by: Mark Fasheh
18 Jul, 2008
2 commits
-
The configfs operations ->make_item() and ->make_group() currently
return a new item/group. A return of NULL signifies an error. Because
of this, -ENOMEM is the only return code bubbled up the stack.Multiple folks have requested the ability to return specific error codes
when these operations fail. This patch adds that ability by changing the
->make_item/group() ops to return ERR_PTR() values. These errors are
bubbled up appropriately. NULL returns are changed to -ENOMEM for
compatibility.Also updated are the in-kernel users of configfs.
This is a rework of reverted commit 11c3b79218390a139f2d474ee1e983a672d5839a.
Signed-off-by: Joel Becker
-
This reverts commit 11c3b79218390a139f2d474ee1e983a672d5839a. The code
will move to PTR_ERR().Signed-off-by: Joel Becker
15 Jul, 2008
7 commits
-
When allow_link() succeeds but create_link() fails, the subsystem is not
informed of the failure.This patch fixes this by calling drop_link() on create_link() failures.
Signed-off-by: Louis Rilling
Signed-off-by: Joel Becker -
The configfs operations ->make_item() and ->make_group() currently
return a new item/group. A return of NULL signifies an error. Because
of this, -ENOMEM is the only return code bubbled up the stack.Multiple folks have requested the ability to return specific error codes
when these operations fail. This patch adds that ability by changing the
->make_item/group() ops to return an int.Also updated are the in-kernel users of configfs.
Signed-off-by: Joel Becker
-
When fixing the rename() vs rmdir() deadlock, we stopped locking default groups'
inodes in configfs_detach_prep(), letting racing mkdir() in default groups
proceed concurrently. This enables races like below happen, which leads to a
failing mkdir() making rmdir() fail, despite the group to remove having no
user-created directory under it in the end.process A: process B:
/* PWD=A/B */
mkdir("C")
make_item("C")
attach_group("C")
rmdir("A")
detach_prep("A")
detach_prep("B")
error because of "C"
return -ENOTEMPTY
attach_group("C/D")
error (eg -ENOMEM)
return -ENOMEMThis patch prevents such scenarii by making rmdir() wait as long as
detach_prep() fails because a racing mkdir() is in the middle of attach_group().
To achieve this, mkdir() sets a flag CONFIGFS_USET_IN_MKDIR in parent's
configfs_dirent before calling attach_group(), and clears the flag once
attach_group() is done. detach_prep() fails with -EAGAIN whenever the flag is
hit and returns the guilty inode's mutex so that rmdir() can wait on it.Signed-off-by: Louis Rilling
Signed-off-by: Joel Becker -
This patch fixes the deadlock between racing sys_rename() and configfs_rmdir().
The idea is to avoid locking i_mutexes of default groups in
configfs_detach_prep(), and rely instead on the new configfs_dirent_lock to
protect against configfs_dirent's linkage mutations. To ensure that an mkdir()
racing with rmdir() will not create new items in a to-be-removed default group,
we make configfs_new_dirent() check for the CONFIGFS_USET_DROPPING flag right
before linking the new dirent, and return error if the flag is set. This makes
racing mkdir()/symlink()/dir_open() fail in places where errors could already
happen, resp. in (attach_item()|attach_group())/create_link()/new_dirent().configfs_depend() remains safe since it locks all the path from configfs root,
and is thus mutually exclusive with rmdir().An advantage of this is that now detach_groups() unconditionnaly takes the
default groups i_mutex, which makes it more consistent with populate_groups().Signed-off-by: Louis Rilling
Signed-off-by: Joel Becker -
This patch makes configfs_new_dirent return negative error code instead of NULL,
which will be useful in the next patch to differentiate ENOMEM from ENOENT.Signed-off-by: Louis Rilling
Signed-off-by: Joel Becker -
Symlinks to a config_item are listed under its configfs_dirent s_links, but the
list mutations are not protected by any common lock.This patch uses the configfs_dirent_lock spinlock to add the necessary
protection.Note: we should also protect the list_empty() test in configfs_detach_prep() but
1/ the lock should not be released immediately because nothing would prevent the
list from being filled after a successful list_empty() test, making the problem
tricky,
2/ this will be solved by the rmdir() vs rename() deadlock bugfix.Signed-off-by: Louis Rilling
Signed-off-by: Joel Becker -
This patch introduces configfs_dirent_lock spinlock to protect configfs_dirent
traversals against linkage mutations (add/del/move). This will allow
configfs_detach_prep() to avoid locking i_mutexes.Locking rules for configfs_dirent linkage mutations are the same plus the
requirement of taking configfs_dirent_lock. For configfs_dirent walking, one can
either take appropriate i_mutex as before, or take configfs_dirent_lock.The spinlock could actually be a mutex, but the critical sections are either
O(1) or should not be too long (default groups walking in last patch).ChangeLog:
- Clarify the comment on configfs_dirent_lock usage
- Move sd->s_element init before linking the new dirent
- In lseek(), do not release configfs_dirent_lock before the dirent is
relinked.Signed-off-by: Louis Rilling
Signed-off-by: Joel Becker
30 Apr, 2008
2 commits
-
__FUNCTION__ is gcc-specific, use __func__
Signed-off-by: Harvey Harrison
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Add a new BDI capability flag: BDI_CAP_NO_ACCT_WB. If this flag is
set, then don't update the per-bdi writeback stats from
test_set_page_writeback() and test_clear_page_writeback().Misc cleanups:
- convert bdi_cap_writeback_dirty() and friends to static inline functions
- create a flag that includes all three dirty/writeback related flags,
since almst all users will want to have them toghetherSigned-off-by: Miklos Szeredi
Cc: Peter Zijlstra
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
15 Feb, 2008
2 commits
-
* 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 -
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 vmlinuxwith patch series:
text data bss dec hex filename
5320026 858418 715768 6894212 693284 vmlinuxThis 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
26 Jan, 2008
2 commits
-
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/0x70but task is already holding lock:
(&sb->s_type->i_mutex_key#3){--..}, at: [] configfs_register_subsystem+0x55/0x130other 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/0x130stack 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_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/0x190but task is already holding lock:
(&sb->s_type->i_mutex_key#3){--..}, at: [] configfs_register_subsystem+0x55/0x130other 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/0x130stack 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
25 Jan, 2008
5 commits
-
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 -
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 -
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 -
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 -
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
17 Oct, 2007
2 commits
-
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 -
provide BDI constructor/destructor hooks
[akpm@linux-foundation.org: compile fix]
Signed-off-by: Peter Zijlstra
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
