From: "Liam R. Howlett" <Liam.Howlett@Oracle.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
maple-tree@lists.infradead.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org,
Matthew Wilcox <willy@infradead.org>,
Suren Baghdasaryan <surenb@google.com>
Subject: Re: [PATCH 0/8] Fix VMA tree modification under mmap read lock
Date: Tue, 28 Mar 2023 09:02:30 -0400 [thread overview]
Message-ID: <20230328130230.gdmychfid3aggikd@revolver> (raw)
In-Reply-To: <a017acde-7520-743c-963b-94a23c0f30c8@suse.cz>
* Vlastimil Babka <vbabka@suse.cz> [230328 05:11]:
> On 3/27/23 21:48, Liam R. Howlett wrote:
> > * Andrew Morton <akpm@linux-foundation.org> [230327 15:35]:
> >> On Mon, 27 Mar 2023 14:55:24 -0400 "Liam R. Howlett" <Liam.Howlett@oracle.com> wrote:
> >>
> >> > These patches have been in -next since next-20230301, and have received
> >> > intensive testing in Android as part of the RCU page fault patchset.
> >> > They were also sent as part of the "Per-VMA locks" v4 patch series.
> >> > Patches 1 to 7 are bug fixes for RCU mode of the tree and patch 8 enables
> >> > RCU mode for the tree.
> >>
> >> What's happening here? I assume you've decided that the first 8
> >> patches of the "Per-VMA locks v4" series should be fast-tracked into
> >> 6.3-rcX and backported? And we retain the rest of that series for
> >> 6.4-rc1?
> >
> > Yes, they need to be backported and fast tracked to fix the issue syzbot
> > found.
>
> Stable usually wants the "mainline first" which means fast tracking first,
> then once it's in mainline, they pick it and annotate with mainline commit id.
Right. I meant these patches won't cleanly apply to 6.1/6.2 and will
need more than just a cherry-pick due to the vma iterator changes. I
have those modified patches ready to go as well.
>
> One question is how Linus would feel about this now for rc5.
>
> Another question is if we should really deviate in the patch 8/8 backport
> just because it's not necessary for stable. Generally they would also prefer
> not to deviate, unless there's a strong reason.
Just to clarify, the change is to remove something that isn't necessary
at all.
>
> >>
> >> Patch [3/8] hasn't come through to me, to linux-mm or to linux-kernel.
> >
> > Should arrive shortly, I received it from one of the ML.
> >
> >
>
>
> --
> maple-tree mailing list
> maple-tree@lists.infradead.org
> https://lists.infradead.org/mailman/listinfo/maple-tree
next prev parent reply other threads:[~2023-03-28 13:02 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-27 18:55 Liam R. Howlett
2023-03-27 18:55 ` [PATCH 1/8] maple_tree: be more cautious about dead nodes Liam R. Howlett
2023-03-27 18:55 ` [PATCH 2/8] maple_tree: detect dead nodes in mas_start() Liam R. Howlett
2023-03-27 18:55 ` [PATCH 3/8] maple_tree: fix freeing of nodes in rcu mode Liam R. Howlett
2023-03-27 18:55 ` [PATCH 4/8] maple_tree: remove extra smp_wmb() from mas_dead_leaves() Liam R. Howlett
2023-03-27 18:55 ` [PATCH 5/8] maple_tree: fix write memory barrier of nodes once dead for RCU mode Liam R. Howlett
2023-03-27 19:05 ` Liam R. Howlett
2023-03-27 19:45 ` Andrew Morton
2023-03-27 18:55 ` [PATCH 6/8] maple_tree: add smp_rmb() to dead node detection Liam R. Howlett
2023-03-27 18:55 ` [PATCH 7/8] maple_tree: add RCU lock checking to rcu callback functions Liam R. Howlett
2023-03-27 18:55 ` [PATCH 8/8] mm: enable maple tree RCU mode by default Liam R. Howlett
2023-03-27 19:38 ` Andrew Morton
2023-03-27 19:43 ` Liam R. Howlett
2023-04-11 1:25 ` kernel test robot
2023-04-11 2:25 ` Matthew Wilcox
2023-03-27 19:35 ` [PATCH 0/8] Fix VMA tree modification under mmap read lock Andrew Morton
2023-03-27 19:48 ` Liam R. Howlett
2023-03-28 9:10 ` Vlastimil Babka
2023-03-28 13:02 ` Liam R. Howlett [this message]
2023-04-03 19:44 ` Liam R. Howlett
2023-04-03 20:19 ` Andrew Morton
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=20230328130230.gdmychfid3aggikd@revolver \
--to=liam.howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=maple-tree@lists.infradead.org \
--cc=surenb@google.com \
--cc=torvalds@linux-foundation.org \
--cc=vbabka@suse.cz \
--cc=willy@infradead.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