RE: [PATCH v4] misc: mei: fix race condition between client teardown and read completion

[nirbhayykumarr]

On Sunday, August 30th, 2026 at 2:06 PM, Usyskin, Alexander <alexander.usyskin@xxxxxxxxx> wrote:
> 
> This change look like no-op in this flow as you moved mei_cl_flush_queues() inside the mei_cl_unlink(),
> but mei_cl_unlink() is called here straight after mei_cl_flush_queues() without releasing device_lock.
> 
> Seems like the failure is real but analysis and patch is wrong.
> I suppose there is another path that call mei_cl_unlink() without proper queue cleanup.
> 

Hi Sasha,

You were right. Moving mei_cl_flush_queues() into mei_cl_unlink() 
was a no-op because the lock is held across both calls.

Your comment prompted me to look deeper, and I realized the issue 
wasn't the call location, but that mei_cl_flush_queues() itself was 
fundamentally broken. Specifically, mei_cl_free_pending() was using 
list_first_entry_or_null() and only freeing a maximum of one callback 
per flush leaving any other queued read callbacks stranded on the list 
to trigger the WARN_ON.

I will send a v5 patch to the list which corrects this by properly 
iterating through the pending queues and allowing per-file descriptor 
filtering during teardown.

Thanks for the review and guidance.

Best regards,
Nirbhay Kumar