From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Tomlin Subject: Re: [RFC PATCH] fs: Use a seperate wq for do_sync_work() to avoid a potential deadlock Date: Fri, 19 Sep 2014 16:44:23 +0100 Message-ID: <20140919154423.GH25400@atomlin.usersys.redhat.com> References: <1410953942-32144-1-git-send-email-atomlin@redhat.com> <20140917182202.GE19308@redhat.com> <20140917204634.GB25400@atomlin.usersys.redhat.com> <20140917211613.GU4322@dastard> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: Oleg Nesterov , linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk, bmr@redhat.com, jcastillo@redhat.com, mguzik@redhat.com, linux-kernel@vger.kernel.org To: Dave Chinner Return-path: Content-Disposition: inline In-Reply-To: <20140917211613.GU4322@dastard> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, Sep 18, 2014 at 07:16:13AM +1000, Dave Chinner wrote: > > - Both lru_add_drain and do_sync_work work items are added to > > the same global system_wq > > > > - The current work fn on the system_wq is do_sync_work and is > > blocked waiting to aquire an sb's s_umount for reading > > > > - The umount task is the current owner of the s_umount in > > question but is waiting for do_sync_work to continue. > > Thus we hit a deadlock situation. > > What kernel did you see this deadlock on? Sorry for the noise. This deadlock was produced under a kernel whereby the workqueue implementation is significantly less sophisticated. -- Aaron Tomlin