Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp1058836pxb; Wed, 6 Oct 2021 23:10:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzCFsJmwyhE38Kh1gimMm+aLWjlFYzKPK10wcpSX2eNS39YhdKjnIwfEzNapgvne2MBF7dq X-Received: by 2002:a17:906:269a:: with SMTP id t26mr3474531ejc.20.1633587020069; Wed, 06 Oct 2021 23:10:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633587020; cv=none; d=google.com; s=arc-20160816; b=gLY2KqiMZ07hKko3jDfiP7xtJ0qR0jVcdwYJhzZo9lPPAJ0InnzDZkyP/qPOC7GDr9 wVtQs400IZ3tmR3NJRkalamGGAKEG+glQCoTDWjXgJivvyiLzLl0NuK2cE3uD2PBpizj nrx3Ch1ghanR0uY3qbVVMjaR6GrRJVmcsUjwwbtzeY7SuwkkgcAg/2n6D/MrNB1yoyVQ QqNnpL1V/EJHKpaqOg6lJtA6l2pCOdxWl9wrDKw5fNTbp8a1VYSy97Rw+mCjjXis9pmx u+sRExiDKcVCOgiUZ4M9z3zuvX3y2xz7xl+gUzmK9eh11LCk5WiNij0ypwoxCUaCpbN6 jB3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:subject:user-agent:mime-version:date:message-id; bh=awLDpR2/FlfIkUEug//WdP4l1xSiO/+molQkWJzhA50=; b=jf0BYA/0RP7j8W/1pLbViuTdqogNlyMVAm2jZQh7leuZerKE7JI5IAoBBsuRUE4gUr 23HmPYFkZiuZXRlwB/6ERQyBOOPywRiZ4J5EVJ05bSjYICAIB/1mb/hr15I2k1tK0PQS 6dyhSkgvWVkPxVtNkwyVgsboVP5+FnsROa7au4j0VUGIvxhe6cgLX5yUjh3E2el67B0L Hny9Mbae0EYu44z70IRhsc3vMOwqAyYiPuO6dp6BOHWEA+hBZIXtDEdJzR/IoMR2P5+C zLu0I9SagTCHxufM8uYnF+fAm1SnhNHrqU1O3KRSeHQVUdVgFZSVlJ4RO3zBKZ6oKWBu oa9w== 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 c4si25997716ejc.492.2021.10.06.23.09.55; Wed, 06 Oct 2021 23:10:20 -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 S232711AbhJGGKB (ORCPT + 99 others); Thu, 7 Oct 2021 02:10:01 -0400 Received: from n169-114.mail.139.com ([120.232.169.114]:9964 "EHLO n169-114.mail.139.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229497AbhJGGKB (ORCPT ); Thu, 7 Oct 2021 02:10:01 -0400 X-RM-TagInfo: emlType=0 X-RM-SPAM: X-RM-SPAM-FLAG: 00000000 Received: from [192.168.255.10] (unknown[116.30.194.209]) by rmsmtp-lg-appmail-37-12051 (RichMail) with SMTP id 2f13615e8ec1772-7b31d; Thu, 07 Oct 2021 14:08:05 +0800 (CST) X-RM-TRANSID: 2f13615e8ec1772-7b31d Message-ID: Date: Thu, 7 Oct 2021 14:08:03 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.1.2 Subject: Re: [RFC PATCH v5 03/10] ovl: implement overlayfs' ->evict_inode operation To: Miklos Szeredi , Chengguang Xu Cc: Jan Kara , Amir Goldstein , linux-fsdevel@vger.kernel.org, overlayfs , linux-kernel@vger.kernel.org References: <20210923130814.140814-1-cgxu519@mykernel.net> <20210923130814.140814-4-cgxu519@mykernel.net> From: Chengguang Xu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2021/10/6 23:33, Miklos Szeredi 写道: > On Thu, 23 Sept 2021 at 15:08, Chengguang Xu wrote: >> Implement overlayfs' ->evict_inode operation, >> so that we can clear dirty flags of overlayfs inode. >> >> Signed-off-by: Chengguang Xu >> --- >> fs/overlayfs/super.c | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c >> index 51886ba6130a..2ab77adf7256 100644 >> --- a/fs/overlayfs/super.c >> +++ b/fs/overlayfs/super.c >> @@ -406,11 +406,18 @@ static int ovl_remount(struct super_block *sb, int *flags, char *data) >> return ret; >> } >> >> +static void ovl_evict_inode(struct inode *inode) >> +{ >> + inode->i_state &= ~I_DIRTY_ALL; >> + clear_inode(inode); > clear_inode() should already clear the dirty flags; the default > eviction should work fine without having to define an ->evict_inode. > What am I missing? Yeah, you are right, we don't need overlayfs' own ->evict_inode anymore because we wait all writeback upper inodes in overlayfs' ->sync_fs. Thanks, Chengguang