Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit fece9c87 authored by Bryan O'Donoghue's avatar Bryan O'Donoghue Committed by Greg Kroah-Hartman
Browse files

greybus: Ensure gb->mutex is held when adding timer 



Currently in loopback on the async path we issue an operation and then add
a timer to time-out that operation should it fail to complete. Looking at a
backtrace given in its feasible op_async->pending can be true and
del_timer() can run before add_timer() has run. In the callback handler we
already hold gb->mutex. This patch fixes that potential race by ensuring we
hold gb->mutex both when we are adding and when we are removing the
relevant timer.

Signed-off-by: default avatarBryan O'Donoghue <bryan.odonoghue@linaro.org>
Reported-and-tested-by: default avatarAxel Haslam <ahaslam@baylibre.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@google.com>
parent 1dc8d3d7

drivers/staging/greybus/loopback.c

+4 −1
Original line number Diff line number Diff line
@@ -626,6 +626,7 @@ static int gb_loopback_async_operation(struct gb_loopback *gb, int type, 
	do_gettimeofday(&op_async->ts);

	op_async->pending = true;

	atomic_inc(&gb->outstanding_operations);

	mutex_lock(&gb->mutex);

	ret = gb_operation_request_send(operation,

					gb_loopback_async_operation_callback,

					GFP_KERNEL);
@@ -637,9 +638,11 @@ static int gb_loopback_async_operation(struct gb_loopback *gb, int type, 
	op_async->timer.data = (unsigned long)operation->id;

	add_timer(&op_async->timer);



	return ret;

	goto done;

error:

	gb_loopback_async_operation_put(op_async);

done:

	mutex_unlock(&gb->mutex);

	return ret;

}