From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Joel Fernandes <joel@joelfernandes.org>
Cc: kernel test robot <rong.a.chen@intel.com>,
LKML <linux-kernel@vger.kernel.org>,
Stephen Rothwell <sfr@canb.auug.org.au>,
lkp@01.org
Subject: Re: [LKP] [rcutorture] 3b745c8969: WARNING:at_mm/slab_common.c:#kmalloc_slab
Date: Thu, 26 Jul 2018 20:14:26 -0700 [thread overview]
Message-ID: <20180727031426.GU24813@linux.vnet.ibm.com> (raw)
In-Reply-To: <20180726233436.GA211260@joelaf.mtv.corp.google.com>
On Thu, Jul 26, 2018 at 04:34:36PM -0700, Joel Fernandes wrote:
> On Thu, Jul 26, 2018 at 04:53:25AM -0700, Paul E. McKenney wrote:
> > On Thu, Jul 26, 2018 at 04:50:15PM +0800, kernel test robot wrote:
> > >
> > > FYI, we noticed the following commit (built with gcc-5):
> > >
> > > commit: 3b745c8969c752601cb68c82a06735363563ab42 ("rcutorture: Make boost test more robust")
> > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
> > >
> > > in testcase: boot
> > >
> > > on test machine: qemu-system-x86_64 -enable-kvm -smp 2 -m 512M
> > >
> > > caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
> >
> > Is this fixed by 4babd855fd61 ("rcutorture: Add support to detect
> > if boost kthread prio is too low")? That could address the
> > rcu_torture_stats_print() failures, depending on exactly what they were.
> > (Yes, I should have reversed these two commits, but they are in -tip
> > now, so that ship has sailed.)
> >
> > Joel, any other thoughts?
>
> I ran the next tree myself and was not able to reproduce the issue with the
> same configuration. Although I don't have rcupdate.rcu_cpu_stall_timeout=100
> passed in like they do (which I can also try if you think its of significance
> here).
>
> It seems from their logs that most Locking API self tests are failing. the
> Lock API test suite is run before rcutorture where rcutorture hasn't even
> started.
>
> Also as per their rcutorture output, it appears the 'rtf' value is also
> non-zero (rcu_torture_free test). Which makes sense if the earlier memory
> allocation warnings are somehow related.
It could potentially be an OOM issue. Something to keep an eye out for,
then.
Thanx, Paul
prev parent reply other threads:[~2018-07-27 3:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-26 8:50 [LKP] [rcutorture] 3b745c8969: WARNING:at_mm/slab_common.c:#kmalloc_slab kernel test robot
2018-07-26 11:53 ` Paul E. McKenney
2018-07-26 17:39 ` Joel Fernandes
2018-07-26 23:34 ` Joel Fernandes
2018-07-27 3:14 ` Paul E. McKenney [this message]
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=20180727031426.GU24813@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@01.org \
--cc=rong.a.chen@intel.com \
--cc=sfr@canb.auug.org.au \
/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).