commit e854ff58ed70 ("greybus: loopback: add runtime pm support") introduces pm runtime support to the loopback code. If a gb_pm_runtime_get_sync() fails, currently we immediately return from the loopback thread.
Alexandre reports that later on, subsequent to the afore mentioned failure, doing an rmmod will trigger a kthread_stop() which will will generate a fault. The fault results from dereferencing gb->task in gb_loopback_disconnect(). One way to fix that is to have the loopback thread do_exit() instead of simply returning on gb_pm_runtime_get_sync() failure - however this will leave dangling sysfs entries with no loopback thread to take action based on the sysfs inputs. This patch fixes the fault by ignoring the gb_pm_runtime_get_sync() result code, this will allow only gb_loopback_disconnect() to terminate the loopback thread. Fix validated in gbsim. Next steps on this driver entail changing the relationship between /sysfs and the loopback thread - probably making the loopback thread dynamically started/stopped - as opposed to the pre-allocation model currently used but, those changes are for a future series to address. Reported-by: Alexandre Bailon <abai...@baylibre.com> Signed-off-by: Bryan O'Donoghue <pure.lo...@nexus-software.ie> --- drivers/staging/greybus/loopback.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/staging/greybus/loopback.c b/drivers/staging/greybus/loopback.c index 83f3b9f..88d4f5c 100644 --- a/drivers/staging/greybus/loopback.c +++ b/drivers/staging/greybus/loopback.c @@ -886,9 +886,7 @@ static int gb_loopback_fn(void *data) gb_pm_runtime_put_autosuspend(bundle); wait_event_interruptible(gb->wq, gb->type || kthread_should_stop()); - ret = gb_pm_runtime_get_sync(bundle); - if (ret) - return ret; + gb_pm_runtime_get_sync(bundle); } if (kthread_should_stop()) -- 2.7.4 _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel