Re: [block] general protection fault in lo_rw_aio

On 2026/08/22 2:32, Bart Van Assche wrote:
> On 8/21/26 5:46 AM, Tetsuo Handa wrote:
>> On 2026/08/03 22:34, Tetsuo Handa wrote:
>>> I am waiting for your response on
>>> "[PATCH v5] loop: Fix NULL pointer dereference in lo_rw_aio()" at
>>> https://lkml.kernel.org/r/[email protected] .
>>
>> You have never responded for 4 months since I first contacted you at
>> https://lkml.kernel.org/r/[email protected] .
>> Nobody being interested in this problem has caused multiple issues for linux-next tree.
>> Will you become responsive on this problem?
> 
> Since I didn't like the proposed solution I took a look at this issue
> myself. If nobody objects I will integrate the patch below in my loop
> driver patch series.

Here is a review comment from AI Mode in Google Search.
I and Google consider that your patch is not sufficient.
At least your patch should be reviewed by sashiko, by posting your patch to ML.

----------
Thanks for working on this patch. 

However, I am concerned that using blk_mq_freeze_queue() alone is insufficient 
to resolve the underlying synchronization issues in the loop driver. While 
freezing the queue successfully prevents new I/O requests from entering, it 
does not guarantee that all asynchronous work currently pending or executing 
in the driver's internal workqueue has completely finished.

If we rely solely on freezing the queue, we still leave the door open for several 
critical race conditions:

1. NULL Pointer Dereference: Asynchronous work items might still trigger and 
   attempt to access structures or resources that are freed during cleanup.
2. Deadlocks: Unsynchronized worker threads and queue management tasks can 
   easily end up waiting on each other, causing a complete lockup.
3. Incomplete Work: Internal worker threads might be cut off mid-execution, 
   leaving the block device state corrupted or uncleaned.

To safely prevent these issues, we need to ensure that the driver's internal 
workqueue is completely synchronized and emptied. Instead of just a queue freeze, 
we should incorporate a proper drain_workqueue() mechanism (or drain the specific 
workqueue handling the async tasks) to guarantee that no lingering asynchronous 
workers are active during the critical path.

Could you please update the patch to include a thorough flushing/draining of 
the loop driver's internal workqueue?

Thanks,
----------