linux/fs/sysfs, branch v2.6.28.1

[PATCH] fix ->llseek for more directories

2008-10-23T09:13:21Z

With this patch all directory fops instances that have a readdir that doesn't take the BKL are switched to generic_file_llseek. Signed-off-by: Christoph Hellwig

kobject: Cleanup kobject_rename and !CONFIG_SYSFS

2008-10-16T16:24:52Z

It finally dawned on me what the clean fix to sysfs_rename_dir calling kobject_set_name is. Move the work into kobject_rename where it belongs. The callers serialize us anyway so this is safe. Signed-off-by: Eric W. Biederman Acked-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman

sysfs: Make dir and name args to sysfs_notify() const

2008-10-16T16:24:51Z

Because they can be, and because code like this produces a warning if they're not: struct device_attribute dev_attr; sysfs_notify(&kobj, NULL, dev_attr.attr.name); Signed-off-by: Trent Piepho CC: Neil Brown Signed-off-by: Greg Kroah-Hartman

sysfs: use ilookup5() instead of ilookup5_nowait()

2008-10-16T16:24:51Z

As inode creation is protected by sysfs_mutex, ilookup5_nowait() always either fails to find at all or finds one which is fully initialized, so using ilookup5_nowait() or ilookup5() doesn't make any difference. Switch to ilookup5() as it's planned to be removed. This change also makes lookup return value handling a bit simpler. This change was suggested by Al Viro. Signed-off-by: Tejun Heo Cc: Al Viro Signed-off-by: Greg Kroah-Hartman

sysfs: fix deadlock

2008-10-16T16:24:50Z

On Thu, Sep 11, 2008 at 10:27:10AM +0200, Ingo Molnar wrote: > and it's working fine on most boxes. One testbox found this new locking > scenario: > > PM: Adding info for No Bus:vcsa7 > EDAC DEBUG: MC0: i82860_check() > > ======================================================= > [ INFO: possible circular locking dependency detected ] > 2.6.27-rc6-tip #1 > ------------------------------------------------------- > X/4873 is trying to acquire lock: > (&bb->mutex){--..}, at: [] mmap+0x40/0xa0 > > but task is already holding lock: > (&mm->mmap_sem){----}, at: [] sys_mmap2+0x8e/0xc0 > > which lock already depends on the new lock. > > > the existing dependency chain (in reverse order) is: > > -> #1 (&mm->mmap_sem){----}: > [] validate_chain+0xa96/0xf50 > [] __lock_acquire+0x2cb/0x5b0 > [] lock_acquire+0x89/0xc0 > [] might_fault+0x6b/0x90 > [] copy_to_user+0x38/0x60 > [] read+0xfb/0x170 > [] vfs_read+0x95/0x110 > [] sys_pread64+0x63/0x80 > [] sysenter_do_call+0x12/0x43 > [] 0xffffffff > > -> #0 (&bb->mutex){--..}: > [] validate_chain+0x6b7/0xf50 > [] __lock_acquire+0x2cb/0x5b0 > [] lock_acquire+0x89/0xc0 > [] __mutex_lock_common+0xab/0x3c0 > [] mutex_lock_nested+0x38/0x50 > [] mmap+0x40/0xa0 > [] mmap_region+0x14e/0x450 > [] do_mmap_pgoff+0x2ef/0x310 > [] sys_mmap2+0xad/0xc0 > [] sysenter_do_call+0x12/0x43 > [] 0xffffffff > > other info that might help us debug this: > > 1 lock held by X/4873: > #0: (&mm->mmap_sem){----}, at: [] sys_mmap2+0x8e/0xc0 > > stack backtrace: > Pid: 4873, comm: X Not tainted 2.6.27-rc6-tip #1 > [] print_circular_bug_tail+0x79/0xc0 > [] validate_chain+0x6b7/0xf50 > [] ? trace_hardirqs_off_caller+0x15/0xb0 > [] __lock_acquire+0x2cb/0x5b0 > [] lock_acquire+0x89/0xc0 > [] ? mmap+0x40/0xa0 > [] __mutex_lock_common+0xab/0x3c0 > [] ? mmap+0x40/0xa0 > [] mutex_lock_nested+0x38/0x50 > [] ? mmap+0x40/0xa0 > [] mmap+0x40/0xa0 > [] mmap_region+0x14e/0x450 > [] ? arch_get_unmapped_area_topdown+0xf8/0x160 > [] do_mmap_pgoff+0x2ef/0x310 > [] sys_mmap2+0xad/0xc0 > [] sysenter_do_call+0x12/0x43 > [] ? __switch_to+0x130/0x220 > ======================= > evbug.c: Event. Dev: input3, Type: 20, Code: 0, Value: 500 > warning: `sudo' uses deprecated v2 capabilities in a way that may be insecure. > > i've attached the config. > > at first sight it looks like a genuine bug in fs/sysfs/bin.c? Yes, it is a real bug by the looks. bin.c takes bb->mutex under mmap_sem when it is mmapped, and then does its copy_*_user under bb->mutex too. Here is a basic fix for the sysfs lor. From: Nick Piggin Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

sysfs: Support sysfs_notify from atomic context with new sysfs_notify_dirent

2008-10-16T16:24:47Z

Support sysfs_notify from atomic context with new sysfs_notify_dirent sysfs_notify currently takes sysfs_mutex. This means that it cannot be called in atomic context. sysfs_mutex is sometimes held over a malloc (sysfs_rename_dir) so it can block on low memory. In md I want to be able to notify on a sysfs attribute from atomic context, and I don't want to block on low memory because I could be in the writeout path for freeing memory. So: - export the "sysfs_dirent" structure along with sysfs_get, sysfs_put and sysfs_get_dirent so I can get the sysfs_dirent that I want to notify on and hold it in an md structure. - split sysfs_notify_dirent out of sysfs_notify so the sysfs_dirent can be notified on with no blocking (just a spinlock). Signed-off-by: Neil Brown Acked-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman

sysfs: crash debugging

2008-10-16T16:24:41Z

Print the name of the last-accessed sysfs file when we oops, to help track down oopses which occur in sysfs store/read handlers. Because these oopses tend to not leave any trace of the offending code in the stack traces. Cc: Kay Sievers Cc: Mathieu Desnoyers Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

Use WARN() in fs/sysfs

2008-07-26T19:00:07Z

Use WARN() instead of a printk+WARN_ON() pair; this way the message becomes part of the warning section for better reporting/collection. Also, with this, one fo the if() sections collapses entirely into the WARN(). Signed-off-by: Arjan van de Ven Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

driver core: Suppress sysfs warnings for device_rename().

2008-07-22T04:55:01Z

driver core: Suppress sysfs warnings for device_rename(). Renaming network devices to an already existing name is not something we want sysfs to print a scary warning for, since the callers can deal with this correctly. So let's introduce sysfs_create_link_nowarn() which gets rid of the common warning. Signed-off-by: Cornelia Huck Signed-off-by: Greg Kroah-Hartman

sysfs: don't call notify_change

2008-07-22T04:54:57Z

sysfs_chmod_file() calls notify_change() to change the permission bits on a sysfs file. Replace with explicit call to sysfs_setattr() and fsnotify_change(). This is equivalent, except that security_inode_setattr() is not called. This function is called by drivers, so the security checks do not make any sense. Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman