Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1227191 > unrolled thread

crisv32 runtime failure in -next due to 'page-flags: define behavior SL*B-related flags on compound pages'

Back to article view | Back to linux.kernel

Contents

  crisv32 runtime failure in -next due to 'page-flags: define behavior  SL*B-related flags on compound pages' Guenter Roeck <linux@roeck-us.net> - 2015-09-17 18:30 +0200
    Re: crisv32 runtime failure in -next due to 'page-flags: define  behavior SL*B-related flags on compound pages' "Kirill A. Shutemov" <kirill@shutemov.name> - 2015-09-18 16:30 +0200
      Re: crisv32 runtime failure in -next due to 'page-flags: define  behavior SL*B-related flags on compound pages' Jesper Nilsson <jesper.nilsson@axis.com> - 2015-09-18 17:00 +0200
        Re: crisv32 runtime failure in -next due to 'page-flags: define  behavior SL*B-related flags on compound pages' Guenter Roeck <linux@roeck-us.net> - 2015-09-18 17:20 +0200
          Re: crisv32 runtime failure in -next due to 'page-flags: define  behavior SL*B-related flags on compound pages' "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2015-09-21 18:00 +0200
            Re: crisv32 runtime failure in -next due to 'page-flags: define  behavior SL*B-related flags on compound pages' Guenter Roeck <linux@roeck-us.net> - 2015-09-22 03:20 +0200

#1227191 — crisv32 runtime failure in -next due to 'page-flags: define behavior SL*B-related flags on compound pages'

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.

Bisect points to 'page-flags: define behavior SL*B-related flags on compound pages'.

One of the bisect steps, at 'mm: support madvise(MADV_FREE)', causes a build failure,
but that did not seem to affect the overall bisect results. Just for completeness,
here is the reported build failure.

mm/vmscan.c: In function ‘shrink_page_list’:
mm/vmscan.c:1093:5: error: implicit declaration of function ‘__clear_page_locked’ [-Werror=implicit-function-declaration]
      __clear_page_locked(page);
      ^

Guenter

---
Bisect log:

# bad: [01c8787d7f7ea56c16d94cf7133022189be231ad] Add linux-next specific files for 20150917
# good: [6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f] Linux 4.3-rc1
git bisect start 'HEAD' 'v4.3-rc1'
# good: [5b986ec423c0e7615824a46b48e6d5cfa45ac82d] Merge remote-tracking branch 'battery/master'
git bisect good 5b986ec423c0e7615824a46b48e6d5cfa45ac82d
# good: [d4cb33477f815c8a0c8b1c28e986c79d89d37491] Merge remote-tracking branch 'staging/staging-next'
git bisect good d4cb33477f815c8a0c8b1c28e986c79d89d37491
# good: [b73c6555e0733dc811d6f7b533183c518d6c7bb2] Merge remote-tracking branch 'livepatching/for-next'
git bisect good b73c6555e0733dc811d6f7b533183c518d6c7bb2
# good: [5c74cd46dcbc65a682b2bdfc74d51feac91c0e0f] mm-introduce-vm_lockonfault-v9
git bisect good 5c74cd46dcbc65a682b2bdfc74d51feac91c0e0f
# bad: [b928350d7f112a2525516c444ebac84ed53e937e] mm: support madvise(MADV_FREE)
git bisect bad b928350d7f112a2525516c444ebac84ed53e937e
# good: [8129659afb03679ae08e6bc862c78bc571a10170] page-flags-introduce-page-flags-policies-wrt-compound-pages-fix
git bisect good 8129659afb03679ae08e6bc862c78bc571a10170
# bad: [f285037c71068de549f2432c9d275844575707de] page-flags: look at head page if the flag is encoded in page->mapping
git bisect bad f285037c71068de549f2432c9d275844575707de
# bad: [ceba84a8eac816c92d1f1789b1273f812ac9af80] page-flags: define PG_reserved behavior on compound pages
git bisect bad ceba84a8eac816c92d1f1789b1273f812ac9af80
# good: [40774838143f84a5c38ecee2f142bbd6b9a0687a] page-flags: define behavior of LRU-related flags on compound pages
git bisect good 40774838143f84a5c38ecee2f142bbd6b9a0687a
# bad: [fcd079cce0714accc45d35ffad59bf05ddb37893] page-flags: define behavior of Xen-related flags on compound pages
git bisect bad fcd079cce0714accc45d35ffad59bf05ddb37893
# bad: [2c42f049fc7aa8198514707bce436c7f9f2c318f] page-flags: define behavior SL*B-related flags on compound pages
git bisect bad 2c42f049fc7aa8198514707bce436c7f9f2c318f
# first bad commit: [2c42f049fc7aa8198514707bce436c7f9f2c318f] page-flags: define behavior SL*B-related flags on compound pages
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1227919 — Re: crisv32 runtime failure in -next due to 'page-flags: define behavior SL*B-related flags on compound pages'

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?

-- 
 Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1227959 — Re: crisv32 runtime failure in -next due to 'page-flags: define behavior SL*B-related flags on compound pages'

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.

/^JN - Jesper Nilsson
-- 
               Jesper Nilsson -- jesper.nilsson@axis.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1228040 — Re: crisv32 runtime failure in -next due to 'page-flags: define behavior SL*B-related flags on compound pages'

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!
Linux 4.3.0-rc1-next-20150918 #1 Fri Sep 18 08:07:55 PDT 2015
Oops: 0000
CPU: 0
ERP: c0074c00 SRP: c0074c1e  CCS: 00009408 USP: 00000000 MOF: 00000000
  r0: 0000002a  r1: ffffe000   r2: c000f2ca  r3: c0074e40
  r4: c0033d00  r5: 0000000a   r6: 00000009  r7: 00000100
  r8: 0000000a  r9: c04a3254  r10: c1e97765 r11: c1fc1282
r12: c04a3240 r13: 00000000 oR10: c1e97765 acr: 00000001
  sp: c046458c
        Data MMU Cause: 00000000
Instruction MMU Cause: 00000000
Process ksoftirqd/0 (pid: 3, stackpage=c1feb3a0)

Stack from c1ff3e80:

c0004a0e c004ba7c
c04645e0 00000000
c04645d8 0000000a
c00059e8 00000001

        00000000
c046458c 00000000
c0341cfc c004ba7c
c0033d00 c0004b52
0000002a

ffffe000 c000f2ca
c0074e40 c0005898
c0074c1e c1e97765
c0074c1e c0033bd2

Call Trace: [<c0004a0e>] show_stack+0x0/0x9e
[<c004ba7c>] printk+0x0/0x2c
[<c00059e8>] show_registers+0x14a/0x1c2
[<c004ba7c>] printk+0x0/0x2c
[<c0033d00>] rcu_bh_qs+0x0/0x30
[<c0004b52>] die_if_kernel+0x7c/0x9e
[<c000f2ca>] __local_bh_enable_ip+0x0/0xb0
[<c0074e40>] kfree+0x0/0x82
[<c0005898>] do_BUG+0x2a/0x30
[<c0074c1e>] kmem_rcu_free+0x18/0x1e
[<c0074c1e>] kmem_rcu_free+0x18/0x1e
[<c0033bd2>] __rcu_process_callbacks+0x80/0xaa
[<c0033b52>] __rcu_process_callbacks+0x0/0xaa
[<c0033c14>] rcu_process_callbacks+0x18/0x2a
[<c000f15e>] __do_softirq+0xbc/0x1c2
[<c002008c>] kthread_should_stop+0x0/0x18
[<c00200a4>] kthread_should_park+0x0/0x18
[<c02d5f5e>] schedule+0x0/0x7c
[<c000f286>] run_ksoftirqd+0x22/0x32
[<c00228e8>] smpboot_thread_fn+0xe4/0x12c
[<c0022804>] smpboot_thread_fn+0x0/0x12c
[<c0028e88>] __init_waitqueue_head+0x0/0x8
[<c002048e>] kthread+0xb6/0xce
[<c00203d8>] kthread+0x0/0xce
[<c00055fa>] ret_from_kernel_thread+0xe/0x14

Code: 2a d6 6d da 87 d3 65 70 b0 05 3e e9 (7f) d2 65 e0 29 d6 84 e2 7e ba 6a c6
---[ end trace cc289b1d61e6a9a8 ]---

Kernel panic - not syncing: Aiee, killing interrupt handler!
CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 4.3.0-rc1-next-20150918 #1

Stack from c1ff3e28:

c1feb3a0 0000000b
c0341cfc c004ba7c
c0033d00 0000000a
c0177e2c c004b8fa

        c1feb3a0
0000000b c0341cfc
c004ba7c c0033d00
0000000a 00000009
c000dd54

c0342a14 00000000
00000061 00000000
c046458c 00000000
c0341cfc c004ba7c

Call Trace: [<c004ba7c>] printk+0x0/0x2c
[<c0033d00>] rcu_bh_qs+0x0/0x30
[<c0177e2c>] dump_stack+0x1c/0x22
[<c004b8fa>] panic+0x82/0x19c
[<c004ba7c>] printk+0x0/0x2c
[<c0033d00>] rcu_bh_qs+0x0/0x30
[<c000dd54>] do_exit+0x5e0/0x7da
[<c004ba7c>] printk+0x0/0x2c
[<c0033d00>] rcu_bh_qs+0x0/0x30
[<c004baa2>] printk+0x26/0x2c
[<c0004b6a>] die_if_kernel+0x94/0x9e
[<c0004b72>] die_if_kernel+0x9c/0x9e
[<c000f2ca>] __local_bh_enable_ip+0x0/0xb0
[<c0074e40>] kfree+0x0/0x82
[<c0005898>] do_BUG+0x2a/0x30
[<c0074c1e>] kmem_rcu_free+0x18/0x1e
[<c0074c1e>] kmem_rcu_free+0x18/0x1e
[<c0033bd2>] __rcu_process_callbacks+0x80/0xaa
[<c0033b52>] __rcu_process_callbacks+0x0/0xaa
[<c0033c14>] rcu_process_callbacks+0x18/0x2a
[<c000f15e>] __do_softirq+0xbc/0x1c2
[<c002008c>] kthread_should_stop+0x0/0x18
[<c00200a4>] kthread_should_park+0x0/0x18
[<c02d5f5e>] schedule+0x0/0x7c
[<c000f286>] run_ksoftirqd+0x22/0x32
[<c00228e8>] smpboot_thread_fn+0xe4/0x12c
[<c0022804>] smpboot_thread_fn+0x0/0x12c
[<c0028e88>] __init_waitqueue_head+0x0/0x8
[<c002048e>] kthread+0xb6/0xce
[<c00203d8>] kthread+0x0/0xce
[<c00055fa>] ret_from_kernel_thread+0xe/0x14
---[ end Kernel panic - not syncing: Aiee, killing interrupt handler!

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1229506 — Re: crisv32 runtime failure in -next due to 'page-flags: define behavior SL*B-related flags on compound pages'

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);
-- 
 Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1229867 — Re: crisv32 runtime failure in -next due to 'page-flags: define behavior SL*B-related flags on compound pages'

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 ?

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web