[PATCH v3 6/7] mm: introduce mod_vm_flags_nolock and use it in untrack_pfn

Mel Gorman mgorman at techsingularity.net
Fri Jan 27 02:47:40 AEDT 2023


On Wed, Jan 25, 2023 at 03:35:53PM -0800, Suren Baghdasaryan wrote:
> In cases when VMA flags are modified after VMA was isolated and mmap_lock
> was downgraded, flags modifications would result in an assertion because
> mmap write lock is not held.

Add note that it's also used during exit when the locking of the VMAs
becomes irrelevant (mm users is 0, should be no VMA modifications taking
place other than zap).

The typical naming pattern when a caller either knows it holds the necessary
lock or knows it does not matter is __mod_vm_flags()

> Introduce mod_vm_flags_nolock to be used in such situation, when VMA is
> not part of VMA tree and locking it is not required.

Instead of such situations, describe in as "used when the caller takes
responsibility for the required locking".

> Pass a hint to untrack_pfn to conditionally use mod_vm_flags_nolock for
> flags modification and to avoid assertion.
> 
> Signed-off-by: Suren Baghdasaryan <surenb at google.com>

Patch itself looks ok. It strays close to being "conditional locking"
though which might attract some complaints.

-- 
Mel Gorman
SUSE Labs


More information about the Linuxppc-dev mailing list