From: Ira Weiny <[email protected]>
Page faults need to ensure the inode mode is correct and consistent with
the vmf information at the time of the fault. There is no easy way to
ensure the vmf information is correct if a mode change is in progress.
Furthermore, there is no good use case to require a mode change while
the file is mmap'ed.
Track mmap's of the file and fail the mode change if the file is
mmap'ed.
Signed-off-by: Ira Weiny <[email protected]>
---
fs/inode.c | 2 ++
fs/xfs/xfs_ioctl.c | 8 ++++++++
include/linux/fs.h | 1 +
mm/mmap.c | 19 +++++++++++++++++--
4 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/fs/inode.c b/fs/inode.c
index 2b0f51161918..944711aed6f8 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -245,6 +245,8 @@ static struct inode *alloc_inode(struct super_block *sb)
return NULL;
}
+ atomic64_set(&inode->i_mapped, 0);
+
return inode;
}
diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
index bc3654fe3b5d..1ab0906c6c7f 100644
--- a/fs/xfs/xfs_ioctl.c
+++ b/fs/xfs/xfs_ioctl.c
@@ -1200,6 +1200,14 @@ xfs_ioctl_setattr_dax_invalidate(
goto out_unlock;
}
+ /*
+ * If there is a mapping in place we must remain in our current mode.
+ */
+ if (atomic64_read(&inode->i_mapped)) {
+ error = -EBUSY;
+ goto out_unlock;
+ }
+
error = filemap_write_and_wait(inode->i_mapping);
if (error)
goto out_unlock;
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 631f11d6246e..6e7dc626b657 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -740,6 +740,7 @@ struct inode {
#endif
void *i_private; /* fs or device private pointer */
+ atomic64_t i_mapped;
} __randomize_layout;
struct timespec64 timestamp_truncate(struct timespec64 t, struct inode *inode);
diff --git a/mm/mmap.c b/mm/mmap.c
index dfaf1130e706..e6b68924b7ca 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -171,12 +171,17 @@ void unlink_file_vma(struct vm_area_struct *vma)
static struct vm_area_struct *remove_vma(struct vm_area_struct *vma)
{
struct vm_area_struct *next = vma->vm_next;
+ struct file *f = vma->vm_file;
might_sleep();
if (vma->vm_ops && vma->vm_ops->close)
vma->vm_ops->close(vma);
- if (vma->vm_file)
- fput(vma->vm_file);
+ if (f) {
+ struct inode *inode = file_inode(f);
+ if (inode)
+ atomic64_dec(&inode->i_mapped);
+ fput(f);
+ }
mpol_put(vma_policy(vma));
vm_area_free(vma);
return next;
@@ -1837,6 +1842,16 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
vma_set_page_prot(vma);
+ /*
+ * Track if there is mapping in place such that a mode change
+ * does not occur on a file which is mapped
+ */
+ if (file) {
+ struct inode *inode = file_inode(file);
+
+ atomic64_inc(&inode->i_mapped);
+ }
+
return addr;
unmap_and_free_vma:
--
2.21.0
On Mon, Jan 13, 2020 at 05:30:04PM -0800, Darrick J. Wong wrote:
> On Mon, Jan 13, 2020 at 04:46:10PM -0800, Ira Weiny wrote:
> > On Mon, Jan 13, 2020 at 02:22:12PM -0800, Darrick J. Wong wrote:
> > > On Fri, Jan 10, 2020 at 11:29:39AM -0800, [email protected] wrote:
> > > > From: Ira Weiny <[email protected]>
> > > >
> >
> > [snip]
> >
> > > >
> > > > diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
> > > > index bc3654fe3b5d..1ab0906c6c7f 100644
> > > > --- a/fs/xfs/xfs_ioctl.c
> > > > +++ b/fs/xfs/xfs_ioctl.c
> > > > @@ -1200,6 +1200,14 @@ xfs_ioctl_setattr_dax_invalidate(
> > > > goto out_unlock;
> > > > }
> > > >
> > > > + /*
> > > > + * If there is a mapping in place we must remain in our current mode.
> > > > + */
> > > > + if (atomic64_read(&inode->i_mapped)) {
> > >
> > > Urk, should we really be messing around with the address space
> > > internals?
> >
> > I contemplated a function call instead of checking i_mapped directly? Is that
> > what you mean?
>
> Yeah. Abstracting the details just enough that filesystems don't have
> to know that i_mapped is atomic64 etc.
Done.
>
> >
> > >
> > > > + error = -EBUSY;
> > > > + goto out_unlock;
> > > > + }
> > > > +
> > > > error = filemap_write_and_wait(inode->i_mapping);
> > > > if (error)
> > > > goto out_unlock;
> > > > diff --git a/include/linux/fs.h b/include/linux/fs.h
> > > > index 631f11d6246e..6e7dc626b657 100644
> > > > --- a/include/linux/fs.h
> > > > +++ b/include/linux/fs.h
> > > > @@ -740,6 +740,7 @@ struct inode {
> > > > #endif
> > > >
> > > > void *i_private; /* fs or device private pointer */
> > > > + atomic64_t i_mapped;
> > >
> > > I would have expected to find this in struct address_space since the
> > > mapping count is a function of the address space, right?
> >
> > I suppose but the only external call (above) would be passing an inode. So to
> > me it seemed better here.
>
> But the number of memory mappings reflects the state of the address
> space, not the inode. Or maybe put another way, if I were an mm
> developer I would not expect to look in struct inode for mm state.
This is a good point...
>
> static inline bool inode_has_mappings(struct inode *inode)
> {
> return atomic64_read(&inode->i_mapping->mapcount) > 0;
> }
>
> OTOH if there exist other mm developers who /do/ find that storing the
> mmap count in struct inode is more logical, please let me know. :)
... My thinking was that the number of mappings does not matters to the mm
system... However, I'm starting to think you are correct... ;-)
I've made a note of it and we will see what others think.
Ira
>
> --D
>
> > Ira
> >
> > >
> > > --D
> > >