linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@techsingularity.net>
To: Suren Baghdasaryan <surenb@google.com>
Cc: akpm@linux-foundation.org, michel@lespinasse.org,
	jglisse@google.com, mhocko@suse.com, vbabka@suse.cz,
	hannes@cmpxchg.org, dave@stgolabs.net, willy@infradead.org,
	liam.howlett@oracle.com, peterz@infradead.org,
	ldufour@linux.ibm.com, paulmck@kernel.org, mingo@redhat.com,
	will@kernel.org, luto@kernel.org, songliubraving@fb.com,
	peterx@redhat.com, david@redhat.com, dhowells@redhat.com,
	hughd@google.com, bigeasy@linutronix.de,
	kent.overstreet@linux.dev, punit.agrawal@bytedance.com,
	lstoakes@gmail.com, peterjung1337@gmail.com, rientjes@google.com,
	axelrasmussen@google.com, joelaf@google.com, minchan@google.com,
	jannh@google.com, shakeelb@google.com, tatashin@google.com,
	edumazet@google.com, gthelen@google.com, gurua@google.com,
	arjunroy@google.com, soheil@google.com, hughlynch@google.com,
	leewalsh@google.com, posk@google.com, linux-mm@kvack.org,
	linux-arm-kernel@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org, x86@kernel.org,
	linux-kernel@vger.kernel.org, kernel-team@android.com
Subject: Re: [PATCH v3 6/7] mm: introduce mod_vm_flags_nolock and use it in untrack_pfn
Date: Thu, 26 Jan 2023 15:47:40 +0000	[thread overview]
Message-ID: <20230126154740.j3a3lu4x557c56yi@techsingularity.net> (raw)
In-Reply-To: <20230125233554.153109-7-surenb@google.com>

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@google.com>

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

-- 
Mel Gorman
SUSE Labs

  parent reply	other threads:[~2023-01-26 15:47 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-25 23:35 [PATCH v3 0/7] introduce vm_flags modifier functions Suren Baghdasaryan
2023-01-25 23:35 ` [PATCH v3 1/7] kernel/fork: convert vma assignment to a memcpy Suren Baghdasaryan
2023-01-26  0:21   ` Andrew Morton
2023-01-26  0:50     ` Suren Baghdasaryan
2023-01-26  1:34       ` Andrew Morton
2023-01-26 11:52         ` Mel Gorman
2023-01-26 15:59           ` Suren Baghdasaryan
2023-01-26 17:27         ` Paul E. McKenney
2023-02-07 17:16           ` Marco Elver
2023-02-07 17:23             ` Suren Baghdasaryan
2023-02-07 17:51               ` Marco Elver
2023-01-25 23:35 ` [PATCH v3 2/7] mm: introduce vma->vm_flags wrapper functions Suren Baghdasaryan
2023-01-26  0:24   ` Andrew Morton
2023-01-26  0:51     ` Suren Baghdasaryan
2023-01-26 17:48     ` Davidlohr Bueso
2023-01-26  0:28   ` Andrew Morton
2023-01-26  0:56     ` Suren Baghdasaryan
2023-01-26  7:59       ` Michal Hocko
2023-01-26  8:33   ` Michal Hocko
2023-01-26 13:58   ` Mel Gorman
2023-01-26 16:01     ` Suren Baghdasaryan
2023-01-25 23:35 ` [PATCH v3 3/7] mm: replace VM_LOCKED_CLEAR_MASK with VM_LOCKED_MASK Suren Baghdasaryan
2023-01-26 13:59   ` Mel Gorman
2023-01-26 14:16   ` Mel Gorman
2023-01-25 23:35 ` [PATCH v3 4/7] mm: replace vma->vm_flags direct modifications with modifier calls Suren Baghdasaryan
2023-01-26 15:10   ` Mel Gorman
2023-01-26 16:10     ` Suren Baghdasaryan
2023-01-26 17:26       ` Mel Gorman
2023-01-26 17:28         ` Suren Baghdasaryan
2023-01-25 23:35 ` [PATCH v3 5/7] mm: replace vma->vm_flags indirect modification in ksm_madvise Suren Baghdasaryan
2023-01-26 15:19   ` Mel Gorman
2023-01-26 16:11     ` Suren Baghdasaryan
2023-01-25 23:35 ` [PATCH v3 6/7] mm: introduce mod_vm_flags_nolock and use it in untrack_pfn Suren Baghdasaryan
2023-01-26  8:34   ` Michal Hocko
2023-01-26 15:47   ` Mel Gorman [this message]
2023-01-26 16:18     ` Suren Baghdasaryan
2023-01-26 17:32       ` Mel Gorman
2023-01-26 17:34         ` Suren Baghdasaryan
2023-01-25 23:35 ` [PATCH v3 7/7] mm: export dump_mm() Suren Baghdasaryan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230126154740.j3a3lu4x557c56yi@techsingularity.net \
    --to=mgorman@techsingularity.net \
    --cc=akpm@linux-foundation.org \
    --cc=arjunroy@google.com \
    --cc=axelrasmussen@google.com \
    --cc=bigeasy@linutronix.de \
    --cc=dave@stgolabs.net \
    --cc=david@redhat.com \
    --cc=dhowells@redhat.com \
    --cc=edumazet@google.com \
    --cc=gthelen@google.com \
    --cc=gurua@google.com \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=hughlynch@google.com \
    --cc=jannh@google.com \
    --cc=jglisse@google.com \
    --cc=joelaf@google.com \
    --cc=kent.overstreet@linux.dev \
    --cc=kernel-team@android.com \
    --cc=ldufour@linux.ibm.com \
    --cc=leewalsh@google.com \
    --cc=liam.howlett@oracle.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=lstoakes@gmail.com \
    --cc=luto@kernel.org \
    --cc=mhocko@suse.com \
    --cc=michel@lespinasse.org \
    --cc=minchan@google.com \
    --cc=mingo@redhat.com \
    --cc=paulmck@kernel.org \
    --cc=peterjung1337@gmail.com \
    --cc=peterx@redhat.com \
    --cc=peterz@infradead.org \
    --cc=posk@google.com \
    --cc=punit.agrawal@bytedance.com \
    --cc=rientjes@google.com \
    --cc=shakeelb@google.com \
    --cc=soheil@google.com \
    --cc=songliubraving@fb.com \
    --cc=surenb@google.com \
    --cc=tatashin@google.com \
    --cc=vbabka@suse.cz \
    --cc=will@kernel.org \
    --cc=willy@infradead.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).