From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752409Ab1LQWaj (ORCPT ); Sat, 17 Dec 2011 17:30:39 -0500 Received: from zeniv.linux.org.uk ([195.92.253.2]:48289 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751061Ab1LQWah (ORCPT ); Sat, 17 Dec 2011 17:30:37 -0500 Date: Sat, 17 Dec 2011 22:30:33 +0000 From: Al Viro To: Sergey Senozhatsky Cc: Jens Axboe , Andrew Morton , Kay Sievers , Namhyung Kim , Lukas Czerner , linux-kernel@vger.kernel.org Subject: Re: [PATCH] loop: fput() called in loop_clr_fd() may cause bd_mutex recursive locking Message-ID: <20111217223033.GB2203@ZenIV.linux.org.uk> References: <20111217215333.GA3313@swordfish> <20111217221232.GA2203@ZenIV.linux.org.uk> <20111217221928.GB3313@swordfish> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111217221928.GB3313@swordfish> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Dec 18, 2011 at 01:19:28AM +0300, Sergey Senozhatsky 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(). 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. And your patch would simply leave the underlying device opened, with all the consequences...