On Thu, 2013-08-22 at 16:30 +0930, Rusty Russell wrote: > Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> writes: > > On Wed, Aug 21, 2013 at 05:49:58PM +0800, Li Zhong wrote: > > > struct kobj_type module_ktype = { > > > + .release = module_kobj_release, > > > .sysfs_ops = &module_sysfs_ops, > > > }; > > > > Wait, as there is no release function here for the kobject (a different > > problem), why is the deferred release function causing any problems? > > There is no release function to call, so what is causing the oops? > > Because DEBUG_KOBJECT_RELEASE does the kobject_put() sometime later, > which is what causes the oops. > > Since kobjects don't have an owner field, AFAICT someone *could* grab > one in a module which is unloading, then put it after unload. So this > fixes a real bug, albeit not one seen in the real world. > > Applied, Oh, thank you, Rusty. I just sent out another version... which fix it in another way as Greg suggested, could you please also help to take a look at it? Thanks, Zhong > Rusty. > -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html