From patchwork Wed Jun 21 06:39:15 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sahitya Tummala X-Patchwork-Id: 9800873 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 DFEF9601C0 for ; Wed, 21 Jun 2017 06:39:48 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D029D26E49 for ; Wed, 21 Jun 2017 06:39:48 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id C47E92853C; Wed, 21 Jun 2017 06:39:48 +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.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=unavailable 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 7240F26E49 for ; Wed, 21 Jun 2017 06:39:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751120AbdFUGjg (ORCPT ); Wed, 21 Jun 2017 02:39:36 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:36036 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751069AbdFUGjf (ORCPT ); Wed, 21 Jun 2017 02:39:35 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 963F560996; Wed, 21 Jun 2017 06:39:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1498027174; bh=XK8gZ6e2E8iGkwOA/fm6+GTnWmdowvTtSJ1dc3CYJf0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bL7iz6G0CR988+jUDKnDDoU8a0AuODpVbyh8RDkt9YJ0jr+YAHf3/GiIqkUJiAEUC ifZMqePiejpesjv4mZCemQrj6K3lwYmk+zIeskW3Fe1RPhKbi8nCCkpBYZMj21oBWW 74aR9uJrwEsSDWN8mjNQd2zI1EEeoc3ZTTUEiHL4= Received: from codeaurora.org (blr-c-bdr-fw-01_globalnat_allzones-outside.qualcomm.com [103.229.19.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: stummala@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id A2DBE60867; Wed, 21 Jun 2017 06:39:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1498027173; bh=XK8gZ6e2E8iGkwOA/fm6+GTnWmdowvTtSJ1dc3CYJf0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LM9Nx/gxYLZ/awp5thjpciRQfQjPZypPtjlOsOoqTKHeIFw7qVgHCLZR6hWIflj/C PKB6nX1TNsG5lUpWfy9r005afhJEFR9aTL8tRNze0lOZ+pmRAJtPgNNilIOpjwMgyI JkCpGPgRoEWES9MJhdRRd7lEJW5aWYE2LVBZc5ok= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org A2DBE60867 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=stummala@codeaurora.org From: Sahitya Tummala To: Alexander Polakov , Andrew Morton , Vladimir Davydov , Jan Kara , viro@zeniv.linux.org.uk, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: Sahitya Tummala Subject: [PATCH v2] fs/dcache.c: fix spin lockup issue on nlru->lock Date: Wed, 21 Jun 2017 12:09:15 +0530 Message-Id: <1498027155-4456-1-git-send-email-stummala@codeaurora.org> X-Mailer: git-send-email 1.9.1 In-Reply-To: <6ab790fe-de97-9495-0d3b-804bae5d7fbb@codeaurora.org> References: <6ab790fe-de97-9495-0d3b-804bae5d7fbb@codeaurora.org> Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP __list_lru_walk_one() acquires nlru spin lock (nlru->lock) for longer duration if there are more number of items in the lru list. As per the current code, it can hold the spin lock for upto maximum UINT_MAX entries at a time. So if there are more number of items in the lru list, then "BUG: spinlock lockup suspected" is observed in the below path - [] spin_bug+0x90 [] do_raw_spin_lock+0xfc [] _raw_spin_lock+0x28 [] list_lru_add+0x28 [] dput+0x1c8 [] path_put+0x20 [] terminate_walk+0x3c [] path_lookupat+0x100 [] filename_lookup+0x6c [] user_path_at_empty+0x54 [] SyS_faccessat+0xd0 [] el0_svc_naked+0x24 This nlru->lock is acquired by another CPU in this path - [] d_lru_shrink_move+0x34 [] dentry_lru_isolate_shrink+0x48 [] __list_lru_walk_one.isra.10+0x94 [] list_lru_walk_node+0x40 [] shrink_dcache_sb+0x60 [] do_remount_sb+0xbc [] do_emergency_remount+0xb0 [] process_one_work+0x228 [] worker_thread+0x2e0 [] kthread+0xf4 [] ret_from_fork+0x10 Fix this lockup by reducing the number of entries to be shrinked from the lru list to 1024 at once. Also, add cond_resched() before processing the lru list again. Link: http://marc.info/?t=149722864900001&r=1&w=2 Fix-suggested-by: Jan kara Fix-suggested-by: Vladimir Davydov Signed-off-by: Sahitya Tummala --- v2: patch shrink_dcache_sb() instead of list_lru_walk() --- fs/dcache.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/dcache.c b/fs/dcache.c index cddf397..c8ca150 100644 --- a/fs/dcache.c +++ b/fs/dcache.c @@ -1133,10 +1133,11 @@ void shrink_dcache_sb(struct super_block *sb) LIST_HEAD(dispose); freed = list_lru_walk(&sb->s_dentry_lru, - dentry_lru_isolate_shrink, &dispose, UINT_MAX); + dentry_lru_isolate_shrink, &dispose, 1024); this_cpu_sub(nr_dentry_unused, freed); shrink_dentry_list(&dispose); + cond_resched(); } while (freed > 0); } EXPORT_SYMBOL(shrink_dcache_sb);