Messages in this thread |  | | Date | Wed, 10 Feb 2010 15:05:44 -0800 | From | Greg KH <> | Subject | Re: [PATCH] sysfs: differentiate between locking links and non-links |
| |
On Wed, Feb 10, 2010 at 10:25:21AM -0800, Eric W. Biederman wrote: > Tejun Heo <tj@kernel.org> writes: > > > On 02/10/2010 05:03 PM, Eric W. Biederman wrote: > >> Tejun Heo <tj@kernel.org> writes: > >> > >>> Hello, > >>> > >>> On 02/10/2010 11:08 AM, Américo Wang wrote: > >>>> This bug report is new for me. Recently we received lots of sysfs lockdep > >>>> warnings, I am working on a patch to fix all the bogus ones. > >>>> > >>>> However, this one is _not_ similar to the other cases, as you decribed. > >>>> This patch could fix the problem, but not a good fix, IMO. We need more > >>>> work in sysfs layer to fix this kind of things. I will take care of this. > >>> > >>> Can't we just give each s_active lock a separate class? Would that be > >>> too costly? > >> > >> When I asked the question earlier I was told that that locking classes > >> require static storage. Where would that static storage come from? > > > > Maybe I'm glossly misunderstanding it but wouldn't embedding struct > > lockdep_map into sysfs_node as in work_struct do the trick? > > In lockdep_init_map there is the following check: > > /* > * Sanity check, the lock-class key must be persistent: > */ > if (!static_obj(key)) { > printk("BUG: key %p not in .data!\n", key); > DEBUG_LOCKS_WARN_ON(1); > return; > } > > It needs playing with but I think we can embed something in struct > attribute, and simply disallow dynamically allocated instances of > struct attribute.
I think some code dynamically creates attributes today, as this has never been a restriction.
So I don't know if this is going to work :(
thanks,
greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |