On Wed, Jan 18, 2023 at 1:33 PM Michal Hocko [off-list ref] wrote:

On Wed 18-01-23 10:09:29, Suren Baghdasaryan wrote:

quoted

On Wed, Jan 18, 2023 at 1:23 AM Michal Hocko [off-list ref] wrote:

quoted

On Tue 17-01-23 18:01:01, Suren Baghdasaryan wrote:

quoted

On Tue, Jan 17, 2023 at 7:16 AM Michal Hocko [off-list ref] wrote:

quoted

On Mon 09-01-23 12:53:12, Suren Baghdasaryan wrote:

quoted

Move VMA flag modification (which now implies VMA locking) before
anon_vma_lock_write to match the locking order of page fault handler.

Does this changelog assumes per vma locking in the #PF?

Hmm, you are right. Page fault handlers do not use per-vma locks yet
but the changelog already talks about that. Maybe I should change it
to simply:

Move VMA flag modification (which now implies VMA locking) before
vma_adjust_trans_huge() to ensure the modifications are done after VMA
has been locked.

Because ....

because vma_adjust_trans_huge() modifies the VMA and such
modifications should be done under VMA write-lock protection.

So it will become:
Move VMA flag modification (which now implies VMA locking) before
vma_adjust_trans_huge() to ensure the modifications are done after VMA
has been locked. Because vma_adjust_trans_huge() modifies the VMA and such
modifications should be done under VMA write-lock protection.

which is effectivelly saying
vma_adjust_trans_huge() modifies the VMA and such modifications should
be done under VMA write-lock protection so move VMA flag modifications
before so all of them are covered by the same write protection.

right?

Yes, and the wording in the latter version is simpler to understand
IMO, so I would like to adopt it. Do you agree?

--
Michal Hocko
SUSE Labs