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 <abailon@xxxxxxxxxxxx>
Signed-off-by: Bryan O'Donoghue <pure.logic@xxxxxxxxxxxxxxxxx>
---
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
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
