lkml.org 
[lkml]   [2011]   [Dec]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] loop: fput() called in loop_clr_fd() may cause bd_mutex recursive locking
On (12/17/11 22:30), Al Viro wrote:
> > Sorry, why is that a false positive?
> >
> > blkdev_put() calls lo_release() while holding bd_mutex,
> > lo_release() calls loop_clr_fd() -> fput(). fput() once again
> > attempts to grub already held bd_mutex calling blkdev_put().
> > Looks like a recursion to me.
>
> Because of this:
> /* Avoid recursion */
> f = file;
> while (is_loop_device(f)) {
> struct loop_device *l;
>
> if (f->f_mapping->host->i_bdev == bdev)
> goto out_putf;
>
> l = f->f_mapping->host->i_bdev->bd_disk->private_data;
> if (l->lo_state == Lo_unbound) {
> error = -EINVAL;
> goto out_putf;
> }
> f = l->lo_backing_file;
> }
> in loop_set_fd().

Oh, thanks. I didn't notice that one.

> Think of it for a minute - if we could run into the
> same bdev in that recursion, what would have happened on read() from
> that sucker? So yes, it is a false positive.

I've tried read()/write() some time ago and it worked. Perhaps, I just
wasn't "lucky" enough to hit any problems.

> And your patch would simply leave the underlying device opened,
> with all the consequences...
>
well, that sucks.


Sergey


\
 
 \ /
  Last update: 2011-12-17 23:43    [W:0.058 / U:0.568 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site