From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Atish Patra <atishp@atishpatra.org>
Cc: Atish Patra <atishp@rivosinc.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Anup Patel <anup@brainfault.org>,
Albert Ou <aou@eecs.berkeley.edu>,
Damien Le Moal <damien.lemoal@wdc.com>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>, Jisheng Zhang <jszhang@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>,
linux-riscv <linux-riscv@lists.infradead.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Rob Herring <robh+dt@kernel.org>,
Emil Renner Berthing <kernel@esmil.dk>
Subject: Re: [PATCH v3 6/6] RISC-V: Do not use cpumask data structure for hartid bitmap
Date: Tue, 25 Jan 2022 21:52:23 +0100 [thread overview]
Message-ID: <CAMuHMdWBF0XXXQLfAH81F=BczjsDeQFU454_A2C_-qLPKJGpiQ@mail.gmail.com> (raw)
In-Reply-To: <CAOnJCULjqeL9Q27n=g19ALbOivzid6pc_gYv6JUF4iP=64kJ-Q@mail.gmail.com>
Hi Atish,
On Tue, Jan 25, 2022 at 9:17 PM Atish Patra <atishp@atishpatra.org> wrote:
> On Tue, Jan 25, 2022 at 12:12 PM Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > On Thu, Jan 20, 2022 at 10:12 AM Atish Patra <atishp@rivosinc.com> wrote:
> > > Currently, SBI APIs accept a hartmask that is generated from struct
> > > cpumask. Cpumask data structure can hold upto NR_CPUs value. Thus, it
> > > is not the correct data structure for hartids as it can be higher
> > > than NR_CPUs for platforms with sparse or discontguous hartids.
> > >
> > > Remove all association between hartid mask and struct cpumask.
> > >
> > > Reviewed-by: Anup Patel <anup@brainfault.org> (For Linux RISC-V changes)
> > > Acked-by: Anup Patel <anup@brainfault.org> (For KVM RISC-V changes)
> > > Signed-off-by: Atish Patra <atishp@rivosinc.com>
> >
> > Thanks for your patch, which is now commit 26fb751ca37846c9 ("RISC-V:
> > Do not use cpumask data structure for hartid bitmap") in v5.17-rc1.
> >
> > I am having an issue with random userspace SEGVs on Starlight Beta
> > (which needs out-of-tree patches). It doesn't always manifest
> > itself immediately, so it took a while to bisect, but I suspect the
> > above commit to be the culprit.
>
> I have never seen one before during my testing. How frequently do you see them?
> Does it happen while running anything or just idle user space results
> in SEGVs randomly.
Sometimes they happen during startup (lots of failures from systemd),
sometimes they happen later, during interactive work.
Sometimes while idle, and something runs in the background (e.g. mandb).
> Do you have a trace that I can look into ?
# apt update
[ 807.499050] apt[258]: unhandled signal 11 code 0x1 at
0xffffff8300060020 in libapt-pkg.so.6.0.0[3fa49ac000+174000]
[ 807.509548] CPU: 0 PID: 258 Comm: apt Not tainted
5.16.0-starlight-11192-g26fb751ca378-dirty #153
[ 807.518674] Hardware name: BeagleV Starlight Beta (DT)
[ 807.524077] epc : 0000003fa4a47a0a ra : 0000003fa4a479fc sp :
0000003fcb4b39b0
[ 807.531383] gp : 0000002adcef4800 tp : 0000003fa43287b0 t0 :
0000000000000001
[ 807.538603] t1 : 0000000000000009 t2 : 00000000000003ff s0 :
0000000000000000
[ 807.545887] s1 : 0000002adcf3cb60 a0 : 0000000000000003 a1 :
0000000000000000
[ 807.553167] a2 : 0000003fcb4b3a30 a3 : 0000000000000000 a4 :
0000002adcf3cc1c
[ 807.560390] a5 : 0007000300060000 a6 : 0000000000000003 a7 :
1999999999999999
[ 807.567654] s2 : 0000003fcb4b3a28 s3 : 0000000000000002 s4 :
0000003fcb4b3a30
[ 807.575039] s5 : 0000003fa4baa810 s6 : 0000000000000010 s7 :
0000002adcf19a40
[ 807.582363] s8 : 0000003fcb4b4010 s9 : 0000003fa4baa810 s10:
0000003fcb4b3e90
[ 807.589606] s11: 0000003fa4b2a528 t3 : 0000000000000000 t4 :
0000003fa47906a0
[ 807.596891] t5 : 0000000000000005 t6 : ffffffffffffffff
[ 807.602302] status: 0000000200004020 badaddr: ffffff8300060020
cause: 000000000000000d
(-dirty due to Starlight DTS and driver updates)
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:[~2022-01-25 20:53 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-20 9:09 [PATCH v3 0/6] Sparse HART id support Atish Patra
2022-01-20 9:09 ` [PATCH v3 1/6] RISC-V: Avoid using per cpu array for ordered booting Atish Patra
2022-01-20 9:09 ` [PATCH v3 2/6] RISC-V: Do not print the SBI version during HSM extension boot print Atish Patra
2022-01-20 9:09 ` [PATCH v3 3/6] RISC-V: Use __cpu_up_stack/task_pointer only for spinwait method Atish Patra
2022-01-20 9:09 ` [PATCH v3 5/6] RISC-V: Move spinwait booting method to its own config Atish Patra
2022-01-20 9:09 ` [PATCH v3 6/6] RISC-V: Do not use cpumask data structure for hartid bitmap Atish Patra
2022-01-25 20:12 ` Geert Uytterhoeven
2022-01-25 20:17 ` Atish Patra
2022-01-25 20:52 ` Geert Uytterhoeven [this message]
2022-01-25 21:11 ` Ron Economos
2022-01-25 22:26 ` Jessica Clarke
2022-01-25 22:29 ` David Laight
2022-01-26 2:21 ` Atish Patra
2022-01-26 8:28 ` Geert Uytterhoeven
2022-01-26 9:10 ` Geert Uytterhoeven
2022-01-27 1:01 ` Atish Patra
2022-01-27 8:48 ` Geert Uytterhoeven
2022-01-27 8:48 ` Geert Uytterhoeven
2022-01-27 10:03 ` Geert Uytterhoeven
2022-01-27 10:17 ` Andreas Schwab
[not found] ` <CAOnJCU+U0xmw-_yTEUo9ZXO5pvoJ6VCGu+jjU-Sa2MnhcAha6Q@mail.gmail.com>
2022-01-28 8:39 ` Geert Uytterhoeven
2022-01-28 8:55 ` Geert Uytterhoeven
2022-01-31 12:09 ` Anup Patel
2022-01-31 13:27 ` Geert Uytterhoeven
2022-01-27 9:56 ` Ron Economos
2022-01-31 8:35 ` Anup Patel
2022-01-20 18:17 ` [PATCH v3 0/6] Sparse HART id support Palmer Dabbelt
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='CAMuHMdWBF0XXXQLfAH81F=BczjsDeQFU454_A2C_-qLPKJGpiQ@mail.gmail.com' \
--to=geert@linux-m68k.org \
--cc=anup@brainfault.org \
--cc=aou@eecs.berkeley.edu \
--cc=atishp@atishpatra.org \
--cc=atishp@rivosinc.com \
--cc=damien.lemoal@wdc.com \
--cc=devicetree@vger.kernel.org \
--cc=jszhang@kernel.org \
--cc=kernel@esmil.dk \
--cc=krzysztof.kozlowski@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=robh+dt@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;
as well as URLs for NNTP newsgroup(s).