sysfs: refill attribute buffer when reading from offset 0
Requiring userspace to close and re-open sysfs attributes has been the
policy since before 2.6.12. It allows userspace to get a consistent
snapshot of kernel state and consume it with incremental reads and seeks.
Now, if the file position is zero the kernel assumes userspace wants to see
the new value. The application for this change is to allow a userspace
RAID metadata handler to check the state of an array without causing any
memory allocations. Thus not causing writeback to a raid array that might
be blocked waiting for userspace to take action.
Cc: Neil Brown <neilb@suse.de>
Acked-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
index a859c32..ade9a7e 100644
--- a/fs/sysfs/file.c
+++ b/fs/sysfs/file.c
@@ -129,7 +129,7 @@
ssize_t retval = 0;
mutex_lock(&buffer->mutex);
- if (buffer->needs_read_fill) {
+ if (buffer->needs_read_fill || *ppos == 0) {
retval = fill_read_buffer(file->f_path.dentry,buffer);
if (retval)
goto out;
@@ -410,8 +410,7 @@
* return POLLERR|POLLPRI, and select will return the fd whether
* it is waiting for read, write, or exceptions.
* Once poll/select indicates that the value has changed, you
- * need to close and re-open the file, as simply seeking and reading
- * again will not get new data, or reset the state of 'poll'.
+ * need to close and re-open the file, or seek to 0 and read again.
* Reminder: this only works for attributes which actively support
* it, and it is not possible to test an attribute from userspace
* to see if it supports poll (Neither 'poll' nor 'select' return