Re: [PATCH v6] loop: Fix NULL pointer dereference in lo_rw_aio()

[Tetsuo Handa]

On 2026/08/25 7:53, Bart Van Assche wrote:
> On 8/24/26 3:06 PM, Tetsuo Handa wrote:
>> but sashiko found problems with Bart's series ( https://sashiko.dev/
>> #/patchset/8330ca0e-b4d9-451a-bc0d-a50178194ea8@xxxxxxxxxxxxxxxxxxx
>> and https://sashiko.dev/#/patchset/2efb1032-34b9-4c31-
>> b6fc-4aa9b1d60895@xxxxxxxxxxxxxxxxxxx ).
> 
> Thanks, I had not yet seen this feedback from Sashiko. My conclusion is
> that two of the three Sashiko findings are wrong. I will fix the third
> one - the finding about the potential wait-die deadlock.
> 

As of commit fe4c990e6a30 ("loop: Add __guarded_by() annotations") in block-loop branch,

  modprobe loop
  losetup /dev/loop0 testfile.img; losetup /dev/loop1 /dev/loop0; losetup -D
  sleep 1
  losetup /dev/loop1 testfile.img; losetup /dev/loop0 /dev/loop1; losetup -D

causes lockdep warning. This is a false positive, but we need to avoid it anyway.

>> I still cannot catch why Bart's approach can become safe without
>> synchronize_rcu() and drain_workqueue().
> 
> Agreed that drain_workqueue() or flush_workqueue() is necessary. I do
> not agree that an explicit synchronize_rcu() call is required. Waiting
> until the request queue is frozen includes this call implicitly.
> See also __percpu_ref_switch_to_atomic().

OK. You recognized that we need drain_workqueue() or flush_workqueue(), and

On 2026/08/25 8:24, Bart Van Assche wrote:
> On 8/24/26 3:53 PM, Bart Van Assche wrote:
>> On 8/24/26 3:06 PM, Tetsuo Handa wrote:
>>> I still cannot catch why Bart's approach can become safe without
>>> synchronize_rcu() and drain_workqueue().
>>
>> Agreed that drain_workqueue() or flush_workqueue() is necessary. I do
>> not agree that an explicit synchronize_rcu() call is required. Waiting
>> until the request queue is frozen includes this call implicitly.
>> See also __percpu_ref_switch_to_atomic().
> 
> A correction: it is not safe to call drain_workqueue() nor to freeze the
> request queue in __loop_clr_fd(). I'm considering to modify the comment
> in that function as follows:

you also recognized that we can't call drain_workqueue() or flush_workqueue().

Therefore, I chose to temporarily drop lo->lo_disk->open_mutex in order to
make it possible to safely perform drain_workqueue().