On Sun, Nov 15, 2020 at 10:36:51AM -0800, Dave Hansen wrote:
> On 11/15/20 9:32 AM, Matthew Wilcox wrote:
> > On Fri, Nov 13, 2020 at 12:01:21AM +0200, Jarkko Sakkinen wrote:
> >> +++ b/include/linux/mm.h
> >> @@ -559,6 +559,13 @@ struct vm_operations_struct {
> >> void (*close)(struct vm_area_struct * area);
> >> int (*split)(struct vm_area_struct * area, unsigned long addr);
> >> int (*mremap)(struct vm_area_struct * area);
> >> + /*
> >> + * Called by mprotect() to make driver-specific permission
> >> + * checks before mprotect() is finalised. The VMA must not
> >> + * be modified. Returns 0 if eprotect() can proceed.
> >> + */
> >
> > This is the wrong place for this documentation, and it's absurdly
> > specific to your implementation. It should be in
> > Documentation/filesystems/locking.rst.
>
> I'll let you and Mel duke that one out:
>
I suggested placing the comment there to make it clear what the expected
semantics of the hook was to reduce the chances of abuse or surprises. The
hook does not affect locking so Documentation/filesystems/locking.rst
didn't appear appropriate other than maybe adding a note there
that it doesn't affect locks. The hook also is not expecting any
filesystems-specific action that I aware of but a note could be added to
the effect that filesystems should not need to take special action for it.
Protections on the filesystem level are for the inode, I can't imagine what
a filesystem would do with a protection change on the page table level
but maybe I'm not particularly imaginative today.
--
Mel Gorman
SUSE Labs
