linux.git/fs/sysfs/file.c, branch v2.6.34

sysfs: Only take active references on attributes.

2010-03-08T01:04:51+00:00

If we exclude directories and symlinks from the set of sysfs
dirents where we need active references we are left with
sysfs attributes (binary or not).

- Tweak sysfs_deactivate to only do something on attributes
- Move lockdep initialization into sysfs_file_add_mode to
  limit it to just attributes.

Signed-off-by: Eric W. Biederman 
Acked-by: WANG Cong 
Cc: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman

sysfs: Remove sysfs_get/put_active_two

2010-03-08T01:04:51+00:00

It turns out that holding an active reference on a directory is
pointless.  The purpose of the active references are to allows us to
block when removing sysfs entries that have custom methods so we don't
remove modules while running modular code and to keep those custom
methods from accessing data structures after the files have been
removed.  Further sysfs_remove_dir remove all elements in the
directory before removing the directory itself, so there is no chance
we will remove a directory with active children.

Signed-off-by: Eric W. Biederman 
Cc: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman

Driver core: Constify struct sysfs_ops in struct kobj_type

2010-03-08T01:04:49+00:00

Constify struct sysfs_ops.

This is part of the ops structure constification
effort started by Arjan van de Ven et al.

Benefits of this constification:

 * prevents modification of data that is shared
   (referenced) by many other structure instances
   at runtime

 * detects/prevents accidental (but not intentional)
   modification attempts on archs that enforce
   read-only kernel data at runtime

 * potentially better optimized code as the compiler
   can assume that the const data cannot be changed

 * the compiler/linker move const data into .rodata
   and therefore exclude them from false sharing

Signed-off-by: Emese Revfy 
Acked-by: David Teigland 
Acked-by: Matt Domsch 
Acked-by: Maciej Sosnowski 
Acked-by: Hans J. Koch 
Acked-by: Pekka Enberg 
Acked-by: Jens Axboe 
Acked-by: Stephen Hemminger 
Signed-off-by: Greg Kroah-Hartman

sysfs: Add sysfs_add/remove_files utility functions

2010-03-08T01:04:47+00:00

Adding/Removing a whole array of attributes is very common. Add a standard
utility function to do this with a simple function call, instead of
requiring drivers to open code this.

Signed-off-by: Andi Kleen 
Signed-off-by: Greg Kroah-Hartman

sysfs: In sysfs_chmod_file lazily propagate the mode change.

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

Now that sysfs_getattr and sysfs_permission refresh the vfs
inode there is no need to immediatly push the mode change
into the vfs cache.  Reducing the amount of work needed and
simplifying the locking.

Acked-by: Tejun Heo 
Acked-by: Serge Hallyn 
Signed-off-by: Eric W. Biederman 
Signed-off-by: Greg Kroah-Hartman

sysfs: Simplify sysfs_chmod_file semantics

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

Currently every caller of sysfs_chmod_file happens at either
file creation time to set a non-default mode or in response
to a specific user requested space change in policy.  Making
timestamps of when the chmod happens and notification of
a file changing mode uninteresting.

Remove the unnecessary time stamp and filesystem change
notification, and removes the last of the explicit inotify
and donitfy support from sysfs.

Acked-by: Tejun Heo 
Acked-by: Serge Hallyn 
Signed-off-by: Eric W. Biederman 
Signed-off-by: Greg Kroah-Hartman

sysfs: Allow sysfs_notify_dirent to be called from interrupt context.

2009-10-14T22:16:25+00:00

sysfs_notify_dirent is a simple atomic operation that can be used to
alert user-space that new data can be read from a sysfs attribute.

Unfortunately it cannot currently be called from non-process context
because of its use of spin_lock which is sometimes taken with
interrupts enabled.

So change all lockers of sysfs_open_dirent_lock to disable interrupts,
thus making sysfs_notify_dirent safe to be called from non-process
context (as drivers/md does in md_safemode_timeout).

sysfs_get_open_dirent is (documented as being) only called from
process context, so it uses spin_lock_irq.  Other places
use spin_lock_irqsave.

The usage for sysfs_notify_dirent in md_safemode_timeout was
introduced in 2.6.28, so this patch is suitable for that and more
recent kernels.

Reported-by: Joel Andres Granados 
Signed-off-by: NeilBrown 
Signed-off-by: Dan Williams 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

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