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.021 / U:120.540 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site