linux-toradex.git/fs/sysfs, branch v2.6.30-rc8

sysfs: file.c: use create_singlethread_workqueue()

2009-05-28T21:24:07+00:00

We don't need a kernel thread per CPU for this application.

Acked-by: Alex Chiang 
Cc: Lai Jiangshan 
Cc: Peter Zijlstra 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

sysfs: use memdup_user()

2009-04-21T03:02:50+00:00

Remove open-coded memdup_user().

Signed-off-by: Li Zefan 
Signed-off-by: Al Viro

sysfs: sysfs poll keep the poll rule of regular file.

2009-04-16T23:17:09+00:00

Currently, following test programs don't finished.

% ruby -e '
Thread.new { sleep }
File.read("/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies")
'

strace expose the reason.

...
open("/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies", O_RDONLY|O_LARGEFILE) = 3
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbf9fa6b8) = -1 ENOTTY (Inappropriate ioctl for device)
fstat64(3, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
_llseek(3, 0, [0], SEEK_CUR)            = 0
select(4, [3], NULL, NULL, NULL)        = 1 (in [3])
read(3, "1400000 1300000 1200000 1100000 1"..., 4096) = 62
select(4, [3], NULL, NULL, NULL


Because Ruby (the scripting language) VM assume select system-call
against regular file don't block.  it because SUSv3 says "Regular files
shall always poll TRUE for reading and writing".  see
http://www.opengroup.org/onlinepubs/009695399/functions/poll.html it
seems valid assumption.

But sysfs_poll() don't keep this rule although sysfs file can read and
write always.

This patch restore proper poll behavior to sysfs.
/sys/block/md*/md/sync_action polling application and another sysfs
updating sensitive application still can use POLLERR and POLLPRI.

Cc: Neil Brown 
Signed-off-by: KOSAKI Motohiro 
Signed-off-by: Greg Kroah-Hartman

sysfs: don't use global workqueue in sysfs_schedule_callback()

2009-04-16T23:17:08+00:00

A sysfs attribute using sysfs_schedule_callback() to commit suicide
may end up calling device_unregister(), which will eventually call
a driver's ->remove function.

Drivers may call flush_scheduled_work() in their shutdown routines,
in which case lockdep will complain with something like the following:

  =============================================
  [ INFO: possible recursive locking detected ]
  2.6.29-rc8-kk #1
  ---------------------------------------------
  events/4/56 is trying to acquire lock:
  (events){--..}, at: [] flush_workqueue+0x0/0xa0

  but task is already holding lock:
  (events){--..}, at: [] run_workqueue+0x108/0x230

  other info that might help us debug this:
  3 locks held by events/4/56:
  #0:  (events){--..}, at: [] run_workqueue+0x108/0x230
  #1:  (&ss->work){--..}, at: [] run_workqueue+0x108/0x230
  #2:  (pci_remove_rescan_mutex){--..}, at: [] remove_callback+0x21/0x40

  stack backtrace:
  Pid: 56, comm: events/4 Not tainted 2.6.29-rc8-kk #1
  Call Trace:
  [] validate_chain+0xb7d/0x1260
  [] __lock_acquire+0x42e/0xa40
  [] lock_acquire+0x58/0x80
  [] ? flush_workqueue+0x0/0xa0
  [] flush_workqueue+0x4d/0xa0
  [] ? flush_workqueue+0x0/0xa0
  [] flush_scheduled_work+0x10/0x20
  [] e1000_remove+0x55/0xfe [e1000e]
  [] ? sysfs_schedule_callback_work+0x0/0x50
  [] pci_device_remove+0x32/0x70
  [] __device_release_driver+0x59/0x90
  [] device_release_driver+0x2b/0x40
  [] bus_remove_device+0xa6/0x120
  [] device_del+0x12b/0x190
  [] device_unregister+0x26/0x70
  [] pci_stop_dev+0x49/0x60
  [] pci_remove_bus_device+0x40/0xc0
  [] remove_callback+0x29/0x40
  [] sysfs_schedule_callback_work+0x1f/0x50
  [] run_workqueue+0x15a/0x230
  [] ? run_workqueue+0x108/0x230
  [] worker_thread+0x9f/0x100
  [] ? autoremove_wake_function+0x0/0x40
  [] ? worker_thread+0x0/0x100
  [] kthread+0x4d/0x80
  [] child_rip+0xa/0x20
  [] ? restore_args+0x0/0x30
  [] ? kthread+0x0/0x80
  [] ? child_rip+0x0/0x20

Although we know that the device_unregister path will never acquire
a lock that a driver might try to acquire in its ->remove, in general
we should never attempt to flush a workqueue from within the same
workqueue, and lockdep rightly complains.

So as long as sysfs attributes cannot commit suicide directly and we
are stuck with this callback mechanism, put the sysfs callbacks on
their own workqueue instead of the global one.

This has the side benefit that if a suicidal sysfs attribute kicks
off a long chain of ->remove callbacks, we no longer induce a long
delay on the global queue.

This also fixes a missing module_put in the error path introduced
by sysfs-only-allow-one-scheduled-removal-callback-per-kobj.patch.

We never destroy the workqueue, but I'm not sure that's a
problem.

Reported-by: Kenji Kaneshige 
Tested-by: Kenji Kaneshige 
Signed-off-by: Alex Chiang 
Signed-off-by: Greg Kroah-Hartman

mm: page_mkwrite change prototype to match fault: fix sysfs

2009-04-01T15:59:14+00:00

Fix warnings and return values in sysfs bin_page_mkwrite(), fixing
fs/sysfs/bin.c: In function `bin_page_mkwrite':
fs/sysfs/bin.c:250: warning: passing argument 2 of `bb->vm_ops->page_mkwrite' from incompatible pointer type
fs/sysfs/bin.c: At top level:
fs/sysfs/bin.c:280: warning: initialization from incompatible pointer type

Expects to have my [PATCH next] sysfs: fix some bin_vm_ops errors

Signed-off-by: Hugh Dickins 
Cc: Nick Piggin 
Cc: "Eric W. Biederman" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6

2009-03-27T23:23:12+00:00

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6: (37 commits)
  fs: avoid I_NEW inodes
  Merge code for single and multiple-instance mounts
  Remove get_init_pts_sb()
  Move common mknod_ptmx() calls into caller
  Parse mount options just once and copy them to super block
  Unroll essentials of do_remount_sb() into devpts
  vfs: simple_set_mnt() should return void
  fs: move bdev code out of buffer.c
  constify dentry_operations: rest
  constify dentry_operations: configfs
  constify dentry_operations: sysfs
  constify dentry_operations: JFS
  constify dentry_operations: OCFS2
  constify dentry_operations: GFS2
  constify dentry_operations: FAT
  constify dentry_operations: FUSE
  constify dentry_operations: procfs
  constify dentry_operations: ecryptfs
  constify dentry_operations: CIFS
  constify dentry_operations: AFS
  ...

constify dentry_operations: sysfs

2009-03-27T18:44:02+00:00

Signed-off-by: Al Viro

sysfs: fix some bin_vm_ops errors

2009-03-24T23:38:26+00:00

Commit 86c9508eb1c0ce5aa07b5cf1d36b60c54efc3d7a
"sysfs: don't block indefinitely for unmapped files" in linux-next
crashes the PowerMac G5 when X starts up.  It's caught out by the way
powerpc's pci_mmap of legacy_mem uses shmem_zero_setup(), substituting
a new vma->vm_file whose private_data no longer points to the bin_buffer
(substitution done because some versions of X crash if that mmap fails).

The fix to this is straightforward: the original vm_file is fput() in
that case, so this mmap won't block sysfs at all, so just don't switch
over to bin_vm_ops if vm_file has changed.

But more fixes made before realizing that was the problem:-

It should not be an error if bin_page_mkwrite() finds no underlying
page_mkwrite().

Check that a file already mmap'ed has the same underlying vm_ops
_before_ pointing vma->vm_ops at bin_vm_ops.

If the file being mmap'ed is a shmem/tmpfs file, don't fail the mmap
on CONFIG_NUMA=y, just because that has a set_policy and get_policy:
provide bin_set_policy, bin_get_policy and bin_migrate.

Signed-off-by: Hugh Dickins 
Acked-by: Eric Biederman 
Signed-off-by: Greg Kroah-Hartman

sysfs: only allow one scheduled removal callback per kobj

2009-03-24T23:38:26+00:00

The only way for a sysfs attribute to remove itself (without
deadlock) is to use the sysfs_schedule_callback() interface.

Vegard Nossum discovered that a poorly written sysfs ->store
callback can repeatedly schedule remove callbacks on the same
device over and over, e.g.

	$ while true ; do echo 1 > /sys/devices/.../remove ; done

If the 'remove' attribute uses the sysfs_schedule_callback API
and also does not protect itself from concurrent accesses, its
callback handler will be called multiple times, and will
eventually attempt to perform operations on a freed kobject,
leading to many problems.

Instead of requiring all callers of sysfs_schedule_callback to
implement their own synchronization, provide the protection in
the infrastructure.

Now, sysfs_schedule_callback will only allow one scheduled
callback per kobject. On subsequent calls with the same kobject,
return -EAGAIN.

This is a short term fix. The long term fix is to allow sysfs
attributes to remove themselves directly, without any of this
callback hokey pokey.

[cornelia.huck@de.ibm.com: s390 ccwgroup bits]

Reported-by: vegard.nossum@gmail.com
Signed-off-by: Alex Chiang 
Acked-by: Cornelia Huck 
Signed-off-by: Greg Kroah-Hartman

sysfs: don't block indefinitely for unmapped files.

2009-03-24T23:38:26+00:00

Modify sysfs bin files so that we can remove the bin file while they are
still mapped.  When the kobject is removed we unmap the bin file and
arrange for future accesses to the mapping to receive SIGBUS.

Implementing this prevents a nasty DOS when pci devices are hot plugged
and unplugged.  Where if any of their resources were mmaped the kernel
could not free up their pci resources or release their pci data
structures.

[akpm@linux-foundation.org: remove unused var]
Signed-off-by: Eric W. Biederman 
Cc: Jesse Barnes 
Acked-by: Tejun Heo 
Cc: Kay Sievers 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman