On Thu, Jan 26, 2023 at 08:18:31AM -0800, Suren Baghdasaryan wrote: > On Thu, Jan 26, 2023 at 7:47 AM Mel Gorman <mgorman@xxxxxxxxxxxxxxxxxxx> wrote: > > > > 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). > > Ack. > > > > > The typical naming pattern when a caller either knows it holds the necessary > > lock or knows it does not matter is __mod_vm_flags() > > Ok. It sounds less explicit but plenty of examples, so I'm fine with > such rename. Will apply in the next version. > It might be a personal thing. nolock to me is ambigious because it might mean "lock is already held", "no lock is necessary" or "no lock is acquired" where as *for me*, calling foo vs __foo *usually* means "direct callers of __foo take care of the locking, memory ordering, per-cpu pinning details etc" depending on the context. Of course, this convention is not universally true. > > > 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@xxxxxxxxxx> > > > > Patch itself looks ok. It strays close to being "conditional locking" > > though which might attract some complaints. > > The description seems to accurately describe what's done here but I'm > open to better suggestions. I don't have alternative suggestions but if someone else reads the patch and says "this is conditional locking", you can at least claim that someone else considered "conditional locking" and didn't think it was a major problem in this specific patch. -- Mel Gorman SUSE Labs
