Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp102544ybz; Tue, 21 Apr 2020 16:14:32 -0700 (PDT) X-Google-Smtp-Source: APiQypIK20kedRDiHbx/e6W2j6pG7yy72IkrhqSxwfIDMOHoRVb5TbdVrD6TS3kUcSQ59Enixw54 X-Received: by 2002:a17:906:829a:: with SMTP id h26mr22925463ejx.133.1587510872150; Tue, 21 Apr 2020 16:14:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587510872; cv=none; d=google.com; s=arc-20160816; b=xpB++QSmW9jcwaD1VGdA49L5YLrtJBj9vy68H8PMqiVOhNfPVUpfhtS9faKBdiDg4P /B2UOQ0kKxdvqEmbi97pzgm4wJbbcH37ZeWuAsCeU6A9ffs6sfzl8DyFkPQJUfKTsyIe c7F9BDmsEvE0u/Ffg0D/DD7YWz1P7gkFD4qtWTG8i0RlK+47cj3rCUQ9qf8JSasIXKLl GBs5Je7aAv9x7OmjqNvXHk3jkvq4cOtaQ9hNdJE4pHKIGH2mpMGxVigghRBzAmFujsG8 j0h6Gb5EgJ9seJ90u8f8wRNBzbwbIUqJR1gPTY1hVj3vd8jGajo5y0mDsHyPIKQr3sD4 35WQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=EB0pQyohQHL77g4/ophJ/uATQzJP+tzAJtYfO5Tl/Eg=; b=0RGqLJndvbwgyTMjglXwLY7jH8dtDlOWpYW+vcu5e8IDMiwq78l89TOATVJxuU8TMc bUnZ17IU7OAAEGr6HRswn4JUWsmKSEQe3rqBMuim7rHaLdYn+lxMYmwYdi8YJGtQ11UK hbf28nKCKM3HNDOy4MSJhncgbUuRi5S5w1GD9moRDo7HpWtAmWFC7EejVAKP6rwbJVdC VECcO6ARteGKOWBdVIfrLPIv7dgGJOf+Beus8nXB36jV174TnbGpQGln3xg414m4HfU/ D9ffcG7NwoiXbqN9iM+cAXlHexbPaZT3eNh8ye35Jx7+U4PscnP8Zq3Rn17b/BiFrOi6 v3Pg== 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 k7si2294374ejq.480.2020.04.21.16.13.59; Tue, 21 Apr 2020 16:14:32 -0700 (PDT) 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 S1726296AbgDUXNy (ORCPT + 99 others); Tue, 21 Apr 2020 19:13:54 -0400 Received: from mail104.syd.optusnet.com.au ([211.29.132.246]:40640 "EHLO mail104.syd.optusnet.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725822AbgDUXNx (ORCPT ); Tue, 21 Apr 2020 19:13:53 -0400 Received: from dread.disaster.area (pa49-180-0-232.pa.nsw.optusnet.com.au [49.180.0.232]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 25B7E5886E7; Wed, 22 Apr 2020 09:13:45 +1000 (AEST) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1jR25H-0006j2-2b; Wed, 22 Apr 2020 09:13:43 +1000 Date: Wed, 22 Apr 2020 09:13:43 +1000 From: Dave Chinner To: Ira Weiny Cc: "Darrick J. Wong" , linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, Al Viro , Jan Kara , Dan Williams , Christoph Hellwig , "Theodore Y. Ts'o" , Jeff Moyer , linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH V9 10/11] fs/xfs: Update xfs_ioctl_setattr_dax_invalidate() Message-ID: <20200421231343.GD27860@dread.disaster.area> References: <20200421191754.3372370-1-ira.weiny@intel.com> <20200421191754.3372370-11-ira.weiny@intel.com> <20200421203140.GD6742@magnolia> <20200421213049.GC27860@dread.disaster.area> <20200421214328.GD3372712@iweiny-DESK2.sc.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200421214328.GD3372712@iweiny-DESK2.sc.intel.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.3 cv=X6os11be c=1 sm=1 tr=0 a=XYjVcjsg+1UI/cdbgX7I7g==:117 a=XYjVcjsg+1UI/cdbgX7I7g==:17 a=kj9zAlcOel0A:10 a=cl8xLZFz6L8A:10 a=QyXUC8HyAAAA:8 a=7-415B0cAAAA:8 a=TYO8zY9xZc45-t_caPEA:9 a=CjuIK1q_8ugA:10 a=biEYGPWJfzWAr4FL6Ov7:22 Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Tue, Apr 21, 2020 at 02:43:29PM -0700, Ira Weiny wrote: > On Wed, Apr 22, 2020 at 07:30:49AM +1000, Dave Chinner wrote: > > On Tue, Apr 21, 2020 at 01:31:40PM -0700, Darrick J. Wong wrote: > > > On Tue, Apr 21, 2020 at 12:17:52PM -0700, ira.weiny@intel.com wrote: > > > > From: Ira Weiny > > > > > > > > Because of the separation of FS_XFLAG_DAX from S_DAX and the delayed > > > > setting of S_DAX, data invalidation no longer needs to happen when > > > > FS_XFLAG_DAX is changed. > > > > > > > > Change xfs_ioctl_setattr_dax_invalidate() to be > > > > xfs_ioctl_dax_check_set_cache() and alter the code to reflect the new > > > > functionality. > > > > > > > > Furthermore, we no longer need the locking so we remove the join_flags > > > > logic. > > > > > > > > Signed-off-by: Ira Weiny > > > > > > > > --- > > > > Changes from V8: > > > > Change name of function to xfs_ioctl_dax_check_set_cache() > > > > Update commit message > > > > Fix bit manipulations > > > > > > > > Changes from V7: > > > > Use new flag_inode_dontcache() > > > > Skip don't cache if mount over ride is active. > > > > > > > > Changes from v6: > > > > Fix completely broken implementation and update commit message. > > > > Use the new VFS layer I_DONTCACHE to facilitate inode eviction > > > > and S_DAX changing on drop_caches > > > > > > > > Changes from v5: > > > > New patch > > > > --- > > > > fs/xfs/xfs_ioctl.c | 108 +++++++++------------------------------------ > > > > 1 file changed, 20 insertions(+), 88 deletions(-) > > > > > > > > diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c > > > > index 104495ac187c..b87b571a6748 100644 > > > > --- a/fs/xfs/xfs_ioctl.c > > > > +++ b/fs/xfs/xfs_ioctl.c > > > > @@ -1245,64 +1245,26 @@ xfs_ioctl_setattr_xflags( > > > > return 0; > > > > } > > > > > > > > -/* > > > > - * If we are changing DAX flags, we have to ensure the file is clean and any > > > > - * cached objects in the address space are invalidated and removed. This > > > > - * requires us to lock out other IO and page faults similar to a truncate > > > > - * operation. The locks need to be held until the transaction has been committed > > > > - * so that the cache invalidation is atomic with respect to the DAX flag > > > > - * manipulation. > > > > - */ > > > > -static int > > > > -xfs_ioctl_setattr_dax_invalidate( > > > > +static void > > > > +xfs_ioctl_dax_check_set_cache( > > > > > > That's a ... strange name. Set cache on what? > > > > > > Oh, this is the function that sets I_DONTCACHE if an FS_XFLAG_DAX change > > > could have an immediate effect on S_DAX (assuming no other users). What > > > do you think of the following? > > > > > > /* > > > * If a change to FS_XFLAG_DAX will result in an change to S_DAX > > > * the next time the incore inode is initialized, set the VFS > > > * I_DONTCACHE flag to try to hurry that along. > > > */ > > > static void > > > xfs_ioctl_try_change_vfs_dax(...) > > > > That doesn't seem any better. This is a preparation function now, in > > that it can't fail and doesn't change the outcome of the operation > > being performed. So, IMO, calling it something like > > xfs_ioctl_setattr_prepare_dax() would be a better name for it. > > But it does potentially (after a check) set I_DONTCACHE. That is an implementation detail - it doesn't change the outcome of the function, the current behaviour of the inode, or the result of the ioctl.... > What about? > > xfs_ioctl_dax_check_set_dontcache()? Then we have to rename it again the moment we change it's functionality. i.e. we have exactly the same problem we have now where the function name describes the implementation, not the operational reason the function is being called... Cheers, Dave. -- Dave Chinner david@fromorbit.com