From: Michael Cree <mcree@orcon.net.nz>
To: Matt Turner <mattst88@gmail.com>
Cc: Kees Cook <keescook@chromium.org>,
Linux-Arch <linux-arch@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-alpha <linux-alpha@vger.kernel.org>,
Richard Henderson <rth@twiddle.net>,
Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Subject: Re: Regression bisected to f2f84b05e02b (bug: consolidate warn_slowpath_fmt() usage)
Date: Fri, 12 Jun 2020 16:47:57 +1200 [thread overview]
Message-ID: <20200612044757.GA10703@tower> (raw)
In-Reply-To: <CAEdQ38F2GP92xB2gMXTrEo-Adbbc9Cy1DWHU9yveGLzJNd2HrA@mail.gmail.com>
On Thu, Jun 11, 2020 at 09:23:52PM -0700, Matt Turner wrote:
> Since I noticed earlier that using maxcpus=1 on a 2-CPU system
> prevented the system from hanging, I tried disabling CONFIG_SMP on my
> 1-CPU system as well. In doing so, I discovered that the RCU torture
> module (RCU_TORTURE_TEST) triggers some null pointer dereferences on
> Alpha when CONFIG_SMP is set, but works successfully when CONFIG_SMP
> is unset.
>
> That seems likely to be a symptom of the same underlying problem that
> started this thread, don't you think? If so, I'll focus my attention
> on that.
I wonder if that is related to user space segfaults we are now seeing
on SMP systems but not UP systems while building Alpha debian-ports.
It's happening in the test-suites of builds of certain software
(such as autogen and guile) but they always build successfully with
the test suite passing on a UP system.
When investigating I seem to recall it was a NULL (or near NULL)
pointer dereference but couldn't make any sense of how it might
have got into such an obviously wrong state.
Cheers,
Michael.
next prev parent reply other threads:[~2020-06-12 4:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-02 2:48 Regression bisected to f2f84b05e02b (bug: consolidate warn_slowpath_fmt() usage) Matt Turner
2020-06-02 18:03 ` Kees Cook
2020-06-12 4:23 ` Matt Turner
2020-06-12 4:47 ` Michael Cree [this message]
2020-06-12 5:07 ` Kees Cook
2024-05-21 18:46 ` John Paul Adrian Glaubitz
2024-05-23 23:49 ` Kees Cook
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=20200612044757.GA10703@tower \
--to=mcree@orcon.net.nz \
--cc=ink@jurassic.park.msu.ru \
--cc=keescook@chromium.org \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mattst88@gmail.com \
--cc=rth@twiddle.net \
/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).