From patchwork Tue Sep 12 08:45:30 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hou Tao X-Patchwork-Id: 9948613 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 1DE1160360 for ; Tue, 12 Sep 2017 08:40:54 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0D1CB2839C for ; Tue, 12 Sep 2017 08:40:54 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 017332852C; Tue, 12 Sep 2017 08:40:53 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 74C182839C for ; Tue, 12 Sep 2017 08:40:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751247AbdILIkw (ORCPT ); Tue, 12 Sep 2017 04:40:52 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:6454 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751266AbdILIkw (ORCPT ); Tue, 12 Sep 2017 04:40:52 -0400 Received: from 172.30.72.59 (EHLO DGGEMS402-HUB.china.huawei.com) ([172.30.72.59]) by dggrg04-dlp.huawei.com (MOS 4.4.6-GA FastPath queued) with ESMTP id DHB47640; Tue, 12 Sep 2017 16:40:40 +0800 (CST) Received: from huawei.com (10.175.124.28) by DGGEMS402-HUB.china.huawei.com (10.3.19.202) with Microsoft SMTP Server id 14.3.301.0; Tue, 12 Sep 2017 16:40:36 +0800 From: Hou Tao To: CC: Subject: [PATCH v2] xfs: check kthread_should_stop() after the setting of task state Date: Tue, 12 Sep 2017 16:45:30 +0800 Message-ID: <1505205930-2445-1-git-send-email-houtao1@huawei.com> X-Mailer: git-send-email 2.5.0 MIME-Version: 1.0 X-Originating-IP: [10.175.124.28] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59B79D89.0028, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ec40f54c3a1c680a13fff6cfa6260d4d Sender: linux-xfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP A umount hang is possible when a race occurs between the umount process and the xfsaild kthread. The following sequences outline the race: xfsaild: kthread_should_stop() => return false, so xfsaild continue umount: set_bit(KTHREAD_SHOULD_STOP, &kthread->flags) => by kthread_stop() umount: wake_up_process() => because xfsaild is still running, so 0 is returned xfsaild: __set_current_state(TASK_INTERRUPTIBLE) xfsaild: schedule() => now, xfsaild will wait indefinitely umount: wait_for_completion() => and umount will hang To fix that, we need to check kthread_should_stop() after we set the task state, so the xfsaild will either see the stop bit and exit or the task state is reset to runnable by wake_up_process() such that it isn't scheduled out indefinitely and detects the stop bit at the next iteration. Reviewed-by: Christoph Hellwig Reviewed-by: Brian Foster Signed-off-by: Hou Tao --- v2: * comment updates suggested by Brain Foster v1: * http://www.spinics.net/lists/linux-xfs/msg10285.html --- fs/xfs/xfs_trans_ail.c | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/fs/xfs/xfs_trans_ail.c b/fs/xfs/xfs_trans_ail.c index 9056c0f..2d77d9c 100644 --- a/fs/xfs/xfs_trans_ail.c +++ b/fs/xfs/xfs_trans_ail.c @@ -499,11 +499,26 @@ xfsaild( current->flags |= PF_MEMALLOC; set_freezable(); - while (!kthread_should_stop()) { + while (1) { if (tout && tout <= 20) - __set_current_state(TASK_KILLABLE); + set_current_state(TASK_KILLABLE); else - __set_current_state(TASK_INTERRUPTIBLE); + set_current_state(TASK_INTERRUPTIBLE); + + /* + * Check kthread_should_stop() after we set the task state + * to guarantee that we either see the stop bit and exit or + * the task state is reset to runnable such that it's not + * scheduled out indefinitely and detects the stop bit at + * next iteration. + * + * A memory barrier is included in above task state set to + * serialize again kthread_stop(). + */ + if (kthread_should_stop()) { + __set_current_state(TASK_RUNNING); + break; + } spin_lock(&ailp->xa_lock);