[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090313130314.77dc18ed@gondolin>
Date: Fri, 13 Mar 2009 13:03:14 +0100
From: Cornelia Huck <cornelia.huck@...ibm.com>
To: Alex Chiang <achiang@...com>
Cc: Greg KH <gregkh@...e.de>, Tejun Heo <tj@...nel.org>,
Vegard Nossum <vegard.nossum@...il.com>,
Pekka Enberg <penberg@...helsinki.fi>,
Ingo Molnar <mingo@...e.hu>, jbarnes@...tuousgeek.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH, RFC] sysfs: only allow one scheduled removal callback
per kobj
On Thu, 12 Mar 2009 16:02:31 -0600,
Alex Chiang <achiang@...com> wrote:
> From: Alex Chiang <achiang@...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@...ibm.com
> Reported-by: vegard.nossum@...il.com
> Signed-off-by: Alex Chiang <achiang@...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;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists