From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: "Liam R. Howlett" <Liam.Howlett@oracle.com>,
Andrew Morton <akpm@linux-foundation.org>,
maple-tree@lists.infradead.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH v2 1/2] maple_tree: Disable mas_wr_append() when other readers are possible
Date: Thu, 31 Aug 2023 10:25:48 +0200 [thread overview]
Message-ID: <CAMuHMdXMpr0spdprjwsV56nJE3vHGTFaodcnVXUa=GMYaB5yKw@mail.gmail.com> (raw)
In-Reply-To: <87v8cv22jh.fsf@mail.lhotse>
Hi Michael,
On Thu, Aug 31, 2023 at 7:39 AM Michael Ellerman <mpe@ellerman.id.au> wrote:
> Geert Uytterhoeven <geert@linux-m68k.org> writes:
> > On Fri, 18 Aug 2023, Liam R. Howlett wrote:
> >> The current implementation of append may cause duplicate data and/or
> >> incorrect ranges to be returned to a reader during an update. Although
> >> this has not been reported or seen, disable the append write operation
> >> while the tree is in rcu mode out of an abundance of caution.
> >>
> >> During the analysis of the mas_next_slot() the following was
> >> artificially created by separating the writer and reader code:
> >>
> >> Writer: reader:
> >> mas_wr_append
> >> set end pivot
> >> updates end metata
> >> Detects write to last slot
> >> last slot write is to start of slot
> >> store current contents in slot
> >> overwrite old end pivot
> >> mas_next_slot():
> >> read end metadata
> >> read old end pivot
> >> return with incorrect range
> >> store new value
> >>
> >> Alternatively:
> >>
> >> Writer: reader:
> >> mas_wr_append
> >> set end pivot
> >> updates end metata
> >> Detects write to last slot
> >> last lost write to end of slot
> >> store value
> >> mas_next_slot():
> >> read end metadata
> >> read old end pivot
> >> read new end pivot
> >> return with incorrect range
> >> set old end pivot
> >>
> >> There may be other accesses that are not safe since we are now updating
> >> both metadata and pointers, so disabling append if there could be rcu
> >> readers is the safest action.
> >>
> >> Fixes: 54a611b60590 ("Maple Tree: add new data structure")
> >> Cc: stable@vger.kernel.org
> >> Signed-off-by: Liam R. Howlett <Liam.Howlett@oracle.com>
> >
> > Thanks for your patch, which is now commit cfeb6ae8bcb96ccf
> > ("maple_tree: disable mas_wr_append() when other readers are
> > possible") in v6.5, and is being backported to stable.
> >
> > On Renesas RZ/A1 and RZ/A2 (single-core Cortex-A9), this causes the
> > following warning:
> >
> > clocksource: timer@e803b000: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 28958491609 ns
> > sched_clock: 32 bits at 66MHz, resolution 15ns, wraps every 32537631224ns
> > /soc/timer@e803b000: used for clocksource
> > /soc/timer@e803c000: used for clock events
> > +------------[ cut here ]------------
> > +WARNING: CPU: 0 PID: 0 at init/main.c:992 start_kernel+0x2f0/0x480
> > +Interrupts were enabled early
> ...
> >
> > I do not see this issue on any other platform
> > (arm/arm64/risc-v/mips/sh/m68k), several of them use the same
> > RCU configuration.
>
> There's something similar on pmac32 / mac99.
>
> > Do you have a clue?
>
> It seems something in the maple tree code is setting TIF_NEED_RESCHED,
> and that causes a subsequent call to cond_resched() to call schedule()
> and enable interrupts.
>
> On pmac32 enabling CONFIG_DEBUG_ATOMIC_SLEEP fixes/hides the problem.
> But I don't see why.
Enabling CONFIG_DEBUG_ATOMIC_SLEEP on RZ/A1 and RZ/A2 does
fix the problem.
But there must be more to it, as some of my test configs had it enabled,
and others hadn't, while only RZ/A showed the issue.
I tried disabling it on R-Car M2-W (arm32) and R-Car H3 (arm64), and
that did not cause the problem to happen...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
next prev parent reply other threads:[~2023-08-31 8:26 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-19 0:43 [PATCH v2 0/2] maple_tree: mas_wr_append() fix ups Liam R. Howlett
2023-08-19 0:43 ` [PATCH v2 1/2] maple_tree: Disable mas_wr_append() when other readers are possible Liam R. Howlett
2023-08-29 16:42 ` Geert Uytterhoeven
2023-08-31 5:39 ` Michael Ellerman
2023-08-31 8:25 ` Geert Uytterhoeven [this message]
2023-08-31 8:45 ` Peng Zhang
2023-08-31 9:43 ` Geert Uytterhoeven
2023-09-06 15:23 ` Liam R. Howlett
2023-09-06 17:23 ` Paul E. McKenney
2023-09-06 17:29 ` Liam R. Howlett
2023-09-06 18:02 ` Paul E. McKenney
2023-09-11 23:54 ` Liam R. Howlett
2023-09-12 8:14 ` Paul E. McKenney
2023-09-12 8:23 ` Geert Uytterhoeven
2023-09-12 8:30 ` Paul E. McKenney
2023-09-12 8:34 ` Geert Uytterhoeven
2023-09-12 10:00 ` Paul E. McKenney
2023-09-12 13:56 ` Liam R. Howlett
2023-09-12 14:29 ` Liam R. Howlett
2023-09-12 15:08 ` Paul E. McKenney
2023-09-12 15:27 ` Christophe Leroy
2023-09-12 15:49 ` Liam R. Howlett
2023-09-12 15:07 ` Paul E. McKenney
2023-09-12 15:44 ` Liam R. Howlett
2023-09-12 16:49 ` Paul E. McKenney
2023-09-12 17:02 ` Christophe Leroy
2023-09-12 17:09 ` Christophe Leroy
2023-09-12 17:38 ` Liam R. Howlett
2023-09-13 13:14 ` Geert Uytterhoeven
2023-09-13 13:24 ` Liam R. Howlett
2023-09-13 13:26 ` Geert Uytterhoeven
2023-09-12 14:37 ` Christophe Leroy
2023-09-12 14:10 ` Matthew Wilcox
2023-09-12 14:17 ` Liam R. Howlett
2023-09-06 19:06 ` Geert Uytterhoeven
2023-09-11 12:27 ` Linux regression tracking #adding (Thorsten Leemhuis)
2023-10-16 8:29 ` Linux regression tracking #update (Thorsten Leemhuis)
2023-08-30 19:49 ` Andreas Schwab
2023-08-31 5:37 ` Michael Ellerman
2023-08-31 19:01 ` Andreas Schwab
2023-09-12 18:15 ` Andreas Schwab
2023-09-12 19:09 ` Liam R. Howlett
2023-09-12 20:01 ` Andreas Schwab
2023-08-19 0:43 ` [PATCH v2 2/2] maple_tree: Clean up mas_wr_append() Liam R. Howlett
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='CAMuHMdXMpr0spdprjwsV56nJE3vHGTFaodcnVXUa=GMYaB5yKw@mail.gmail.com' \
--to=geert@linux-m68k.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=maple-tree@lists.infradead.org \
--cc=mpe@ellerman.id.au \
--cc=stable@vger.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