[PATCH 2/2] staging: greybus: loopback: fix oops on rmmod gb_loopback

[Bryan O'Donoghue]

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.logic at 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