Messages in this thread | | | Date | Wed, 15 May 2019 15:07:30 +0200 | From | Jan Kara <> | Subject | Re: INFO: task hung in __get_super |
| |
On Wed 15-05-19 20:32:27, Tetsuo Handa wrote: > On 2019/05/15 19:21, Jan Kara wrote: > > The question is how to fix this problem. The simplest fix I can see is that > > we'd just refuse to do LOOP_SET_FD if someone has the block device > > exclusively open as there are high chances such user will be unpleasantly > > surprised by the device changing under him. OTOH this has some potential > > for userspace visible regressions. But I guess it's worth a try. Something > > like attached patch? > > (1) If I understand correctly, FMODE_EXCL is set at blkdev_open() only if > O_EXCL is specified.
Yes.
> How can we detect if O_EXCL was not used, for the reproducer ( > https://syzkaller.appspot.com/text?tag=ReproC&x=135385a8a00000 ) is not > using O_EXCL ?
mount_bdev() is using O_EXCL and that's what matters.
> (2) There seems to be no serialization. What guarantees that mount_bdev() > does not start due to preempted after the check added by this patch?
That's a good question. lo_ctl_mutex actually synchronizes most of this (taken in both loop_set_fd() and lo_open()) but you're right that there's still a small race window where loop_set_fd() need not see bdev->bd_holders elevated while blkdev_get() will succeed. So I need to think a bit more about proper synchronization of this.
Honza -- Jan Kara <jack@suse.com> SUSE Labs, CR
| |