Messages in this thread | | | Date | Sun, 01 Mar 2009 10:47:07 +0100 | From | Jiri Slaby <> | Subject | Re: [PATCH 2/2] loop : Don't hold the lo_ctl_mutex while fput in loop_clr_fd |
| |
On 28.4.2008 04:33, Dave Young wrote: > On Mon, Apr 28, 2008 at 10:15 AM, Al Viro<viro@zeniv.linux.org.uk> wrote: >> On Mon, Apr 28, 2008 at 03:13:09AM +0100, Al Viro wrote: >> > On Mon, Apr 28, 2008 at 10:10:22AM +0800, Dave Young wrote: >> > > [Fixing bug 10504] >> > > >> > > If the bakingfile is a block device file, losetuo -d will trigger lockdep >> > > warning of "circular locking dependency". >> > > >> > > open/release lock order : bdev->bd_mutex ---> lo->lo_ctl_mutex >> > > loop_clr_fd lock order : lo->lo_ctl_mutex ---> bdev->bd_mutex (fput) >> > > >> > > Don't hold the lo_ctl_mutex while fput in loop_clr_fd to fix it. It's safe >> > > because all loop device state will be consistent here. >> > >> > Explain. > > Hi, Maybe I have some mis-understood, thanks for pointing out in advance. > > IMO the lo_ctl_mutex is for the lo->* state locking, they are all set > to proper values before fput(filp), so I think it's safe to do that. > >> BTW, explain also why open() at that spot will not do interesting things >> wrt BLKRRPART done a bit below, please. >> > > open with a loop device unbound? Sorry, I don't understand. Could you > explain a bit? Thanks
Any ideas here? Al? The bug survived almost a year...
| |