All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
To: lkp@lists.01.org
Subject: Re: [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>

[-- Attachment #1: Type: text/plain, Size: 1775 bytes --]

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


WARNING: multiple messages have this Message-ID (diff)
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


  reply	other threads:[~2018-07-27  3:14 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-26  8:50 [rcutorture] 3b745c8969: WARNING:at_mm/slab_common.c:#kmalloc_slab kernel test robot
2018-07-26  8:50 ` [LKP] " kernel test robot
2018-07-26 11:53 ` Paul E. McKenney
2018-07-26 11:53   ` [LKP] " 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]
2018-07-27  3:14       ` Paul E. McKenney

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=lkp@lists.01.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.