linux-toradex.git/fs/debugfs/inode.c, branch v2.6.33.5

get rid of pointless checks after simple_pin_fs()

2010-01-27T03:22:26+00:00

if we'd just got success from it, vfsmount won't be NULL

Signed-off-by: Al Viro

debugfs: fix create mutex racy fops and private data

2009-12-11T19:24:53+00:00

Setting fops and private data outside of the mutex at debugfs file
creation introduces a race where the files can be opened with the wrong
file operations and private data.  It is easy to trigger with a process
waiting on file creation notification.

Signed-off-by: Mathieu Desnoyers 
Signed-off-by: Andrew Morton 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

fs/debugfs/inode.c: fix comment typos

2009-12-04T14:39:52+00:00

Signed-off-by: Alberto Bertogli 
Signed-off-by: Jiri Kosina

debugfs: dont stop on first failed recursive delete

2009-06-16T04:30:24+00:00

debugfs: dont stop on first failed recursive delete

While running a while loop of removing a module that removes a debugfs
directory with debugfs_remove_recursive, and at the same time doing a
while loop of cat of a file in that directory, I would hit a point where
somehow the cat of the file caused the remove to fail.

The result is that other files did not get removed when the module
was removed. I simple read of one of those file can oops the kernel
because the operations to the file no longer exist (removed by module).

The funny thing is that the file being cat'ed was removed. It was
the siblings that were not. I see in the code to debugfs_remove_recursive
there's a test that checks if the child fails to bail out of the loop
to prevent an infinite loop.

What this patch does is to still try any siblings in that directory.
If all the siblings fail, or there are no more siblings, then we exit
the loop.

This fixes the above symptom, but...

This is no full proof. It makes the debugfs_remove_recursive a bit more
robust, but it does not explain why the one file failed. There may
be some kind of delay deletion that makes the debugfs think it did
not succeed. So this patch is more of a fix for the symptom but not
the disease.

This patch still makes the debugfs_remove_recursive more robust and
until I can find out why the bug exists, this patch will keep
the kernel from oopsing in most cases.  Even after the cause is found
I think this change can stand on its own and should be kept.

[ Impact: prevent kernel oops on module unload and reading debugfs files ]

Signed-off-by: Steven Rostedt 
Signed-off-by: Greg Kroah-Hartman

debugfs: function to know if debugfs is initialized

2009-03-23T15:25:46+00:00

Impact: add new debugfs API

With ftrace, some tracers are registered in early initcalls
and attempt to create files on the debugfs filesystem.
Depending on when they are activated, they can try to create their
file at any time. Some checks can be done on the tracing area
but providing a helper to know if debugfs is registered make it
really more easy.

Signed-off-by: Frederic Weisbecker 
Acked-by: Greg Kroah-Hartman 
Cc: Steven Rostedt 
LKML-Reference: <1237759847-21025-2-git-send-email-fweisbec@gmail.com>
Signed-off-by: Ingo Molnar

zero i_uid/i_gid on inode allocation

2009-01-05T16:54:28+00:00

... 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

integrity: special fs magic

2008-10-12T22:47:43+00:00

Discussion on the mailing list questioned the use of these
magic values in userspace, concluding these values are already
exported to userspace via statfs and their correct/incorrect
usage is left up to the userspace application.

  - Move special fs magic number definitions to magic.h
  - Add magic.h include

Signed-off-by: Mimi Zohar 
Reviewed-by: James Morris 
Signed-off-by: James Morris

debugfs: Implement debugfs_remove_recursive()

2008-07-22T04:54:59+00:00

debugfs_remove_recursive() will remove a dentry and all its children.
Drivers can use this to zap their whole debugfs tree so that they don't
need to keep track of every single debugfs dentry they created.

It may fail to remove the whole tree in certain cases:

sh-3.2# rmmod atmel-mci < /sys/kernel/debug/mmc0/ios/clock
mmc0: card b368 removed
atmel_mci atmel_mci.0: Lost dma0chan1, falling back to PIO
sh-3.2# ls /sys/kernel/debug/mmc0/
ios

But I'm not sure if that case can be handled in any sane manner.

Signed-off-by: Haavard Skinnemoen 
Cc: Pierre Ossman 
Signed-off-by: Greg Kroah-Hartman

debugfs: fix sparse warnings

2008-03-04T22:47:06+00:00

extern does not belong in C files, move declaration to linux/debugfs.h
fs/debugfs/file.c:42:30: warning: symbol 'debugfs_file_operations' was not declared. Should it be static?
fs/debugfs/file.c:54:31: warning: symbol 'debugfs_link_operations' was not declared. Should it be static?

Signed-off-by: Harvey Harrison 
Signed-off-by: Greg Kroah-Hartman

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

2008-01-25T04:40:40+00:00

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