From: "Liam R. Howlett" <Liam.Howlett@Oracle.com>
To: Vlastimil Babka <vbabka@suse.cz>,
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: Mon, 3 Apr 2023 15:44:43 -0400 [thread overview]
Message-ID: <20230403194443.af3kbawab3d4r5pr@revolver> (raw)
In-Reply-To: <20230328130230.gdmychfid3aggikd@revolver>
* Liam R. Howlett <Liam.Howlett@Oracle.com> [230328 09:02]:
> * 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.
>
Andrew,
I just wanted to know where we stand with these patches?
I understand that it's late in the cycle, but this is a bug that affects
6.1, 6.2, 6.3-rc5 and can be triggered from userspace.
I'm asking because the LTS 6.1 is starting to be picked up by
distributions, although I don't know the scale of the install, and
getting these upstream will allow for the backported fixes to be picked
up by stable quicker.
Thanks,
Liam
next prev parent reply other threads:[~2023-04-03 19:45 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
2023-04-03 19:44 ` Liam R. Howlett [this message]
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=20230403194443.af3kbawab3d4r5pr@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