Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp3906805ybz; Mon, 20 Apr 2020 11:37:15 -0700 (PDT) X-Google-Smtp-Source: APiQypJV2dcn+WjeZ5kUemXHUecOfSYnVXIPpHNZKxIqtQB9CzvzCuc2+sq/BZ2ICNXEGgGLl5Uu X-Received: by 2002:aa7:df0a:: with SMTP id c10mr14882994edy.306.1587407835036; Mon, 20 Apr 2020 11:37:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587407835; cv=none; d=google.com; s=arc-20160816; b=ZlZynr5Qg3dEPuOGolu3aAMjbLa2ybQ4HWeGmsFMMEJ7knJbMvzPKqwrGUXxc4hyS3 kyAG3W1F0Py1cxZvSWokvuGIf02/2YlIIOBrZjZEJA9HAjc4Kx3h7l9G9U7y5Tu9MiE6 VKMbE5OYxuevvba+stEkuSiKw6NVv/0Ir1hmglO4Cwr+ZHzupYqTXSzvPfbDG/Y+kWI4 e4a+1RTqoS4D8JESMKJeTFBzLFLSmfYoSvOZM/eS31U+WMLmENPY9D5DIU6ZWGkMgCj2 /Mi2XJRcbzX+KTDh4ieYUWgT6Eh3sHOPChmSeAAM7dZfPdjAA4jWwe7Lpx9uPkQFUCqV cUFw== 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:ironport-sdr:ironport-sdr; bh=W5C1YRoB24yl8V0G+k3w4/51KCEHKd+kHI1JQ3lNgw0=; b=NiGwY1nBZALzm2gTSWh+4NMBR91iRXH/S+at8Lm/hIwQlPrlJr+JwxlT6oetYIs9na 1NBkBbxbzXk+bDADlNLnoPjyqDfUA9K5cWEhn5T0Pf2UKEQvDTE6+2r+bp4sKPkO3gLy UGsDbNmU3LVqsDzlze+7zQFNbtsy7YbNoQEzDc5oEO4cgDApl2un3zWkMA8jXbPHC1LX 58WBjm8yA08rK8VApxHxXel/aHywb6o2HKboYKxsrGJNeZNDFzX/vGSXQOsw9yMxu5/H 55JAfcPvc6HPj9+0vUBRQR2KuRYhetILdFY2tlTd+H8QsRkt8TrubN4Reavd8sx5HzBH Tjag== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e3si52440ejb.68.2020.04.20.11.36.41; Mon, 20 Apr 2020 11:37:14 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727902AbgDTSgS (ORCPT + 99 others); Mon, 20 Apr 2020 14:36:18 -0400 Received: from mga04.intel.com ([192.55.52.120]:64767 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726748AbgDTSgS (ORCPT ); Mon, 20 Apr 2020 14:36:18 -0400 IronPort-SDR: che0hdkKvtNRSdz+JVniPR8QkXdeh2y+lifisLa3jDp/25bPy/S2cNyYfAkosO+Msyr2GLeVAK Nm9b3S2VZLaQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2020 11:36:18 -0700 IronPort-SDR: 3f5z8FtAcKQHXwtHMt9FRcNWGd8s9i+OwVY7xZiVJZwJ9J8L90DPJugA4bxt9UGJmMpQj6s8/w T4kUXZruE8ig== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,407,1580803200"; d="scan'208";a="258439869" Received: from iweiny-desk2.sc.intel.com ([10.3.52.147]) by orsmga006.jf.intel.com with ESMTP; 20 Apr 2020 11:36:17 -0700 Date: Mon, 20 Apr 2020 11:36:17 -0700 From: Ira Weiny To: Dave Chinner Cc: linux-kernel@vger.kernel.org, "Darrick J. Wong" , Jan Kara , Dan Williams , Christoph Hellwig , "Theodore Y. Ts'o" , Jeff Moyer , linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH V8 10/11] fs/xfs: Change xfs_ioctl_setattr_dax_invalidate() Message-ID: <20200420183617.GB2838440@iweiny-DESK2.sc.intel.com> References: <20200415064523.2244712-1-ira.weiny@intel.com> <20200415064523.2244712-11-ira.weiny@intel.com> <20200420023131.GC9800@dread.disaster.area> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200420023131.GC9800@dread.disaster.area> User-Agent: Mutt/1.11.1 (2018-12-01) Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Mon, Apr 20, 2020 at 12:31:31PM +1000, Dave Chinner wrote: > On Tue, Apr 14, 2020 at 11:45:22PM -0700, ira.weiny@intel.com wrote: > > From: Ira Weiny > > > > We only support changing FS_XFLAG_DAX on directories. Files get their > > flag from the parent directory on creation only. So no data > > invalidation needs to happen. > > > > Alter the xfs_ioctl_setattr_dax_invalidate() to be > > xfs_ioctl_setattr_dax_validate(). xfs_ioctl_setattr_dax_validate() now > > validates that any FS_XFLAG_DAX change is ok. > > > > This also allows use to remove the join_flags logic. > > > > Signed-off-by: Ira Weiny > > > > --- > > 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 | 105 +++++++++------------------------------------ > > 1 file changed, 20 insertions(+), 85 deletions(-) > > > > diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c > > index c6cd92ef4a05..75d4a830ef38 100644 > > --- a/fs/xfs/xfs_ioctl.c > > +++ b/fs/xfs/xfs_ioctl.c > > @@ -1145,63 +1145,28 @@ xfs_ioctl_setattr_xflags( > > } > > > > /* > > - * 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. > > + * Mark inodes with a changing FS_XFLAG_DAX, I_DONTCACHE > > That describes what the code is doing, not why. I'll remove the comment. > > > */ > > -static int > > +static void > > xfs_ioctl_setattr_dax_invalidate( > > struct xfs_inode *ip, > > - struct fsxattr *fa, > > - int *join_flags) > > + struct fsxattr *fa) > > It's not an invalidation function anymore, so needs a name change. Done. > > > - if (!(fa->fsx_xflags & FS_XFLAG_DAX) && !IS_DAX(inode)) > > - return 0; > > + struct xfs_mount *mp = ip->i_mount; > > + struct inode *inode = VFS_I(ip); > > > > if (S_ISDIR(inode->i_mode)) > > - return 0; > > - > > - /* lock, flush and invalidate mapping in preparation for flag change */ > > - xfs_ilock(ip, XFS_MMAPLOCK_EXCL | XFS_IOLOCK_EXCL); > > - error = filemap_write_and_wait(inode->i_mapping); > > - if (error) > > - goto out_unlock; > > - error = invalidate_inode_pages2(inode->i_mapping); > > - if (error) > > - goto out_unlock; > > + return; > > > > - *join_flags = XFS_MMAPLOCK_EXCL | XFS_IOLOCK_EXCL; > > - return 0; > > - > > -out_unlock: > > - xfs_iunlock(ip, XFS_MMAPLOCK_EXCL | XFS_IOLOCK_EXCL); > > - return error; > > + if (mp->m_flags & XFS_MOUNT_DAX_ALWAYS || > > + mp->m_flags & XFS_MOUNT_DAX_NEVER) > > + return; > > if (mp->m_flags & (XFS_MOUNT_DAX_ALWAYS | XFS_MOUNT_DAX_NEVER)) > return; > > + if (((fa->fsx_xflags & FS_XFLAG_DAX) && > > + !(ip->i_d.di_flags2 & XFS_DIFLAG2_DAX)) || > > + (!(fa->fsx_xflags & FS_XFLAG_DAX) && > > + (ip->i_d.di_flags2 & XFS_DIFLAG2_DAX))) > > + flag_inode_dontcache(inode); > > This doesn't set the XFS inode's "don't cache" flag, despite it > having one that serves exactly the same purpose. IOWs, if the XFS_IDONTCACHE > flag is now redundant, please replace it's current usage with this new flag > and get rid of the XFS inode flag. i.e. the only place we set XFS_IDONTCACHE > can be replaced with a call to this mark_inode_dontcache() call... I agree, and I would have removed XFS_IDONTCACHE, except I was not convinced that XFS_IDONTCACHE was redundant. Currently XFS_IDONTCACHE can be cleared if the inode is found in the cache and I was unable to convince myself that it would be ok to remove it. I mentioned this to Darrick in V7. https://lore.kernel.org/lkml/20200413194432.GD1649878@iweiny-DESK2.sc.intel.com/ What am I missing with this code? xfs_iget_cache_hit(): ... if (!(flags & XFS_IGET_INCORE)) xfs_iflags_clear(ip, XFS_ISTALE | XFS_IDONTCACHE); ... Why is XFS_IDONTCACHE not 'sticky'? And why does xfs_iget_cache_hit() clear it rather than fail when XFS_IDONTCACHE is set? Ira > > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com