openwrtv4/target/linux/brcm2708/patches-4.9/950-0096-vchiq_arm-Access-the-dequeue_pending-flag-locked.patch
Rafał Miłecki fce21ae4cc brcm2708: rename all patches from raspberrypi git tree to use 950 prefix
Right now all brcm2708 patches are extracted from the non-mainline
raspberrypi/linux git tree. Many of them are hacks and/or are unneeded
in LEDE. Raspberry Pi is getting better and better mainline support so
it would be nice to finally start maintaining patches in a cleaner way:
1) Backport patches accepted in upstream tree
2) Start using upstream drivers
3) Pick only these patches that are needed for more complete support

Handling above tasks requires grouping patches - ideally using the same
prefixes as generic ones. It means we should rename existing patches to
use some high prefix. This will allow e.g. use 0xx for backported code.

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Stijn Tintel <stijn@linux-ipv6.be>
2017-03-24 08:06:35 +01:00

58 lines
1.9 KiB
Diff

From 64e39b18b8d51eb332a84ef79ed3ce0dd2a76808 Mon Sep 17 00:00:00 2001
From: Phil Elwell <phil@raspberrypi.org>
Date: Wed, 23 Mar 2016 14:16:25 +0000
Subject: [PATCH] vchiq_arm: Access the dequeue_pending flag locked
Reading through this code looking for another problem (now found in userland)
the use of dequeue_pending outside a lock didn't seem safe.
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
---
.../vc04_services/interface/vchiq_arm/vchiq_arm.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -279,6 +279,7 @@ service_callback(VCHIQ_REASON_T reason,
USER_SERVICE_T *user_service;
VCHIQ_SERVICE_T *service;
VCHIQ_INSTANCE_T instance;
+ int skip_completion = 0;
DEBUG_INITIALISE(g_state.local)
DEBUG_TRACE(SERVICE_CALLBACK_LINE);
@@ -345,9 +346,6 @@ service_callback(VCHIQ_REASON_T reason,
user_service->msg_queue[user_service->msg_insert &
(MSG_QUEUE_SIZE - 1)] = header;
user_service->msg_insert++;
- spin_unlock(&msg_queue_spinlock);
-
- up(&user_service->insert_event);
/* If there is a thread waiting in DEQUEUE_MESSAGE, or if
** there is a MESSAGE_AVAILABLE in the completion queue then
@@ -356,13 +354,22 @@ service_callback(VCHIQ_REASON_T reason,
if (((user_service->message_available_pos -
instance->completion_remove) >= 0) ||
user_service->dequeue_pending) {
- DEBUG_TRACE(SERVICE_CALLBACK_LINE);
user_service->dequeue_pending = 0;
- return VCHIQ_SUCCESS;
+ skip_completion = 1;
}
+ spin_unlock(&msg_queue_spinlock);
+
+ up(&user_service->insert_event);
+
header = NULL;
}
+
+ if (skip_completion) {
+ DEBUG_TRACE(SERVICE_CALLBACK_LINE);
+ return VCHIQ_SUCCESS;
+ }
+
DEBUG_TRACE(SERVICE_CALLBACK_LINE);
return add_completion(instance, reason, header, user_service,