Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp5054323pxb; Wed, 19 Jan 2022 10:04:15 -0800 (PST) X-Google-Smtp-Source: ABdhPJxmnV1V0+YyIwrrA7rsNWU0N0ikO+VXLWfOxecnmRUQ3HF4YCkFcTVRaY2/D+Op73gjRlhe X-Received: by 2002:a63:6bc1:: with SMTP id g184mr2272024pgc.316.1642615455408; Wed, 19 Jan 2022 10:04:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642615455; cv=none; d=google.com; s=arc-20160816; b=neFkBG3XcMOJy/7uw1lccQ0lwQXD8gtZyk38WpV8vbFp3MFWhgvYl87vqZvHNOgrN2 MQLBs1CBG4Ofrj6ET51pitDVw74VU8ze5LtjcnC206/1qj0DelRvEyMrxDiayOS3mG1m 3jfRaEcN5mDqx6emrOzTK27R+g/Yci+lkwPmvYpdxBgkh+vNdZM0KABqbkC1Tt8GeXyn 1+UpXUrJTGwAZxiSyl8V2DMSfqeARyAyIBqfuV+k90SHx422oWiwDDBsFZ+ZEkgXkOkR YIB06dWiEPHFYTpUAzEZaMKoCALyjvoTrvmEMGHlyen3VH6wCMzaJLC5k7yuNeY3eJGk foUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=yxlB54zatrLbeNoItQ078/iBH01TTLh58cdJrbTN9jM=; b=XDDAZLt4g1j9eEuO4LMCaNeEXOQCmOOUZAouVj3Wa2cKDNRNZBP/gXYW2P5JqnBI5/ nfEKlvURco88LYsLm5Q4zgZxYiCmwTJDUdLfOsLgf9OO04Wjs+xpSfsnjp+WrMPp35qK 6ZTK8kcWgI7S90DO5oXHw2jeryfS2QLacF6f6PoxrT3RyTITtnknn2Cv82RgPXTbKLAt zgGjoMi86FgBXSV2zljnIWdeFdeRoCQkdcKYa+TvZwoPR6JFa2eECb2DlEyaruvakB0M 3k/NMEqjciXbCUzgJ3HcYBInXEpnHMl4WT74Wo/84itjWy+RnlQz3J4QSx2ldR+yR/KS joqg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p12si335698plq.95.2022.01.19.10.04.02; Wed, 19 Jan 2022 10:04:15 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350078AbiARDr7 (ORCPT + 99 others); Mon, 17 Jan 2022 22:47:59 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48934 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348788AbiARDpt (ORCPT ); Mon, 17 Jan 2022 22:45:49 -0500 Received: from zeniv-ca.linux.org.uk (zeniv-ca.linux.org.uk [IPv6:2607:5300:60:148a::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CF475C03DD8C; Mon, 17 Jan 2022 19:17:21 -0800 (PST) Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1n9ezh-002iFx-FH; Tue, 18 Jan 2022 03:17:13 +0000 Date: Tue, 18 Jan 2022 03:17:13 +0000 From: Al Viro To: Dave Chinner Cc: Brian Foster , Ian Kent , "Darrick J. Wong" , Christoph Hellwig , Miklos Szeredi , David Howells , Kernel Mailing List , linux-fsdevel , xfs Subject: Re: [PATCH] vfs: check dentry is still valid in get_link() Message-ID: References: <164180589176.86426.501271559065590169.stgit@mickey.themaw.net> <275358741c4ee64b5e4e008d514876ed4ec1071c.camel@themaw.net> <20220118030041.GB59729@dread.disaster.area> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220118030041.GB59729@dread.disaster.area> Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 18, 2022 at 02:00:41PM +1100, Dave Chinner wrote: > > IOW, how far is xfs_inode_mark_reclaimable() from being callable in RCU > > callback context? > > AIUI, not very close at all, > > I'm pretty sure we can't put it under RCU callback context at all > because xfs_fs_destroy_inode() can take sleeping locks, perform > transactions, do IO, run rcu_read_lock() critical sections, etc. > This means that needs to run an a full task context and so can't run > from RCU callback context at all. Umm... AFAICS, this pag = xfs_perag_get(mp, XFS_INO_TO_AGNO(mp, ip->i_ino)); spin_lock(&pag->pag_ici_lock); spin_lock(&ip->i_flags_lock); trace_xfs_inode_set_reclaimable(ip); ip->i_flags &= ~(XFS_NEED_INACTIVE | XFS_INACTIVATING); ip->i_flags |= XFS_IRECLAIMABLE; xfs_perag_set_inode_tag(pag, XFS_INO_TO_AGINO(mp, ip->i_ino), XFS_ICI_RECLAIM_TAG); spin_unlock(&ip->i_flags_lock); spin_unlock(&pag->pag_ici_lock); xfs_perag_put(pag); in the end of xfs_inodegc_set_reclaimable() could go into ->free_inode() just fine. It's xfs_inodegc_queue() I'm not sure about - the part about flush_work() in there... I'm not familiar with that code; could you point me towards some docs/old postings/braindump/whatnot?