On Apr 28, 2013, at 4:32 PM, Michael van Elst <mlel...@serpens.de> wrote:
> On Sun, Apr 28, 2013 at 01:50:37PM +0200, J. Hannken-Illjes wrote: > >>> The locking order hasn't been changed, but the faulty tryenter has been >>> replaced with an enter. >> >> Sure -- and that is the problem. The locking order was wrong and you >> removed the hack/workaround without fixing the lock order. > > I now release the mnt_unmounting lock before aquiring the mountlist_lock. > This opens a race condition for a concurrent umount that I prevent by > raising the nest counter. With this change I can no longer provoke > the deadlock. > > The only difference should now be that vfs_hooks_unmount() is called > outside the unmounting lock. But since it is operating on an already > detached mountpoint (if it is used at all) before it is destroyed, > that should be harmless. > > What do you think? <snip> Unfortunately this also opens a race for do_sys_sync to succeed with vfs_busy() and call ffs_sync() with mp->mnt_data == NULL -> BOMB. -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
