Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp2809879pxk; Sun, 6 Sep 2020 14:41:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyUBvqtsahGhVr0XYrvMwFk0nDIBusmE8DMEEtds6RwHj08e8EyXFwdcPMij5Epr6M6KG5p X-Received: by 2002:a17:906:c1d7:: with SMTP id bw23mr8215203ejb.171.1599428470825; Sun, 06 Sep 2020 14:41:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599428470; cv=none; d=google.com; s=arc-20160816; b=PTxvHkBYSs/cNCk+2q6LUc6ScbC/RBRQfSdJHamEV7ateXSWIjtDSfWdaL0d1+sHQQ EEhKu8YohGAhg1AuZrRR7DPyqG+erotueNQNmKjfU3mGjvbL0l+Y5w45wazRbXsk3lsO RBHGIlC+NLCh5979FmCJ4zDBrBlkc/eHobn4IfCtf2rvb1E4HuxzBh3p31ZZuplO6GWl wzGxWv8tXdLiKiLFgE0ikw3MDjGyAmqYtGIP9YqnAtku5OFlADtvQB5+2SZU/Dwxw4KG JUoDBK91z2cdxTb2kvfJweQaHptb7YwFapknPUjGlLN0DtyHgRZV1Om4Zi263qXwQjMx YfUw== 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=ZJRfOnAP/3nz2eLsCJNGEn6Z2Y3shQB4HS6UkMySDtA=; b=eMxf4QXrkKv3/SEbt6eomuDP4i8eQDyZzvHmqFPKoYHgyGCO/XVcmzJwcUpp7W3lUZ fX6Lkn4r86T9QbwLRJa17nvrN2zk2Q3wjp6rx3hxyahhPt6fNaPK2LPxhbEuG7uqldxP 1n9RczeDSF69Pf2w3oMC/q1xGm8ksspvY8pK+ttETrpE03Ncfsr22bwF1wcZ+28S7rYe 128ZqSxP2LfJ/XTriC6SgfzP59XCRgZTKbAWoWc6BGK4cp9EYNSJHbENkoGIxS0fhBY1 ilypaUuuBs3k+2KzEGGIQeQStsw7TO8NS6c0qgh3b8N4gOkNmby+FUd2GwIJaYs5V8vh 3F/A== 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 r11si8933628eju.461.2020.09.06.14.40.48; Sun, 06 Sep 2020 14:41:10 -0700 (PDT) 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 S1726596AbgIFVkK (ORCPT + 99 others); Sun, 6 Sep 2020 17:40:10 -0400 Received: from mail104.syd.optusnet.com.au ([211.29.132.246]:33116 "EHLO mail104.syd.optusnet.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726292AbgIFVkJ (ORCPT ); Sun, 6 Sep 2020 17:40:09 -0400 Received: from dread.disaster.area (pa49-195-191-192.pa.nsw.optusnet.com.au [49.195.191.192]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id DC6FE824631; Mon, 7 Sep 2020 07:40:03 +1000 (AEST) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1kF2OI-0006n6-R9; Mon, 07 Sep 2020 07:40:02 +1000 Date: Mon, 7 Sep 2020 07:40:02 +1000 From: Dave Chinner To: Hao Li Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, ira.weiny@intel.com, linux-xfs@vger.kernel.org, y-goto@fujitsu.com Subject: Re: [PATCH v2] fs: Handle I_DONTCACHE in iput_final() instead of generic_drop_inode() Message-ID: <20200906214002.GI12131@dread.disaster.area> References: <20200904075939.176366-1-lihao2018.fnst@cn.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200904075939.176366-1-lihao2018.fnst@cn.fujitsu.com> X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.3 cv=IuRgj43g c=1 sm=1 tr=0 cx=a_idp_d a=vvDRHhr1aDYKXl+H6jx2TA==:117 a=vvDRHhr1aDYKXl+H6jx2TA==:17 a=kj9zAlcOel0A:10 a=reM5J-MqmosA:10 a=VwQbUJbxAAAA:8 a=omOdbC7AAAAA:8 a=20KFwNOVAAAA:8 a=7-415B0cAAAA:8 a=CYq8bQpZl3HkxBxCX-sA:9 a=CjuIK1q_8ugA:10 a=AjGcO6oz07-iQ99wixmX:22 a=baC4JDFNLZpnPwus_NF9:22 a=biEYGPWJfzWAr4FL6Ov7:22 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 04, 2020 at 03:59:39PM +0800, Hao Li wrote: > If generic_drop_inode() returns true, it means iput_final() can evict > this inode regardless of whether it is dirty or not. If we check > I_DONTCACHE in generic_drop_inode(), any inode with this bit set will be > evicted unconditionally. This is not the desired behavior because > I_DONTCACHE only means the inode shouldn't be cached on the LRU list. > As for whether we need to evict this inode, this is what > generic_drop_inode() should do. This patch corrects the usage of > I_DONTCACHE. > > This patch was proposed in [1]. > > [1]: https://lore.kernel.org/linux-fsdevel/20200831003407.GE12096@dread.disaster.area/ > > Fixes: dae2f8ed7992 ("fs: Lift XFS_IDONTCACHE to the VFS layer") > Signed-off-by: Hao Li > --- > Changes in v2: > - Adjust code format > - Add Fixes tag in commit message > > fs/inode.c | 4 +++- > include/linux/fs.h | 3 +-- > 2 files changed, 4 insertions(+), 3 deletions(-) Looks good. Reviewed-by: Dave Chinner -- Dave Chinner david@fromorbit.com