On Wed, Dec 08, 2021 at 04:51:58PM +0100, Michal Hocko wrote:

On Wed 08-12-21 15:01:24, Matthew Wilcox wrote:

quoted

On Tue, Dec 07, 2021 at 03:08:19PM -0800, Suren Baghdasaryan wrote:

quoted

quoted

quoted

        /**
         * @close: Called when the VMA is being removed from the MM.
         * Context: Caller holds mmap_lock.

BTW, is the caller always required to hold mmap_lock for write or it
*might* hold it?

__do_munmap() might hold it for read, thanks to:

        if (downgrade)
                mmap_write_downgrade(mm);

Should probably say:

	* Context: User context.  May sleep.  Caller holds mmap_lock.

I don't think we should burden the implementor of the vm_ops with the
knowledge that the VM chooses to not hold the mmap_lock under certain
circumstances when it doesn't matter whether it's holding the mmap_lock
or not.

If we document it like that some code might depend on that lock to be
held. I think we only want to document that the holder itself is not
allowed to take mmap sem or a depending lock.

The only place where we're not currently holding the mmap_lock is at
task exit, where the mmap_lock is effectively held because nobody else
can modify the task's mm.  Besides, Suren is changing that in this patch
series anyway, so it will be always true.