On Tue 25-09-18 06:06:56, Tetsuo Handa wrote:
> On 2018/09/25 3:47, Jan Kara wrote:
> >> +/*
> >> + * unlock_loop - Unlock loop_mutex as needed.
> >> + *
> >> + * Explicitly call this function before calling fput() or blkdev_reread_part()
> >> + * in order to avoid circular lock dependency. After this function is called,
> >> + * current thread is no longer allowed to access "struct loop_device" memory,
> >> + * for another thread would access that memory as soon as loop_mutex is held.
> >> + */
> >> +static void unlock_loop(void)
> >> +{
> >> + if (loop_mutex_owner == current) {
> >
> > Urgh, why this check? Conditional locking / unlocking is evil so it has to
> > have *very* good reasons and there is not any explanation here. So far I
> > don't see a reason why this is needed at all.
>
> Yeah, this is why Jens hates this patch. But any alternative?
So can you explain why this conditional locking is really necessary?
> >> @@ -630,7 +669,12 @@ static void loop_reread_partitions(struct loop_device *lo,
> >> + unlock_loop();
> >
> > Unlocking in loop_reread_partitions() makes the locking rules ugly. And
> > unnecessarily AFAICT. Can't we just use lo_refcnt to protect us against
> > loop_clr_fd() and freeing of 'lo' structure itself?
>
> Really? I think that just elevating lo->lo_refcnt will cause another lockdep
> warning because __blkdev_reread_part() requires bdev->bd_mutex being held.
> Don't we need to drop the lock in order to solve original lockdep warning at [2] ?
Yes, you have to drop the lo_ctl_mutex before calling
loop_reread_partitions(). But AFAICS all places calling loop_reread_part()
are called from ioctl where we are sure the device is open and thus
lo_refcnt is > 0. So in these places calling loop_reread_partitions()
without lo_ctl_mutex should be fine. The only exception is lo_clr_fd() that
can get called from __lo_release() - and I think we can protect that case
against LOOP_CTL_REMOVE (it cannot really race with anything else) by
keeping lo_state at Lo_rundown until after loop_reread_partitions() has
finished.
Honza
--
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR
