lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 4 Jan 2014 18:34:03 +0000 From: Al Viro <viro@...IV.linux.org.uk> To: Greg Kroah-Hartman <gregkh@...uxfoundation.org> Cc: Mikulas Patocka <mpatocka@...hat.com>, Jeff Mahoney <jeffm@...e.com>, torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org, dm-devel@...hat.com, tglx@...utronix.de, paulmck@...ux.vnet.ibm.com, mingo@...nel.org Subject: Re: [PATCH] kobject: provide kobject_put_wait to fix module unload race On Sat, Jan 04, 2014 at 10:16:20AM -0800, Greg Kroah-Hartman wrote: > > I came up with a simpler patch to achieve the same purpose - this patch > > makes fixing the drivers easy - the driver is fixed just by replacing > > "kobject_put" with "kobject_put_wait" in the unload routine. > > No, that's not ok at all. Agreed - all it takes is one cargo-culter who religoiusly does such conversion and drops a ref to parent before that to child. > > However, this pattern is buggy with respect to modules. The release method > > is placed in the driver's module. When the driver exits, the module > > reference count is zero, thus the module may be freed. However, there may > > still be references to the kobject. If the module is unloaded and then the > > release method is called, a crash happens. > > Yes, module unloading while a kobject is still "active" is not a good > thing, what modules do you have that cause this problem? Why not just > grab the module reference in your kobject if you need this type of > protection? It's not the kobject's code fault that this issue is there, > or that we now have a "delayed release" function to expose this type of > thing, it's the user of the kobject. > > Please fix the broken users of the kobject first. <snide> Are you saying that there is another kind? </snide> When would you grab that reference to module? More to the point, when would you *drop* it? Doing so from module_exit is not going to work, obviously... -- 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