Doing an rmmod gb_loopback will cause an oops with the following backtrace.
Call Trace: debugfs_remove+0xaf/0x180 gb_loopback_disconnect+0x36/0x160 [gb_loopback] greybus_remove+0x87/0x1a0 [greybus] device_release_driver_internal+0x14a/0x200 driver_detach+0x39/0x60 bus_remove_driver+0x47/0xa0 driver_unregister+0x27/0x50 greybus_deregister_driver+0xd/0x10 [greybus] loopback_exit+0x1c/0x36 [gb_loopback] SyS_delete_module+0x170/0x1b0 entry_SYSCALL_64_fastpath+0x13/0x93 This happens because gb_dev.root is removed prior to greybus_deregister_driver which itself will trigger gb_loopback_disconnect to run - leading to the parent of gb->file being NULL. Typically up to this point when tearing down greybus modules we have removed gb_es2 prior to removing gb_loopback. In this case gb_es2 will run subordinate greybus->disconnect() routines. A subsequent rmmod of gb_loopback then will not re-run gb_loopback_disconnect(). On project Ara the second module removal flow was the only practiced flow hence it's only now in gbsim where we have more freedom to rmmod that this bug is apparent. The fix itself is pretty straight-forward. Signed-off-by: Bryan O'Donoghue <pure.lo...@nexus-software.ie> --- drivers/staging/greybus/loopback.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/greybus/loopback.c b/drivers/staging/greybus/loopback.c index 88d4f5c..8f3eb33 100644 --- a/drivers/staging/greybus/loopback.c +++ b/drivers/staging/greybus/loopback.c @@ -1260,9 +1260,9 @@ module_init(loopback_init); static void __exit loopback_exit(void) { - debugfs_remove_recursive(gb_dev.root); greybus_deregister(&gb_loopback_driver); class_unregister(&loopback_class); + debugfs_remove_recursive(gb_dev.root); ida_destroy(&loopback_ida); } module_exit(loopback_exit); -- 2.7.4 _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel