linux-kernel - Re: [PATCH v2] fs: Handle I_DONTCACHE in iput_final() instead of generic_drop

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200906214002.GI12131@dread.disaster.area>
Date:   Mon, 7 Sep 2020 07:40:02 +1000
From:   Dave Chinner <david@...morbit.com>
To:     Hao Li <lihao2018.fnst@...fujitsu.com>
Cc:     linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        ira.weiny@...el.com, linux-xfs@...r.kernel.org, y-goto@...itsu.com
Subject: Re: [PATCH v2] fs: Handle I_DONTCACHE in iput_final() instead of
 generic_drop_inode()

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 <lihao2018.fnst@...fujitsu.com>
> ---
> 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 <dchinner@...hat.com>

-- 
Dave Chinner
david@...morbit.com