On 2022/01/20 17:50, Karel Zak wrote: > On Wed, Jan 19, 2022 at 10:34:15PM +0100, Jan Kara wrote: >> On Wed 19-01-22 20:30:52, Tetsuo Handa wrote: >>> 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 >>> . >> >> No, you have found a way to make the race window for mount(8) smaller. And >> I still disagree with that kernel change because it is making kernel more >> complex only to make the race window smaller. On another machine or with >> different scheduling decisions, you can still hit this race. This problem >> must be fixed in mount... > > +1 > > I think Jan is right. In this case mount(8) is not robust enough. It > reads info about the device from /sys and then it opens the device. > Unfortunately, whatever can happen before the open() call. > I'm not objecting to fix /bin/mount itself. Please check [PATCH 4/4] loop: wait for __loop_clr_fd() to complete upon lo_open() in https://lkml.kernel.org/r/cdaf1346-2885-f0da-8878-12264bd48348@xxxxxxxxxxxxxxxxxxx . /bin/mount needs to be updated to check ioctl(LOOP_GET_STATUS) after open() in order to confirm that lo->lo_state remains Lo_bound. But we need some migration period for allowing users to update their util-linux package. Thus, meantime emulate serialization between lo_open() and lo_release() without using disk->open_mutex.
