Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp2326001pxb; Mon, 11 Jan 2021 06:59:47 -0800 (PST) X-Google-Smtp-Source: ABdhPJxBbYnCbqksEJb3EvW/NnZUo4wwX3vxXBAopOXVbgxLTnyZFesGTpKROPph+K0qW09lXnMN X-Received: by 2002:a17:906:3b5b:: with SMTP id h27mr10849608ejf.450.1610377187071; Mon, 11 Jan 2021 06:59:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610377187; cv=none; d=google.com; s=arc-20160816; b=FdIYZ/n68+3IVwMYHl0kQWMSDm4ouBczWfShicran/HjRpTZHSZ9ZdaNm85mLNcgTE Bh47AdEzXcZJ4LGH2l5MsJnN4NF7zYYDBFh6uImkcQKnN3Gw1uH4iQab62ENBzqwEzpp Th5AllErk+pfBOIwOP34Vy2FdK+Pqah+Xazt9VKdKIl55/5sssPXZMqkYUjwqbRbnbRt YOpGtj/hxCB3Vl+4o+q7+WAafvtEL/uF7cYIBgAYET+K50zqK2IJCr6N5ru4aCW3joIg +S1xnS1+FKYhcwSLaMYNasG/+PrFhBiCv0gxRQO7dqp3Zp+QbD9btPn44cOI+31m/eIz 0AZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=mTyPu1oC57DyrwwxbFI3SBe8IX9Y1EAFmsQu2J7+b24=; b=dV95q7Y/E3rKA8lIbfJ8daRbp6NqstLFAzBXeFxLJiAXLKzRcA4gBWr1fw9q5ud0/2 ED9vFfGLm5X2Wpr+dS/QiNmIeFsd69r7zssso+1Bf7swM4w/Uda3TkQXgduZjKpskbd+ yqW5WQm2Nl+22mkQwqj57Npy+eGDK5TzDAo4eGX1i8n8qyDPtJmi3584HRtkatAUdq5A e4jvlvyHHQQl7FapLOunFCIv2VKRnpteyAWfV7wgcowKmwA9KwmzQTJvMVrwXuaVx6mW nV+GYm1C+ULa6ldbXLGtqAyM1UALNrxHFh5xX5qLO3+l45Db+kcPcjkaD8cgORFi6me4 B4rw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-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 k26si6481066ejc.545.2021.01.11.06.59.22; Mon, 11 Jan 2021 06:59:47 -0800 (PST) Received-SPF: pass (google.com: domain of linux-ext4-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-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731604AbhAKO5P (ORCPT + 99 others); Mon, 11 Jan 2021 09:57:15 -0500 Received: from mx2.suse.de ([195.135.220.15]:39526 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727750AbhAKO5P (ORCPT ); Mon, 11 Jan 2021 09:57:15 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id C1EF4AD1E; Mon, 11 Jan 2021 14:56:33 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 967771E0807; Mon, 11 Jan 2021 15:56:33 +0100 (CET) Date: Mon, 11 Jan 2021 15:56:33 +0100 From: Jan Kara To: Eric Biggers Cc: linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, Theodore Ts'o , Christoph Hellwig Subject: Re: [PATCH v2 06/12] fs: pass only I_DIRTY_INODE flags to ->dirty_inode Message-ID: <20210111145633.GE18475@quack2.suse.cz> References: <20210109075903.208222-1-ebiggers@kernel.org> <20210109075903.208222-7-ebiggers@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210109075903.208222-7-ebiggers@kernel.org> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Fri 08-01-21 23:58:57, Eric Biggers wrote: > From: Eric Biggers > > ->dirty_inode is now only called when I_DIRTY_INODE (I_DIRTY_SYNC and/or > I_DIRTY_DATASYNC) is set. However it may still be passed other dirty > flags at the same time, provided that these other flags happened to be > passed to __mark_inode_dirty() at the same time as I_DIRTY_INODE. > > This doesn't make sense because there is no reason for filesystems to > care about these extra flags. Nor are filesystems notified about all > updates to these other flags. > > Therefore, mask the flags before passing them to ->dirty_inode. > > Also properly document ->dirty_inode in vfs.rst. > > Reviewed-by: Christoph Hellwig > Signed-off-by: Eric Biggers Looks good to me. Feel free to add: Reviewed-by: Jan Kara Honza > --- > Documentation/filesystems/vfs.rst | 5 ++++- > fs/fs-writeback.c | 2 +- > 2 files changed, 5 insertions(+), 2 deletions(-) > > diff --git a/Documentation/filesystems/vfs.rst b/Documentation/filesystems/vfs.rst > index ca52c82e5bb54..287b80948a40b 100644 > --- a/Documentation/filesystems/vfs.rst > +++ b/Documentation/filesystems/vfs.rst > @@ -270,7 +270,10 @@ or bottom half). > ->alloc_inode. > > ``dirty_inode`` > - this method is called by the VFS to mark an inode dirty. > + this method is called by the VFS when an inode is marked dirty. > + This is specifically for the inode itself being marked dirty, > + not its data. If the update needs to be persisted by fdatasync(), > + then I_DIRTY_DATASYNC will be set in the flags argument. > > ``write_inode`` > this method is called when the VFS needs to write an inode to > diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c > index b7616bbd55336..2e6064012f7d3 100644 > --- a/fs/fs-writeback.c > +++ b/fs/fs-writeback.c > @@ -2259,7 +2259,7 @@ void __mark_inode_dirty(struct inode *inode, int flags) > trace_writeback_dirty_inode_start(inode, flags); > > if (sb->s_op->dirty_inode) > - sb->s_op->dirty_inode(inode, flags); > + sb->s_op->dirty_inode(inode, flags & I_DIRTY_INODE); > > trace_writeback_dirty_inode(inode, flags); > > -- > 2.30.0 > -- Jan Kara SUSE Labs, CR