On 10/11/24 10:21, Chenyuan Yang wrote:
Hi Greg,
I'm curious about the best approach to fix this issue. I'm unsure if
adding a spinlock or mutex around the code would be good to ensure
that only one thread can modify the list at a time (then fix this
issue).
Alternatively, we could check if the entry is already in the list
within the vep_queue function:
```
if (!list_empty(&new_entry->list)) {
// Entry is already in the list, handle it (e.g., log an error or ignore)
return -EEXIST; // Or another appropriate error code
}
vep_queue() function is holding udc lock when it updates
the status and calls list_add_tail(). vep_dequeue() does
the same.
vep_free_request() doesn't see to hold the udc lock. I will
tale a look at this a bit more and get back to you on the
best approach. My guess is that the fix will be in another
function such as vep_free_request() - at the moment - that
routine is the one I suspect.
// Safe to add the entry to the list
list_add_tail(&new_entry->list, &queue->list);
```
This approach would avoid unnecessary locking overhead if the entry is
not already in the list.
Please let me know your thoughts on these options or if you have any
other suggestions.
Best,
Chenyuan
thanks,
-- Shuah
