From: Jens Axboe Subject: Re: [PATCH] Fix lost wake-up shutting down writeback thread Date: Sat, 28 Aug 2010 08:50:48 +0200 Message-ID: <4C78B1C8.10909@fusionio.com> References: <20100825023425.GA24591@fieldses.org> <1282889595.2763.14.camel@localhost> <1282901780.12016.54.camel@localhost> <4C77B873.8010306@netapp.com> <20100827160912.GA18790@fieldses.org> <10B234E0D3A1CA469E00963BF106CA392D0DB78354@NOK-EUMSG-02.mgdnok.nokia.com> <20100827210626.GB27694@fieldses.org> <20100827212842.GC27694@fieldses.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Cc: "Artem.Bityutskiy@nokia.com" , "bjschuma@netapp.com" , "linux-nfs@vger.kernel.org" , "trond@netapp.com" , "hch@lst.de" To: "J. Bruce Fields" Return-path: Received: from 0122700014.0.fullrate.dk ([95.166.99.235]:44375 "EHLO kernel.dk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751720Ab0H1Guq (ORCPT ); Sat, 28 Aug 2010 02:50:46 -0400 In-Reply-To: <20100827212842.GC27694@fieldses.org> Sender: linux-nfs-owner@vger.kernel.org List-ID: On 08/27/2010 11:28 PM, J. Bruce Fields wrote: > From: J. Bruce Fields > > Setting the task state here may cause us to miss the wake up from > kthread_stop(), so we need to recheck kthread_should_stop() or risk > sleeping forever in the following schedule(). > > Symptom was an indefinite hang on an NFSv4 mount. (NFSv4 may create > multiple mounts in a temporary namespace while traversing the mount > path, and since the temporary namespace is immediately destroyed, it may > end up destroying a mount very soon after it was created, possibly > making this race more likely.) > > INFO: task mount.nfs4:4314 blocked for more than 120 seconds. > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > mount.nfs4 D 0000000000000000 2880 4314 4313 0x00000000 > ffff88001ed6da28 0000000000000046 ffff88001ed6dfd8 ffff88001ed6dfd8 > ffff88001ed6c000 ffff88001ed6c000 ffff88001ed6c000 ffff88001e5003a0 > ffff88001ed6dfd8 ffff88001e5003a8 ffff88001ed6c000 ffff88001ed6dfd8 > Call Trace: > [] schedule_timeout+0x1cd/0x2e0 > [] ? mark_held_locks+0x6c/0xa0 > [] ? _raw_spin_unlock_irq+0x30/0x60 > [] ? trace_hardirqs_on_caller+0x14d/0x190 > [] ? sub_preempt_count+0xe/0xd0 > [] wait_for_common+0x120/0x190 > [] ? default_wake_function+0x0/0x20 > [] wait_for_completion+0x1d/0x20 > [] kthread_stop+0x4a/0x150 > [] ? thaw_process+0x70/0x80 > [] bdi_unregister+0x10a/0x1a0 > [] nfs_put_super+0x19/0x20 > [] generic_shutdown_super+0x54/0xe0 > [] kill_anon_super+0x16/0x60 > [] nfs4_kill_super+0x39/0x90 > [] deactivate_locked_super+0x45/0x60 > [] deactivate_super+0x49/0x70 > [] mntput_no_expire+0x84/0xe0 > [] release_mounts+0x9f/0xc0 > [] put_mnt_ns+0x65/0x80 > [] nfs_follow_remote_path+0x1e6/0x420 > [] nfs4_try_mount+0x6f/0xd0 > [] nfs4_get_sb+0xa2/0x360 > [] vfs_kern_mount+0x88/0x1f0 > [] do_kern_mount+0x52/0x130 > [] ? _lock_kernel+0x6a/0x170 > [] do_mount+0x26e/0x7f0 > [] ? copy_mount_options+0xea/0x190 > [] sys_mount+0x98/0xf0 > [] system_call_fastpath+0x16/0x1b > 1 lock held by mount.nfs4/4314: > #0: (&type->s_umount_key#24){+.+...}, at: [] deactivate_super+0x41/0x70 > > Signed-off-by: J. Bruce Fields > --- > fs/fs-writeback.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > On Fri, Aug 27, 2010 at 05:06:26PM -0400, J. Bruce Fields wrote: >> Maybe the following? > > I confirmed that my hang does go away after doing this. > > Please apply if you think this makes sense.... > > diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c > index 7d9d06b..81e086d 100644 > --- a/fs/fs-writeback.c > +++ b/fs/fs-writeback.c > @@ -808,7 +808,7 @@ int bdi_writeback_thread(void *data) > wb->last_active = jiffies; > > set_current_state(TASK_INTERRUPTIBLE); > - if (!list_empty(&bdi->work_list)) { > + if (!list_empty(&bdi->work_list) || kthread_should_stop()) { > __set_current_state(TASK_RUNNING); > continue; > } Thanks Bruce, I've applied this as well. -- Jens Axboe