From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f72.google.com (mail-oi0-f72.google.com [209.85.218.72]) by kanga.kvack.org (Postfix) with ESMTP id 120482802FE for ; Wed, 28 Jun 2017 23:39:49 -0400 (EDT) Received: by mail-oi0-f72.google.com with SMTP id c189so20514289oia.13 for ; Wed, 28 Jun 2017 20:39:49 -0700 (PDT) Received: from smtp.codeaurora.org (smtp.codeaurora.org. [198.145.29.96]) by mx.google.com with ESMTPS id u4si2720048oig.391.2017.06.28.20.39.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jun 2017 20:39:48 -0700 (PDT) From: Sahitya Tummala Subject: [PATCH v4 2/2] fs/dcache.c: fix spin lockup issue on nlru->lock Date: Thu, 29 Jun 2017 09:09:35 +0530 Message-Id: <1498707575-2472-1-git-send-email-stummala@codeaurora.org> In-Reply-To: <20170628171854.t4sjyjv55j673qzv@esperanza> References: <20170628171854.t4sjyjv55j673qzv@esperanza> Sender: owner-linux-mm@kvack.org List-ID: 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 __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 --- fs/dcache.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/dcache.c b/fs/dcache.c index a9f995f..1161390 100644 --- a/fs/dcache.c +++ b/fs/dcache.c @@ -1133,11 +1133,12 @@ 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); - } while (freed > 0); + cond_resched(); + } while (list_lru_count(&sb->s_dentry_lru) > 0); } EXPORT_SYMBOL(shrink_dcache_sb); -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org