On Mon, Sep 02, 2013 at 09:21:55AM +0930, Rusty Russell wrote: > Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> writes: > > On Tue, Aug 27, 2013 at 02:08:27PM +0930, Rusty Russell wrote: > >> Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> writes: > >> > On Thu, Aug 22, 2013 at 03:37:55PM +0800, Li Zhong wrote: > >> >> DEBUG_KOBJECT_RELEASE helps to find the issue attached below. > >> > People are starting to hit these types of issues, and I'd like to take > >> > this one out of the picture. > >> > > >> > Rusty, any objection to me taking this through my driver-core tree, > >> > where this new config option shows up? > >> > >> The original fix was better. > >> > >> Moving the module_kobject out and giving it its own lifetime solves this > >> immediate issue, but it still means there's an accessible module_kobject > >> around referring to a module which doesn't exist any more. > > > > That's ok, it could happen before as well. What's wrong with that? > > > >> Original copied below, feel free to take it. > > > > You are just sitting and sleeping until someone drops the last reference > > to the module. What if userspace grabs a reference from sysfs? That > > could never return, I don't think you want to stall that out. > > In your scenario, what happens if userspace grabs a reference via sysfs? > It then tries to use module_kobj->mod which points into freed memory? > > eg. show_modinfo_##field or show_refcnt. The sysfs file will not be able to be "called" as Tejun fixed that up a long time ago, but yes, you are right, it really doesn't solve the issue. > Is there an owner field I'm missing somewhere which stops this from > happening? Otherwise, we can't unload the module until it's done. Good point. > > I'd prefer not having 2 things determining the lifecycle of a single > > object, that's messy, and not needed at all. > > Normally you'd grab a reference to the module via an owner pointer. > Doing that in kobject seems like overkill, so we're working around it > here... Ok, fair enough, your version is fine, feel free to add a: Acked-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> if you want it. thanks, greg k-h -- 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
