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

Groups > linux.kernel > #1380892 > unrolled thread

Re: [lkp] [parallel lookups machinery, part 2] 96352435af: kernel BUG at mm/slab.c:2599!

Started byAl Viro <viro@ZenIV.linux.org.uk>
First post2016-04-18 04:00 +0200
Last post2016-04-18 13:20 +0200
Articles 5 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [lkp] [parallel lookups machinery, part 2] 96352435af: kernel  BUG at mm/slab.c:2599! Al Viro <viro@ZenIV.linux.org.uk> - 2016-04-18 04:00 +0200
    Re: [LKP] [lkp] [parallel lookups machinery, part 2] 96352435af: kernel BUG at mm/slab.c:2599! "Huang\, Ying" <ying.huang@intel.com> - 2016-04-18 04:10 +0200
      Re: [LKP] [lkp] [parallel lookups machinery, part 2] 96352435af:  kernel BUG at mm/slab.c:2599! Al Viro <viro@ZenIV.linux.org.uk> - 2016-04-18 04:20 +0200
        Re: [LKP] [lkp] [parallel lookups machinery, part 2] 96352435af: kernel BUG at mm/slab.c:2599! "Huang\, Ying" <ying.huang@intel.com> - 2016-04-18 09:20 +0200
          Re: [LKP] [lkp] [parallel lookups machinery, part 2] 96352435af:  kernel BUG at mm/slab.c:2599! Al Viro <viro@ZenIV.linux.org.uk> - 2016-04-18 13:20 +0200

#1380892 — Re: [lkp] [parallel lookups machinery, part 2] 96352435af: kernel BUG at mm/slab.c:2599!

FromAl Viro <viro@ZenIV.linux.org.uk>
Date2016-04-18 04:00 +0200
SubjectRe: [lkp] [parallel lookups machinery, part 2] 96352435af: kernel BUG at mm/slab.c:2599!
Message-ID<rp6DN-5xU-11@gated-at.bofh.it>
On Mon, Apr 18, 2016 at 09:06:35AM +0800, kernel test robot wrote:
> FYI, we noticed the below changes on
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git testing.lookups
> commit 96352435afd792d713ec91e2d5693bdcf40a6b03 ("parallel lookups machinery, part 2")

Very odd.  All stores in that commit are to ->d_parent->d_inode->i_dir_seq
of in-lookup dentries.  And if ->d_parent in those gets buggered, we were
really deep in trouble.  Could you try to reproduce that without __d_move()
or __d_add() parts and see which one ends up triggering that crap?

Note that we don't *use* ->i_dir_seq yet...

[toc] | [next] | [standalone]

#1380896 — Re: [LKP] [lkp] [parallel lookups machinery, part 2] 96352435af: kernel BUG at mm/slab.c:2599!

From"Huang\, Ying" <ying.huang@intel.com>
Date2016-04-18 04:10 +0200
SubjectRe: [LKP] [lkp] [parallel lookups machinery, part 2] 96352435af: kernel BUG at mm/slab.c:2599!
Message-ID<rp6Nr-5VO-7@gated-at.bofh.it>
In reply to#1380892
Al Viro <viro@ZenIV.linux.org.uk> writes:

> On Mon, Apr 18, 2016 at 09:06:35AM +0800, kernel test robot wrote:
>> FYI, we noticed the below changes on
>> 
>> https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git testing.lookups
>> commit 96352435afd792d713ec91e2d5693bdcf40a6b03 ("parallel lookups machinery, part 2")
>
> Very odd.  All stores in that commit are to ->d_parent->d_inode->i_dir_seq
> of in-lookup dentries.  And if ->d_parent in those gets buggered, we were
> really deep in trouble.  Could you try to reproduce that without __d_move()
> or __d_add() parts and see which one ends up triggering that crap?

Could you provide a debug branch in your tree for that?

Best Regards,
Huang, Ying

> Note that we don't *use* ->i_dir_seq yet...
> _______________________________________________
> LKP mailing list
> LKP@lists.01.org
> https://lists.01.org/mailman/listinfo/lkp

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

#1380903 — Re: [LKP] [lkp] [parallel lookups machinery, part 2] 96352435af: kernel BUG at mm/slab.c:2599!

FromAl Viro <viro@ZenIV.linux.org.uk>
Date2016-04-18 04:20 +0200
SubjectRe: [LKP] [lkp] [parallel lookups machinery, part 2] 96352435af: kernel BUG at mm/slab.c:2599!
Message-ID<rp6X8-66A-15@gated-at.bofh.it>
In reply to#1380896
On Mon, Apr 18, 2016 at 10:08:37AM +0800, Huang, Ying wrote:

> Could you provide a debug branch in your tree for that?

Done - vfs.git#T1 and vfs.git#T2 resp.

How reproducible it is and how certain you are that it's not there on
the parent commit?

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

#1381322 — Re: [LKP] [lkp] [parallel lookups machinery, part 2] 96352435af: kernel BUG at mm/slab.c:2599!

From"Huang\, Ying" <ying.huang@intel.com>
Date2016-04-18 09:20 +0200
SubjectRe: [LKP] [lkp] [parallel lookups machinery, part 2] 96352435af: kernel BUG at mm/slab.c:2599!
Message-ID<rpbDr-1sC-3@gated-at.bofh.it>
In reply to#1380903
Al Viro <viro@ZenIV.linux.org.uk> writes:

Hi, Viro,

> On Mon, Apr 18, 2016 at 10:08:37AM +0800, Huang, Ying wrote:
>
>> Could you provide a debug branch in your tree for that?
>
> Done - vfs.git#T1 and vfs.git#T2 resp.

The compare result between T1 and T2 is as follow:

=========================================================================================
compiler/kconfig/rootfs/sleep/tbox_group/testcase:
  gcc-5/x86_64-allyesdebian/quantal-core-x86_64.cgz/1/vm-vp-quantal-x86_64/boot

commit: 
  3ab6378a68555a90a11360e2f2d63c9adb4e7101 (T1)
  e570d87b645a0bfd80e36df9753faf3598c9fce0 (T2)

3ab6378a68555a90 e570d87b645a0bfd80e36df975 
---------------- -------------------------- 
       fail:runs  %reproduction    fail:runs
           |             |             |    
         47:47        -100%            :3     dmesg.Kernel_panic-not_syncing:Fatal_exception_in_interrupt
         47:47        -100%            :3     dmesg.RIP:kfree_debugcheck
         47:47        -100%            :3     dmesg.invalid_opcode:#[##]SMP
         47:47        -100%            :3     dmesg.kernel_BUG_at_mm/slab.c
          7:47         -15%            :3     kmsg.APIC_calibration_not_consistent_with_PM-Timer:#ms_instead_of#ms
          1:47          -2%            :3     kmsg.kfree_debugcheck:out_of_range_ptr#a8h
          7:47         -15%            :3     kmsg.kfree_debugcheck:out_of_range_ptr#aah
         21:47         -45%            :3     kmsg.kfree_debugcheck:out_of_range_ptr#ach
          1:47          -2%            :3     kmsg.kfree_debugcheck:out_of_range_ptr#bah
          2:47          -4%            :3     kmsg.kfree_debugcheck:out_of_range_ptr#ch
          4:47          -9%            :3     kmsg.kfree_debugcheck:out_of_range_ptr#eh
         11:47         -23%            :3     kmsg.kfree_debugcheck:out_of_range_ptr#h

That is, there is same issue for T1, but no such issue for T2.

> How reproducible it is and how certain you are that it's not there on
> the parent commit?

The result is quite stable for tens tests for parents and the first bad
commit.

Best Regards,
Huang, Ying

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

#1381578 — Re: [LKP] [lkp] [parallel lookups machinery, part 2] 96352435af: kernel BUG at mm/slab.c:2599!

FromAl Viro <viro@ZenIV.linux.org.uk>
Date2016-04-18 13:20 +0200
SubjectRe: [LKP] [lkp] [parallel lookups machinery, part 2] 96352435af: kernel BUG at mm/slab.c:2599!
Message-ID<rpfnI-4BZ-25@gated-at.bofh.it>
In reply to#1381322
On Mon, Apr 18, 2016 at 03:12:47PM +0800, Huang, Ying wrote:

> That is, there is same issue for T1, but no such issue for T2.
> 
> > How reproducible it is and how certain you are that it's not there on
> > the parent commit?
> 
> The result is quite stable for tens tests for parents and the first bad
> commit.

Nuts...  Try vfs.git#T3, please - the only way this could cause memory
corruption, AFAICS, is some really weird caller of d_add() or d_splice_alias(),
passing it a dentry with bogus ->d_parent...

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web