From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Guenter Roeck <linux@roeck-us.net>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Mikael Starvik <starvik@axis.com>,
Jesper Nilsson <jespern@axis.com>,
Hugh Dickins <hughd@google.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Minchan Kim <minchan@kernel.org>,
linux-cris-kernel@axis.com
Subject: Re: crisv32 runtime failure in -next due to 'page-flags: define behavior SL*B-related flags on compound pages'
Date: Tue, 22 Sep 2015 15:03:44 +0300 [thread overview]
Message-ID: <20150922120344.GA17969@node.dhcp.inet.fi> (raw)
In-Reply-To: <5600AC2E.8050701@roeck-us.net>
On Mon, Sep 21, 2015 at 06:17:34PM -0700, Guenter Roeck wrote:
> On 09/21/2015 08:34 AM, Kirill A. Shutemov wrote:
> >Guenter Roeck wrote:
> >>On 09/18/2015 07:53 AM, Jesper Nilsson wrote:
> >>>On Fri, Sep 18, 2015 at 05:25:07PM +0300, Kirill A. Shutemov wrote:
> >>>>On Thu, Sep 17, 2015 at 09:29:27AM -0700, Guenter Roeck wrote:
> >>>>>Hi,
> >>>>>
> >>>>>my crisv32 qemu test fails with next-20150917 as follows.
> >>>>>
> >>>>>NET: Registered protocol family 16
> >>>>>kernel BUG at mm/slab.c:1648!
> >>>>>Linux 4.3.0-rc1-next-20150917 #1 Wed Sep 16 23:56:59 PDT 2015
> >>>>>Oops: 0000
> >>>>>
> >>>>>[ register dump follows ]
> >>>>>
> >>>>>See http://server.roeck-us.net:8010/builders/qemu-crisv32-next/builds/83/steps/qemubuildcommand/logs/stdio
> >>>>>for a complete log.
> >>>>
> >>>>Is there a chance to get proper backtrace?
> >>>
> >>>Yes, it should be possible with CONFIG_KALLSYMS=y in the kconfig.
> >>>
> >>
> >>Good to know. I added it to my configuration.
> >>
> >>Here it is:
> >>
> >>kernel BUG at mm/slab.c:1648!
> >
> >I still don't understand what's going on :(
> >Could you try with this instrumentation:
> >
> >diff --git a/mm/slab.c b/mm/slab.c
> >index ce9c6531e6f7..10035d1a06d3 100644
> >--- a/mm/slab.c
> >+++ b/mm/slab.c
> >@@ -1645,7 +1645,11 @@ static void kmem_freepages(struct kmem_cache *cachep, struct page *page)
> > sub_zone_page_state(page_zone(page),
> > NR_SLAB_UNRECLAIMABLE, nr_freed);
> >
> >- BUG_ON(!PageSlab(page));
> >+ if (!PageSlab(page)) {
> >+ dump_page(page, "page");
> >+ dump_page(compound_head(page), "compound_head(page)");
> >+ BUG();
> >+ }
> > __ClearPageSlabPfmemalloc(page);
> > __ClearPageSlab(page);
> > page_mapcount_reset(page);
> >
>
> page:c04a5340 count:1 mapcount:1 mapping:c1f34080 index:0xc1f34060
> flags: 0x80(slab)
> page dumped because: page
> page:c1f17a04 count:0 mapcount:1 mapping:00d13600 index:0xc0
> flags: 0x0()
> page dumped because: compound_head(page)
>
> Does that help ?
Kinda. It's false positive PageTail() due low bit set in
page->rcu_head.next.
It happens (at least) due broken alignment of 'rcu' field within
task_struct -- offsetof(struct task_struct, rcu): 773.
That's looks veery broken. I would guess compiler does something horribly
wrong. I hope it's not an ABI issue. :-/
Mikael? Jesper?
--
Kirill A. Shutemov
next prev parent reply other threads:[~2015-09-22 12:03 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-17 16:29 crisv32 runtime failure in -next due to 'page-flags: define behavior SL*B-related flags on compound pages' Guenter Roeck
2015-09-18 14:25 ` Kirill A. Shutemov
2015-09-18 14:53 ` Jesper Nilsson
2015-09-18 15:13 ` Guenter Roeck
2015-09-21 15:34 ` Kirill A. Shutemov
2015-09-22 1:17 ` Guenter Roeck
2015-09-22 12:03 ` Kirill A. Shutemov [this message]
2015-09-22 12:19 ` Mikael Starvik
2015-09-22 12:50 ` Hans-Peter Nilsson
2015-09-22 13:27 ` Kirill A. Shutemov
2015-09-22 13:57 ` Hans-Peter Nilsson
2015-09-22 15:18 ` Paul E. McKenney
2015-09-22 15:31 ` Kirill A. Shutemov
2015-09-22 15:40 ` Paul E. McKenney
2015-09-23 10:53 ` Kirill A. Shutemov
2015-09-23 15:02 ` Guenter Roeck
2015-09-24 4:45 ` Paul E. McKenney
2015-09-22 16:16 ` Hans-Peter Nilsson
2015-09-22 16:39 ` 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=20150922120344.GA17969@node.dhcp.inet.fi \
--to=kirill@shutemov.name \
--cc=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=jespern@axis.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-cris-kernel@axis.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=minchan@kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=starvik@axis.com \
/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).