Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp840413ybk; Wed, 13 May 2020 14:42:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwiMSPiffSXA2TnOY7x6dSMfhT7Zr5aWkBppTcoMRZPYT6YOPeAemrkO5B+bkTRfFORyZ5i X-Received: by 2002:a17:906:938a:: with SMTP id l10mr1003990ejx.186.1589406159993; Wed, 13 May 2020 14:42:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589406159; cv=none; d=google.com; s=arc-20160816; b=CYEJYyD6Annwl0LcvAuazXbVTKsSyxSUb/Gfnz6fnJaBuylifzuMNAsS4W8gS8dR/H qv0Y1jAVtfHtP9KPweEbkzZGBMpBQ+6In4cHdEEhNlX5adfwmCVDdagILYsQ51aF+/wT HvSnVvRxo5u/qLb42UDyG6V6oErRLNhThYHZkkKJ9icnczM7f5RbAlnXYGFLkh6FoYPC pIOPGiuhem+xhnlXdkBLtP6fDndtrikLCVWw3X0wtnDTBR92VTzVRZzNdVVCe+Q/zkRi 1zxJUsYuyxjLhk2yINLTKjKxqPHSo6wRLi1VuvU6uCWfMatmylbe2mDtiNq7LMwDxWgC Pzzw== 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=huvHrbFGM1uZHXeYJx++I1r9oDfvJDHcWCz/qVCk7PA=; b=C4AV1CTKqscdM7yTgGbwASWHn9rFPunqZSLZVpDVFYBvK8U19Ourmq8V1oTByE+S9k CVQfX20ILshA7RF7Y/nAEiI+TJpxTKPHdZL4jTOOmTjSAOlVoZNc2jsjEMkvLZosCGt1 +OHcQtPy/LgKbTCwCquwl0IPXiSyarJuMuuf/lFxCQmWZwQHofS9A1Fploh1IQtW9c8u k+KgjW6zzcgO5I5cdfmZWJTxO5MQcrVIexWdBswkukt1o0k4KvUyFKv4qB1M5uLmHOWJ VKWDkgnplBt6W7LRzAvbc32U6NRxqVpHIh8PPWvpS5KkPj8KaDHk78qjaFdro+R5qQSv XG7Q== 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 e24si604651ejh.298.2020.05.13.14.42.08; Wed, 13 May 2020 14:42:39 -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 S1729540AbgEMVl4 (ORCPT + 99 others); Wed, 13 May 2020 17:41:56 -0400 Received: from mga03.intel.com ([134.134.136.65]:7010 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729196AbgEMVl4 (ORCPT ); Wed, 13 May 2020 17:41:56 -0400 IronPort-SDR: myQYB0V2K15ihPEq0wI4Fb0P7OmkFUFxIx6NF0KkBCns6Ai9ZtL2zsWdpIeoUSfomxiawMXo4s tF2f8zw8o0pA== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 May 2020 14:41:55 -0700 IronPort-SDR: G91xqFVTAl1hSUCjiwpQwMkoghQt2IXBwgchoMMwgdQiwBlQRpFohg3BNmQTWp29uqsQEIxCnk 4cV+pl4zDYeg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,389,1583222400"; d="scan'208";a="253307995" Received: from iweiny-desk2.sc.intel.com ([10.3.52.147]) by fmsmga008.fm.intel.com with ESMTP; 13 May 2020 14:41:55 -0700 Date: Wed, 13 May 2020 14:41:55 -0700 From: Ira Weiny To: Jan Kara Cc: linux-ext4@vger.kernel.org, Andreas Dilger , "Theodore Y. Ts'o" , Al Viro , Dan Williams , Dave Chinner , Christoph Hellwig , Jeff Moyer , "Darrick J. Wong" , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 8/9] fs/ext4: Introduce DAX inode flag Message-ID: <20200513214154.GB2140786@iweiny-DESK2.sc.intel.com> References: <20200513054324.2138483-1-ira.weiny@intel.com> <20200513054324.2138483-9-ira.weiny@intel.com> <20200513144706.GH27709@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200513144706.GH27709@quack2.suse.cz> 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 Wed, May 13, 2020 at 04:47:06PM +0200, Jan Kara wrote: > On Tue 12-05-20 22:43:23, ira.weiny@intel.com wrote: > > From: Ira Weiny > > > > Add a flag to preserve FS_XFLAG_DAX in the ext4 inode. > > > > Set the flag to be user visible and changeable. Set the flag to be > > inherited. Allow applications to change the flag at any time. > > > > Finally, on regular files, flag the inode to not be cached to facilitate > > changing S_DAX on the next creation of the inode. > > > > Signed-off-by: Ira Weiny > > > > --- > > Change from RFC: > > use new d_mark_dontcache() > > Allow caching if ALWAYS/NEVER is set > > Rebased to latest Linus master > > Change flag to unused 0x01000000 > > update ext4_should_enable_dax() > > --- > > fs/ext4/ext4.h | 13 +++++++++---- > > fs/ext4/inode.c | 4 +++- > > fs/ext4/ioctl.c | 25 ++++++++++++++++++++++++- > > 3 files changed, 36 insertions(+), 6 deletions(-) > > > > diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h > > index 01d1de838896..715f8f2029b2 100644 > > --- a/fs/ext4/ext4.h > > +++ b/fs/ext4/ext4.h > > @@ -415,13 +415,16 @@ struct flex_groups { > > #define EXT4_VERITY_FL 0x00100000 /* Verity protected inode */ > > #define EXT4_EA_INODE_FL 0x00200000 /* Inode used for large EA */ > > /* 0x00400000 was formerly EXT4_EOFBLOCKS_FL */ > > + > > +#define EXT4_DAX_FL 0x01000000 /* Inode is DAX */ > > + > > #define EXT4_INLINE_DATA_FL 0x10000000 /* Inode has inline data. */ > > #define EXT4_PROJINHERIT_FL 0x20000000 /* Create with parents projid */ > > #define EXT4_CASEFOLD_FL 0x40000000 /* Casefolded file */ > > #define EXT4_RESERVED_FL 0x80000000 /* reserved for ext4 lib */ > > > > -#define EXT4_FL_USER_VISIBLE 0x705BDFFF /* User visible flags */ > > -#define EXT4_FL_USER_MODIFIABLE 0x604BC0FF /* User modifiable flags */ > > +#define EXT4_FL_USER_VISIBLE 0x715BDFFF /* User visible flags */ > > +#define EXT4_FL_USER_MODIFIABLE 0x614BC0FF /* User modifiable flags */ > > Hum, I think this was already mentioned but there are also definitions in > include/uapi/linux/fs.h which should be kept in sync... Also if DAX flag > gets modified through FS_IOC_SETFLAGS, we should call ext4_doncache() as > well, shouldn't we? Ah yea it was mentioned. Sorry. > > > @@ -802,6 +807,21 @@ static int ext4_ioctl_get_es_cache(struct file *filp, unsigned long arg) > > return error; > > } > > > > +static void ext4_dax_dontcache(struct inode *inode, unsigned int flags) > > +{ > > + struct ext4_inode_info *ei = EXT4_I(inode); > > + > > + if (S_ISDIR(inode->i_mode)) > > + return; > > + > > + if (test_opt2(inode->i_sb, DAX_NEVER) || > > + test_opt(inode->i_sb, DAX_ALWAYS)) > > + return; > > + > > + if (((ei->i_flags ^ flags) & EXT4_DAX_FL) == EXT4_DAX_FL) > > + d_mark_dontcache(inode); > > +} > > + > > long ext4_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) > > { > > struct inode *inode = file_inode(filp); > > @@ -1267,6 +1287,9 @@ long ext4_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) > > return err; > > > > inode_lock(inode); > > + > > + ext4_dax_dontcache(inode, flags); > > + > > I don't think we should set dontcache flag when setting of DAX flag fails - > it could event be a security issue). good point. > > So I think you'll have to check > whether DAX flag is being changed, ext4_dax_dontcache() does check if the flag is being changed. > call vfs_ioc_fssetxattr_check(), and > only if it succeeded and DAX flags was changing call ext4_dax_dontcache(). Yes I think it would be better to ensure all of the ioctl succeeds prior to setting the don't cache. The logic is easier to follow. Ira > > Honza > -- > Jan Kara > SUSE Labs, CR