I found a way to avoid this race by splitting lo_open() into two phases using task_work_add(). Christoph Hellwig is trying to take a look at https://lkml.kernel.org/r/f6b947d0-1047-66b3-0243-af5017c9ab55@xxxxxxxxxxxxxxxxxxx . On 2022/01/12 22:16, Jan Kara wrote: > I don't think we can fully solve this race in the kernel and IMO it is > futile to try that - depending on when exactly systemd-udev decides to s/systemd-udev/systemd-udevd/g > close /dev/loop0 and how exactly mount decides to implement its loop device > reuse, different strategies will / will not work. Assuming memory leak + spin_unlock(&loop_delete_spinlock); -+ if (err) -+ return err; ++ if (err) { ++ kfree(lot); ++ kfree(lrt); ++ return err; ++ } + /* Add to spool, for -ENOMEM upon release() cannot be handled. */ in that patch is fixed, trying to solve this race on the kernel side looks not such bad.
