From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: Andrew Morton <akpm@linux-foundation.org>,
"Liam R . Howlett" <Liam.Howlett@oracle.com>
Cc: Matthew Wilcox <willy@infradead.org>,
Vlastimil Babka <vbabka@suse.cz>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Sidhartha Kumar <sidhartha.kumar@oracle.com>,
Bert Karwatzki <spasswolf@web.de>,
Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>,
maple-tree@lists.infradead.org
Subject: [PATCH v2 hotfix 6.12 0/2] maple_tree: correct tree corruption on spanning store
Date: Sun, 6 Oct 2024 15:31:06 +0100 [thread overview]
Message-ID: <cover.1728223996.git.lorenzo.stoakes@oracle.com> (raw)
There has been a nasty yet subtle maple tree corruption bug that appears to
have been in existence since the inception of the algorithm.
This bug seems far more likely to happen since commit f8d112a4e657
("mm/mmap: avoid zeroing vma tree in mmap_region()"), which is the point at
which reports started to be submitted concerning this bug.
We were made definitely aware of the bug thanks to the kind efforts of Bert
Karwatzki who helped enormously in my being able to track this down and
identify the cause of it.
The bug arises when an attempt is made to perform a spanning store across
two leaf nodes, where the right leaf node is the rightmost child of the
shared parent, AND the store completely consumes the right-mode node.
This results in mas_wr_spanning_store() mitakenly duplicating the new and
existing entries at the maximum pivot within the range, and thus maple tree
corruption.
The fix patch corrects this by detecting this scenario and disallowing the
mistaken duplicate copy.
The fix patch commit message goes into great detail as to how this occurs.
This series also includes a test which reliably reproduces the issue, and
asserts that the fix works correctly.
Bert has kindly tested the fix and confirmed it resolved his issues. Also
Mikhail Gavrilov kindly reported what appears to be precisely the same bug,
which this fix should also resolve.
Please note - I am intentionally holding off on cc'ing stable until we've
had a chance to be satisfied the series has stabilised in 6.12 as this is a
highly subtle change.
v2:
* Majorly improve clarity of commit message describing the problem.
* Add a reproducable test.
* Add missing maple tree mailing list to cc- list.
v1:
https://lore.kernel.org/linux-mm/20241005064114.42770-1-lorenzo.stoakes@oracle.com/
Lorenzo Stoakes (2):
maple_tree: correct tree corruption on spanning store
maple_tree: add regression test for spanning store bug
lib/maple_tree.c | 20 ++++++--
tools/testing/radix-tree/maple.c | 84 ++++++++++++++++++++++++++++++++
2 files changed, 100 insertions(+), 4 deletions(-)
--
2.46.2
next reply other threads:[~2024-10-06 14:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-06 14:31 Lorenzo Stoakes [this message]
2024-10-06 14:31 ` [PATCH v2 hotfix 6.12 1/2] " Lorenzo Stoakes
2024-10-07 12:14 ` Vlastimil Babka
2024-10-07 14:47 ` Liam R. Howlett
2024-10-07 15:04 ` Lorenzo Stoakes
2024-10-06 14:31 ` [PATCH v2 hotfix 6.12 2/2] maple_tree: add regression test for spanning store bug Lorenzo Stoakes
2024-10-07 12:15 ` Vlastimil Babka
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=cover.1728223996.git.lorenzo.stoakes@oracle.com \
--to=lorenzo.stoakes@oracle.com \
--cc=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=mikhail.v.gavrilov@gmail.com \
--cc=sidhartha.kumar@oracle.com \
--cc=spasswolf@web.de \
--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