The buf in fs/sysfs.c:subsys_attr_store() does not seem to be updated
correctly when returning a negative value (indicating that an error
condition has occurred) is returned. If a negative value is returned,
the next subsequent call to subsys_attr_store will have the contents of
buf appended to the previous call. Example: I have modified the
sd.c:sd_store_allow_restart to always print out the contents of the buf
and return an error using the following patch:
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -183,6 +183,9 @@ static ssize_t sd_store_allow_restart(struct class_device *c
struct scsi_disk *sdkp = to_scsi_disk(cdev);
struct scsi_device *sdp = sdkp->device;
+ printk(KERN_ERR "buf_ptr = 0x%p, buf = %s, count = %u\n", buf, buf, coun
+ return -EINVAL;
+
if (!capable(CAP_SYS_ADMIN))
return -EACCES;
I get the following output when writing invalid values to the
allow_restart sysfs file:
# echo x > /sys/class/scsi_disk/4:0:0:0/allow_restart
bash: echo: write error: Invalid argument
# echo y > /sys/class/scsi_disk/4:0:0:0/allow_restart
bash: echo: write error: Invalid argument
# echo z > /sys/class/scsi_disk/4:0:0:0/allow_restart
bash: echo: write error: Invalid argument
And the console output shows:
buf_ptr = 0xe00001004bdb0000, buf = x
, count = 2
buf_ptr = 0xe00001004bdb0000, buf = x
, count = 2
buf_ptr = 0xe00001004bdb0000, buf = x
y
, count = 4
buf_ptr = 0xe00001004bdb0000, buf = x
y
, count = 4
buf_ptr = 0xe00001004caf0000, buf = x
y
z
, count = 6
buf_ptr = 0xe00001004caf0000, buf = x
y
z
, count = 6
and the same append problem occurs when using another sysfs file:
# echo xyzzy > /sys/class/scsi_disk/4:0:1:0/allow_restart
bash: echo: write error: Invalid argument
buf_ptr = 0xe00001004caf0000, buf = x
y
z
xyzzy
, count = 12
I found this problem in 2.6.24-rc3 and and an earlier version of 2.6.23.
This seems to work correctly on 2.6.18 (at least with the RHEL5 kernel I
did some testing with), i.e. the contents of buf from the previous
failed called are thrown away/overwritten. I looked through sysfs.c to
see if I could find anything obvious but could not see anything.
Perhaps this is handled at a higher level.
--
Andrew Patterson
Hewlett-Packard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
