From: Matthew Wilcox <willy@infradead.org>
To: Uladzislau Rezki <urezki@gmail.com>
Cc: Waiman Long <longman@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/vmalloc: Fix unlock order in s_stop()
Date: Mon, 14 Dec 2020 15:37:46 +0000 [thread overview]
Message-ID: <20201214153746.GK2443@casper.infradead.org> (raw)
In-Reply-To: <20201214151128.GA2094@pc638.lan>
On Mon, Dec 14, 2020 at 04:11:28PM +0100, Uladzislau Rezki wrote:
> On Sun, Dec 13, 2020 at 09:51:34PM +0000, Matthew Wilcox wrote:
> > If we need to iterate the list efficiently, i'd suggest getting rid of
> > the list and using an xarray instead. maybe a maple tree, once that code
> > is better exercised.
>
> Not really efficiently. We need just a full scan of it propagating the
> information about mapped and un-purged areas to user space applications.
>
> For example RCU-safe list is what we need, IMHO. From the other hand i
> am not sure if xarray is RCU safe in a context of concurrent removing/adding
> an element(xa_remove()/xa_insert()) and scanning like xa_for_each_XXX().
It's as RCU safe as an RCU-safe list. Specifically, it guarantees:
- If an element is present at all times between the start and the
end of the iteration, it will appear in the iteration.
- No element will appear more than once.
- No element will appear in the iteration that was never present.
- The iteration will terminate.
If an element is added or removed between the start and end of the
iteration, it may or may not appear. Causality is not guaranteed (eg
if modification A is made before modification B, modification B may
be reflected in the iteration while modification A is not).
next prev parent reply other threads:[~2020-12-14 15:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-13 18:08 [PATCH] mm/vmalloc: Fix unlock order in s_stop() Waiman Long
2020-12-13 18:39 ` Uladzislau Rezki
2020-12-13 19:42 ` Waiman Long
2020-12-13 21:51 ` Matthew Wilcox
2020-12-14 15:11 ` Uladzislau Rezki
2020-12-14 15:37 ` Matthew Wilcox [this message]
2020-12-14 17:56 ` Uladzislau Rezki
2020-12-14 9:39 ` David Hildenbrand
2020-12-14 15:05 ` Waiman Long
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=20201214153746.GK2443@casper.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=longman@redhat.com \
--cc=urezki@gmail.com \
/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).