Re: [PATCH, RFC] sysfs: only allow one scheduled removal callback per kobj

[Cornelia Huck <cornelia.huck@de.ibm.com>]

On Thu, 12 Mar 2009 16:02:31 -0600,
Alex Chiang <achiang@hp.com> wrote:

> From: Alex Chiang <achiang@hp.com>
> 
> sysfs: only allow one scheduled removal callback per kobj
> 
> 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.
> 
> Cc: cornelia.huck@de.ibm.com
> Reported-by: vegard.nossum@gmail.com
> Signed-off-by: Alex Chiang <achiang@hp.com>
> ---
> Greg, I think this is .30 material; we're late in the -rc cycle
> now and we're changing the semantics of an API.
> 
> Cornelia, I understand your earlier point about a smaller patch
> in the caller, but I think pushing the code down into the
> infrastructure is the right thing to do. 

OK, I don't have further objections.

> Also, I wasn't brave
> enough to patch your ccwgroup_ungroup_store(), but I think you
> won't need the gdev->onoff stuff anymore in that code path.

We still need it to prevent online/offline vs. ungroup races.

While device_schedule_callback() should not be able to return -EAGAIN
on us, I'll sleep better if you could add the following snippet to your
patch:

---
 drivers/s390/cio/ccwgroup.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- linux-2.6.orig/drivers/s390/cio/ccwgroup.c
+++ linux-2.6/drivers/s390/cio/ccwgroup.c
@@ -104,8 +104,9 @@ ccwgroup_ungroup_store(struct device *de
 	rc = device_schedule_callback(dev, ccwgroup_ungroup_callback);
 out:
 	if (rc) {
-		/* Release onoff "lock" when ungrouping failed. */
-		atomic_set(&gdev->onoff, 0);
+		if (rc != -EAGAIN)
+			/* Release onoff "lock" when ungrouping failed. */
+			atomic_set(&gdev->onoff, 0);
 		return rc;
 	}
 	return count;