From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 32B50C169C4 for ; Wed, 30 Jan 2019 00:56:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EDC4B2082E for ; Wed, 30 Jan 2019 00:56:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727360AbfA3A4i (ORCPT ); Tue, 29 Jan 2019 19:56:38 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:38444 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727244AbfA3A4i (ORCPT ); Tue, 29 Jan 2019 19:56:38 -0500 Received: from akpm3.svl.corp.google.com (unknown [104.133.8.65]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 38E1D359D; Wed, 30 Jan 2019 00:56:37 +0000 (UTC) Date: Tue, 29 Jan 2019 16:56:36 -0800 From: Andrew Morton To: Jan Kara Cc: Al Viro , , Subject: Re: [PATCH] vfs: Avoid softlockups in drop_pagecache_sb() Message-Id: <20190129165636.34a1dc779efdbb9eff4bcf8b@linux-foundation.org> In-Reply-To: <20190114085343.15011-1-jack@suse.cz> References: <20190114085343.15011-1-jack@suse.cz> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Mon, 14 Jan 2019 09:53:43 +0100 Jan Kara wrote: > When superblock has lots of inodes without any pagecache (like is the > case for /proc), drop_pagecache_sb() will iterate through all of them > without dropping sb->s_inode_list_lock which can lead to softlockups > (one of our customers hit this). > > Fix the problem by going to the slow path and doing cond_resched() in > case the process needs rescheduling. > > ... > > --- a/fs/drop_caches.c > +++ b/fs/drop_caches.c > @@ -21,8 +21,13 @@ static void drop_pagecache_sb(struct super_block *sb, void *unused) > spin_lock(&sb->s_inode_list_lock); > list_for_each_entry(inode, &sb->s_inodes, i_sb_list) { > spin_lock(&inode->i_lock); > + /* > + * We must skip inodes in unusual state. We may also skip > + * inodes without pages but we deliberately won't in case > + * we need to reschedule to avoid softlockups. > + */ > if ((inode->i_state & (I_FREEING|I_WILL_FREE|I_NEW)) || > - (inode->i_mapping->nrpages == 0)) { > + (inode->i_mapping->nrpages == 0 && !need_resched())) { > spin_unlock(&inode->i_lock); > continue; > } > @@ -30,6 +35,7 @@ static void drop_pagecache_sb(struct super_block *sb, void *unused) > spin_unlock(&inode->i_lock); > spin_unlock(&sb->s_inode_list_lock); > > + cond_resched(); > invalidate_mapping_pages(inode->i_mapping, 0, -1); > iput(toput_inode); > toput_inode = inode; Are we sure there's no situation in which a large number of inodes can be in the "unusual state", leading to the same issue?