From: Dan Williams <dan.j.williams@intel.com> To: "Darrick J. Wong" <darrick.wong@oracle.com> Cc: Jan Kara <jack@suse.cz>, "linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>, Dave Chinner <david@fromorbit.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, linux-xfs@vger.kernel.org, Alexander Viro <viro@zeniv.linux.org.uk>, Andy Lutomirski <luto@kernel.org>, linux-fsdevel <linux-fsdevel@vger.kernel.org>, Christoph Hellwig <hch@lst.de> Subject: Re: [PATCH v2 3/5] fs, xfs: introduce FALLOC_FL_UNSEAL_BLOCK_MAP Date: Fri, 4 Aug 2017 13:36:01 -0700 [thread overview] Message-ID: <CAPcyv4jTfchiWLB6zMrdKYTiymjJyzuxBGhh8TRKAbY8rsXWnA@mail.gmail.com> (raw) In-Reply-To: <20170804200446.GD24087@magnolia> On Fri, Aug 4, 2017 at 1:04 PM, Darrick J. Wong <darrick.wong@oracle.com> wrote: > On Thu, Aug 03, 2017 at 07:28:23PM -0700, Dan Williams wrote: >> Provide an explicit fallocate operation type for clearing the >> S_IOMAP_IMMUTABLE flag. Like the enable case it requires CAP_IMMUTABLE >> and it can only be performed while no process has the file mapped. >> >> Cc: Jan Kara <jack@suse.cz> >> Cc: Jeff Moyer <jmoyer@redhat.com> >> Cc: Christoph Hellwig <hch@lst.de> >> Cc: Ross Zwisler <ross.zwisler@linux.intel.com> >> Cc: Alexander Viro <viro@zeniv.linux.org.uk> >> Cc: "Darrick J. Wong" <darrick.wong@oracle.com> >> Suggested-by: Dave Chinner <david@fromorbit.com> >> Signed-off-by: Dan Williams <dan.j.williams@intel.com> >> --- >> fs/open.c | 17 +++++++++++------ >> fs/xfs/xfs_bmap_util.c | 42 ++++++++++++++++++++++++++++++++++++++++++ >> fs/xfs/xfs_bmap_util.h | 3 +++ >> fs/xfs/xfs_file.c | 4 +++- >> include/linux/falloc.h | 3 ++- >> include/uapi/linux/falloc.h | 1 + >> 6 files changed, 62 insertions(+), 8 deletions(-) >> >> diff --git a/fs/open.c b/fs/open.c >> index e3aae59785ae..ccfd8d3becc8 100644 >> --- a/fs/open.c >> +++ b/fs/open.c >> @@ -274,13 +274,17 @@ int vfs_fallocate(struct file *file, int mode, loff_t offset, loff_t len) >> return -EINVAL; >> >> /* >> - * Seal block map operation should only be used exclusively, and >> - * with the IMMUTABLE capability. >> + * Seal/unseal block map operations should only be used >> + * exclusively, and with the IMMUTABLE capability. >> */ >> - if (mode & FALLOC_FL_SEAL_BLOCK_MAP) { >> + if (mode & (FALLOC_FL_SEAL_BLOCK_MAP | FALLOC_FL_UNSEAL_BLOCK_MAP)) { >> if (!capable(CAP_LINUX_IMMUTABLE)) >> return -EPERM; >> - if (mode & ~FALLOC_FL_SEAL_BLOCK_MAP) >> + if (mode == (FALLOC_FL_SEAL_BLOCK_MAP >> + | FALLOC_FL_UNSEAL_BLOCK_MAP)) >> + return -EINVAL; >> + if (mode & ~(FALLOC_FL_SEAL_BLOCK_MAP >> + | FALLOC_FL_UNSEAL_BLOCK_MAP)) >> return -EINVAL; >> } >> >> @@ -303,9 +307,10 @@ int vfs_fallocate(struct file *file, int mode, loff_t offset, loff_t len) >> return -ETXTBSY; >> >> /* >> - * We cannot allow any allocation changes on an iomap immutable file >> + * We cannot allow any allocation changes on an iomap immutable >> + * file, but we can allow clearing the immutable state. >> */ >> - if (IS_IOMAP_IMMUTABLE(inode)) >> + if (IS_IOMAP_IMMUTABLE(inode) && !(mode & FALLOC_FL_UNSEAL_BLOCK_MAP)) >> return -ETXTBSY; >> >> /* >> diff --git a/fs/xfs/xfs_bmap_util.c b/fs/xfs/xfs_bmap_util.c >> index 46d8eb9e19fc..70ac2d33ab27 100644 >> --- a/fs/xfs/xfs_bmap_util.c >> +++ b/fs/xfs/xfs_bmap_util.c >> @@ -1494,6 +1494,48 @@ xfs_seal_file_space( >> return error; >> } >> >> +int >> +xfs_unseal_file_space( >> + struct xfs_inode *ip, >> + xfs_off_t offset, >> + xfs_off_t len) >> +{ >> + struct inode *inode = VFS_I(ip); >> + struct address_space *mapping = inode->i_mapping; >> + int error; >> + >> + ASSERT(xfs_isilocked(ip, XFS_MMAPLOCK_EXCL)); > > Same assert-on-the-iolock comment as the previous patch. Ok. > >> + >> + if (offset) >> + return -EINVAL; >> + >> + xfs_ilock(ip, XFS_ILOCK_EXCL); >> + /* >> + * It does not make sense to unseal less than the full range of >> + * the file. >> + */ >> + error = -EINVAL; >> + if (len < i_size_read(inode)) >> + goto out_unlock; > > Hmm, should we be picky and require len == i_size_read() here? Yes, I think so, otherwise we may have raced someone who increased the file size with unwritten extents. > >> + /* >> + * Provide safety against one thread changing the policy of not >> + * requiring fsync/msync (for block allocations) behind another >> + * thread's back. >> + */ >> + error = -EBUSY; >> + if (mapping_mapped(mapping)) >> + goto out_unlock; >> + >> + inode->i_flags &= ~S_IOMAP_IMMUTABLE; > > It occurred to me, should we jump out early from the seal/unseal > operations if the flag state matches whatever the user is asking for? > This is perhaps not necessary for unseal since we don't do a lot of > work. > Yes, I think I had that semantic in v1, but lost in the cleanups. Will bring it back. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
WARNING: multiple messages have this Message-ID (diff)
From: Dan Williams <dan.j.williams@intel.com> To: "Darrick J. Wong" <darrick.wong@oracle.com> Cc: Jan Kara <jack@suse.cz>, "linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>, Dave Chinner <david@fromorbit.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, linux-xfs@vger.kernel.org, Jeff Moyer <jmoyer@redhat.com>, Alexander Viro <viro@zeniv.linux.org.uk>, Andy Lutomirski <luto@kernel.org>, linux-fsdevel <linux-fsdevel@vger.kernel.org>, Ross Zwisler <ross.zwisler@linux.intel.com>, Christoph Hellwig <hch@lst.de> Subject: Re: [PATCH v2 3/5] fs, xfs: introduce FALLOC_FL_UNSEAL_BLOCK_MAP Date: Fri, 4 Aug 2017 13:36:01 -0700 [thread overview] Message-ID: <CAPcyv4jTfchiWLB6zMrdKYTiymjJyzuxBGhh8TRKAbY8rsXWnA@mail.gmail.com> (raw) In-Reply-To: <20170804200446.GD24087@magnolia> On Fri, Aug 4, 2017 at 1:04 PM, Darrick J. Wong <darrick.wong@oracle.com> wrote: > On Thu, Aug 03, 2017 at 07:28:23PM -0700, Dan Williams wrote: >> Provide an explicit fallocate operation type for clearing the >> S_IOMAP_IMMUTABLE flag. Like the enable case it requires CAP_IMMUTABLE >> and it can only be performed while no process has the file mapped. >> >> Cc: Jan Kara <jack@suse.cz> >> Cc: Jeff Moyer <jmoyer@redhat.com> >> Cc: Christoph Hellwig <hch@lst.de> >> Cc: Ross Zwisler <ross.zwisler@linux.intel.com> >> Cc: Alexander Viro <viro@zeniv.linux.org.uk> >> Cc: "Darrick J. Wong" <darrick.wong@oracle.com> >> Suggested-by: Dave Chinner <david@fromorbit.com> >> Signed-off-by: Dan Williams <dan.j.williams@intel.com> >> --- >> fs/open.c | 17 +++++++++++------ >> fs/xfs/xfs_bmap_util.c | 42 ++++++++++++++++++++++++++++++++++++++++++ >> fs/xfs/xfs_bmap_util.h | 3 +++ >> fs/xfs/xfs_file.c | 4 +++- >> include/linux/falloc.h | 3 ++- >> include/uapi/linux/falloc.h | 1 + >> 6 files changed, 62 insertions(+), 8 deletions(-) >> >> diff --git a/fs/open.c b/fs/open.c >> index e3aae59785ae..ccfd8d3becc8 100644 >> --- a/fs/open.c >> +++ b/fs/open.c >> @@ -274,13 +274,17 @@ int vfs_fallocate(struct file *file, int mode, loff_t offset, loff_t len) >> return -EINVAL; >> >> /* >> - * Seal block map operation should only be used exclusively, and >> - * with the IMMUTABLE capability. >> + * Seal/unseal block map operations should only be used >> + * exclusively, and with the IMMUTABLE capability. >> */ >> - if (mode & FALLOC_FL_SEAL_BLOCK_MAP) { >> + if (mode & (FALLOC_FL_SEAL_BLOCK_MAP | FALLOC_FL_UNSEAL_BLOCK_MAP)) { >> if (!capable(CAP_LINUX_IMMUTABLE)) >> return -EPERM; >> - if (mode & ~FALLOC_FL_SEAL_BLOCK_MAP) >> + if (mode == (FALLOC_FL_SEAL_BLOCK_MAP >> + | FALLOC_FL_UNSEAL_BLOCK_MAP)) >> + return -EINVAL; >> + if (mode & ~(FALLOC_FL_SEAL_BLOCK_MAP >> + | FALLOC_FL_UNSEAL_BLOCK_MAP)) >> return -EINVAL; >> } >> >> @@ -303,9 +307,10 @@ int vfs_fallocate(struct file *file, int mode, loff_t offset, loff_t len) >> return -ETXTBSY; >> >> /* >> - * We cannot allow any allocation changes on an iomap immutable file >> + * We cannot allow any allocation changes on an iomap immutable >> + * file, but we can allow clearing the immutable state. >> */ >> - if (IS_IOMAP_IMMUTABLE(inode)) >> + if (IS_IOMAP_IMMUTABLE(inode) && !(mode & FALLOC_FL_UNSEAL_BLOCK_MAP)) >> return -ETXTBSY; >> >> /* >> diff --git a/fs/xfs/xfs_bmap_util.c b/fs/xfs/xfs_bmap_util.c >> index 46d8eb9e19fc..70ac2d33ab27 100644 >> --- a/fs/xfs/xfs_bmap_util.c >> +++ b/fs/xfs/xfs_bmap_util.c >> @@ -1494,6 +1494,48 @@ xfs_seal_file_space( >> return error; >> } >> >> +int >> +xfs_unseal_file_space( >> + struct xfs_inode *ip, >> + xfs_off_t offset, >> + xfs_off_t len) >> +{ >> + struct inode *inode = VFS_I(ip); >> + struct address_space *mapping = inode->i_mapping; >> + int error; >> + >> + ASSERT(xfs_isilocked(ip, XFS_MMAPLOCK_EXCL)); > > Same assert-on-the-iolock comment as the previous patch. Ok. > >> + >> + if (offset) >> + return -EINVAL; >> + >> + xfs_ilock(ip, XFS_ILOCK_EXCL); >> + /* >> + * It does not make sense to unseal less than the full range of >> + * the file. >> + */ >> + error = -EINVAL; >> + if (len < i_size_read(inode)) >> + goto out_unlock; > > Hmm, should we be picky and require len == i_size_read() here? Yes, I think so, otherwise we may have raced someone who increased the file size with unwritten extents. > >> + /* >> + * Provide safety against one thread changing the policy of not >> + * requiring fsync/msync (for block allocations) behind another >> + * thread's back. >> + */ >> + error = -EBUSY; >> + if (mapping_mapped(mapping)) >> + goto out_unlock; >> + >> + inode->i_flags &= ~S_IOMAP_IMMUTABLE; > > It occurred to me, should we jump out early from the seal/unseal > operations if the flag state matches whatever the user is asking for? > This is perhaps not necessary for unseal since we don't do a lot of > work. > Yes, I think I had that semantic in v1, but lost in the cleanups. Will bring it back.
next prev parent reply other threads:[~2017-08-04 20:33 UTC|newest] Thread overview: 108+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-08-04 2:28 [PATCH v2 0/5] fs, xfs: block map immutable files for dax, dma-to-storage, and swap Dan Williams 2017-08-04 2:28 ` Dan Williams 2017-08-04 2:28 ` [PATCH v2 1/5] fs, xfs: introduce S_IOMAP_IMMUTABLE Dan Williams 2017-08-04 2:28 ` Dan Williams 2017-08-04 20:00 ` Darrick J. Wong 2017-08-04 20:00 ` Darrick J. Wong 2017-08-04 20:31 ` Dan Williams 2017-08-04 20:31 ` Dan Williams 2017-08-05 9:47 ` Christoph Hellwig 2017-08-05 9:47 ` Christoph Hellwig 2017-08-07 0:25 ` Dave Chinner 2017-08-07 0:25 ` Dave Chinner 2017-08-11 10:34 ` Christoph Hellwig 2017-08-11 10:34 ` Christoph Hellwig 2017-08-04 2:28 ` [PATCH v2 2/5] fs, xfs: introduce FALLOC_FL_SEAL_BLOCK_MAP Dan Williams 2017-08-04 2:28 ` Dan Williams 2017-08-04 2:28 ` Dan Williams 2017-08-04 19:46 ` Darrick J. Wong 2017-08-04 19:46 ` Darrick J. Wong 2017-08-04 19:52 ` Dan Williams 2017-08-04 19:52 ` Dan Williams 2017-08-04 23:31 ` Dave Chinner 2017-08-04 23:31 ` Dave Chinner 2017-08-04 23:43 ` Dan Williams 2017-08-04 23:43 ` Dan Williams 2017-08-05 0:04 ` Dave Chinner 2017-08-05 0:04 ` Dave Chinner 2017-08-04 2:28 ` [PATCH v2 3/5] fs, xfs: introduce FALLOC_FL_UNSEAL_BLOCK_MAP Dan Williams 2017-08-04 2:28 ` Dan Williams 2017-08-04 20:04 ` Darrick J. Wong 2017-08-04 20:04 ` Darrick J. Wong 2017-08-04 20:36 ` Dan Williams [this message] 2017-08-04 20:36 ` Dan Williams 2017-08-04 2:28 ` [PATCH v2 4/5] xfs: introduce XFS_DIFLAG2_IOMAP_IMMUTABLE Dan Williams 2017-08-04 2:28 ` Dan Williams 2017-08-04 20:33 ` Darrick J. Wong 2017-08-04 20:33 ` Darrick J. Wong 2017-08-04 20:45 ` Dan Williams 2017-08-04 20:45 ` Dan Williams 2017-08-04 23:46 ` Dave Chinner 2017-08-04 23:46 ` Dave Chinner 2017-08-04 23:57 ` Darrick J. Wong 2017-08-04 23:57 ` Darrick J. Wong 2017-08-04 2:28 ` [PATCH v2 5/5] xfs: toggle XFS_DIFLAG2_IOMAP_IMMUTABLE in response to fallocate Dan Williams 2017-08-04 2:28 ` Dan Williams 2017-08-04 20:14 ` Darrick J. Wong 2017-08-04 20:14 ` Darrick J. Wong 2017-08-04 20:47 ` Dan Williams 2017-08-04 20:47 ` Dan Williams 2017-08-04 20:53 ` Darrick J. Wong 2017-08-04 20:53 ` Darrick J. Wong 2017-08-04 20:55 ` Dan Williams 2017-08-04 20:55 ` Dan Williams 2017-08-04 2:38 ` [PATCH v2 0/5] fs, xfs: block map immutable files for dax, dma-to-storage, and swap Dan Williams 2017-08-04 2:38 ` Dan Williams 2017-08-04 2:38 ` Dan Williams 2017-08-05 9:50 ` Christoph Hellwig 2017-08-05 9:50 ` Christoph Hellwig 2017-08-05 9:50 ` Christoph Hellwig 2017-08-06 18:51 ` Dan Williams 2017-08-06 18:51 ` Dan Williams 2017-08-06 18:51 ` Dan Williams 2017-08-11 10:44 ` Christoph Hellwig 2017-08-11 10:44 ` Christoph Hellwig 2017-08-11 10:44 ` Christoph Hellwig 2017-08-11 22:26 ` Dan Williams 2017-08-11 22:26 ` Dan Williams 2017-08-11 22:26 ` Dan Williams 2017-08-12 3:57 ` Andy Lutomirski 2017-08-12 3:57 ` Andy Lutomirski 2017-08-12 4:44 ` Dan Williams 2017-08-12 4:44 ` Dan Williams 2017-08-12 4:44 ` Dan Williams 2017-08-12 7:34 ` Christoph Hellwig 2017-08-12 7:34 ` Christoph Hellwig 2017-08-12 7:34 ` Christoph Hellwig 2017-08-12 7:33 ` Christoph Hellwig 2017-08-12 7:33 ` Christoph Hellwig 2017-08-12 7:33 ` Christoph Hellwig 2017-08-12 19:19 ` Dan Williams 2017-08-12 19:19 ` Dan Williams 2017-08-12 19:19 ` Dan Williams 2017-08-13 9:24 ` Christoph Hellwig 2017-08-13 9:24 ` Christoph Hellwig 2017-08-13 20:31 ` Dan Williams 2017-08-13 20:31 ` Dan Williams 2017-08-13 20:31 ` Dan Williams 2017-08-14 12:40 ` Jan Kara 2017-08-14 12:40 ` Jan Kara 2017-08-14 12:40 ` Jan Kara 2017-08-14 16:14 ` Dan Williams 2017-08-14 16:14 ` Dan Williams 2017-08-15 8:37 ` Jan Kara 2017-08-15 8:37 ` Jan Kara 2017-08-15 8:37 ` Jan Kara 2017-08-15 23:50 ` Dan Williams 2017-08-15 23:50 ` Dan Williams 2017-08-16 13:57 ` Jan Kara 2017-08-16 13:57 ` Jan Kara 2017-08-16 13:57 ` Jan Kara 2017-08-21 9:16 ` Peter Zijlstra 2017-08-21 9:16 ` Peter Zijlstra 2017-08-21 9:16 ` Peter Zijlstra 2017-08-14 21:46 ` Darrick J. Wong 2017-08-14 21:46 ` Darrick J. Wong 2017-08-14 21:46 ` Darrick J. Wong 2017-08-13 23:46 ` Dave Chinner 2017-08-13 23:46 ` Dave Chinner
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAPcyv4jTfchiWLB6zMrdKYTiymjJyzuxBGhh8TRKAbY8rsXWnA@mail.gmail.com \ --to=dan.j.williams@intel.com \ --cc=darrick.wong@oracle.com \ --cc=david@fromorbit.com \ --cc=hch@lst.de \ --cc=jack@suse.cz \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-nvdimm@lists.01.org \ --cc=linux-xfs@vger.kernel.org \ --cc=luto@kernel.org \ --cc=viro@zeniv.linux.org.uk \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.