From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751669AbdF2Wsr (ORCPT ); Thu, 29 Jun 2017 18:48:47 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:41430 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751579AbdF2Wsq (ORCPT ); Thu, 29 Jun 2017 18:48:46 -0400 Date: Thu, 29 Jun 2017 15:48:28 -0700 From: Andrew Morton To: Sahitya Tummala Cc: Alexander Polakov , Vladimir Davydov , Jan Kara , viro@zeniv.linux.org.uk, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v4 2/2] fs/dcache.c: fix spin lockup issue on nlru->lock Message-Id: <20170629154828.5b4877348470c42352620f41@linux-foundation.org> In-Reply-To: <1498707575-2472-1-git-send-email-stummala@codeaurora.org> References: <20170628171854.t4sjyjv55j673qzv@esperanza> <1498707575-2472-1-git-send-email-stummala@codeaurora.org> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 29 Jun 2017 09:09:35 +0530 Sahitya Tummala wrote: > __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 - > > ... > > 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. > > ... > > --- 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); I'll add a cc:stable to this one - a large dentry list is a relatively common thing. I'm assumng that [1/2] does not need to be backported, OK? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 29 Jun 2017 15:48:28 -0700 From: Andrew Morton To: Sahitya Tummala Cc: Alexander Polakov , Vladimir Davydov , Jan Kara , viro@zeniv.linux.org.uk, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v4 2/2] fs/dcache.c: fix spin lockup issue on nlru->lock Message-Id: <20170629154828.5b4877348470c42352620f41@linux-foundation.org> In-Reply-To: <1498707575-2472-1-git-send-email-stummala@codeaurora.org> References: <20170628171854.t4sjyjv55j673qzv@esperanza> <1498707575-2472-1-git-send-email-stummala@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: On Thu, 29 Jun 2017 09:09:35 +0530 Sahitya Tummala wrote: > __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 - > > ... > > 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. > > ... > > --- 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); I'll add a cc:stable to this one - a large dentry list is a relatively common thing. I'm assumng that [1/2] does not need to be backported, OK? -- 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