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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 8A85BC4360C for ; Sat, 12 Oct 2019 04:30:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5E03C21929 for ; Sat, 12 Oct 2019 04:30:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726787AbfJLEaB (ORCPT ); Sat, 12 Oct 2019 00:30:01 -0400 Received: from mail104.syd.optusnet.com.au ([211.29.132.246]:55910 "EHLO mail104.syd.optusnet.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725308AbfJLEaB (ORCPT ); Sat, 12 Oct 2019 00:30:01 -0400 Received: from dread.disaster.area (pa49-181-198-88.pa.nsw.optusnet.com.au [49.181.198.88]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 452B243E9F5; Sat, 12 Oct 2019 15:29:56 +1100 (AEDT) Received: from dave by dread.disaster.area with local (Exim 4.92.2) (envelope-from ) id 1iJ92R-0001HB-Rh; Sat, 12 Oct 2019 15:29:55 +1100 Date: Sat, 12 Oct 2019 15:29:55 +1100 From: Dave Chinner To: Eric Sandeen Cc: Eric Sandeen , Matthew Wilcox , fsdevel , Jan Kara , Josef Bacik Subject: Re: [PATCH] fs: avoid softlockups in s_inodes iterators Message-ID: <20191012042955.GG15134@dread.disaster.area> References: <841d0e0f-f04c-9611-2eea-0bcc40e5b084@redhat.com> <20191011183253.GV32665@bombadil.infradead.org> <6e67a39c-88ed-f6a9-16a7-6ae9560a1112@redhat.com> <02e4b6c3-1ec8-8adf-93a0-ebf2a7820d65@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02e4b6c3-1ec8-8adf-93a0-ebf2a7820d65@sandeen.net> User-Agent: Mutt/1.10.1 (2018-07-13) X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=P6RKvmIu c=1 sm=1 tr=0 a=ocld+OpnWJCUTqzFQA3oTA==:117 a=ocld+OpnWJCUTqzFQA3oTA==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=XobE76Q3jBoA:10 a=7-415B0cAAAA:8 a=E2jZ3k1vpqApnXpNljMA:9 a=CjuIK1q_8ugA:10 a=biEYGPWJfzWAr4FL6Ov7:22 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Fri, Oct 11, 2019 at 04:14:02PM -0500, Eric Sandeen wrote: > > > On 10/11/19 1:45 PM, Eric Sandeen wrote: > > On 10/11/19 1:32 PM, Matthew Wilcox wrote: > >> On Fri, Oct 11, 2019 at 11:49:38AM -0500, Eric Sandeen wrote: > >>> @@ -698,6 +699,13 @@ int invalidate_inodes(struct super_block *sb, bool kill_dirty) > >>> inode_lru_list_del(inode); > >>> spin_unlock(&inode->i_lock); > >>> list_add(&inode->i_lru, &dispose); > >>> + > >>> + if (need_resched()) { > >>> + spin_unlock(&sb->s_inode_list_lock); > >>> + cond_resched(); > >>> + dispose_list(&dispose); > >>> + goto again; > >>> + } > >>> } > >>> spin_unlock(&sb->s_inode_list_lock); > >>> > >> > >> Is this equivalent to: > >> > >> + cond_resched_lock(&sb->s_inode_list_lock)); > >> > >> or is disposing of the list a crucial part here? > > > > I think we need to dispose, or we'll start with the entire ~unmodified list again after the goto: > > Oh, if you meant in lieu of the goto, we can't drop that lock and > expect to pick up our traversal where we left off, can we? No, we can't. Unless you're doing the iget/iput game (which we can't here!) the moment the s_inode_list_lock is dropped we cannot rely on the inode or it's next pointer to still be valid. Hence we have to restart the traversal. And we dispose of the list before restarting because there's nothing to gain by waiting until we've done the entire sb inode list walk (could be hundreds of millions of inodes) before we start actually freeing them.... Cheers, Dave. -- Dave Chinner david@fromorbit.com