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

From: Cornelia Huck
Date: Fri Mar 13 2009 - 08:03:33 EST


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

> From: Alex Chiang <achiang@xxxxxx>
>
> 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@xxxxxxxxxx
> Reported-by: vegard.nossum@xxxxxxxxx
> Signed-off-by: Alex Chiang <achiang@xxxxxx>
> ---
> 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;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/