Re: BUG: memcmp(): Accessing invalid memory location
On Thursday, February 7, 2019 5:27:09 AM IST Michael Ellerman wrote: > Chandan Rajendra writes: > > On Wednesday, February 6, 2019 5:20:04 PM IST Michael Ellerman wrote: > >> Chandan Rajendra writes: > >> > On Friday, February 1, 2019 4:43:52 PM IST Michael Ellerman wrote: > >> >> Michael Ellerman writes: > >> >> > >> >> > Adding Simon who wrote the code. > >> >> > > >> >> > Chandan Rajendra writes: > >> >> >> When executing fstests' generic/026 test, I hit the following call > >> >> >> trace, > >> >> >> > >> >> >> [ 417.061038] BUG: Unable to handle kernel data access at > >> >> >> 0xc0062ac4 > >> >> >> [ 417.062172] Faulting instruction address: 0xc0092240 > >> >> >> [ 417.062242] Oops: Kernel access of bad area, sig: 11 [#1] > >> >> >> [ 417.062299] LE SMP NR_CPUS=2048 DEBUG_PAGEALLOC NUMA pSeries > >> >> >> [ 417.062366] Modules linked in: > >> >> >> [ 417.062401] CPU: 0 PID: 27828 Comm: chacl Not tainted > >> >> >> 5.0.0-rc2-next-20190115-1-g6de6dba64dda #1 > >> >> >> [ 417.062495] NIP: c0092240 LR: c066a55c CTR: > >> >> >> > >> >> >> [ 417.062567] REGS: c0062c0c3430 TRAP: 0300 Not tainted > >> >> >> (5.0.0-rc2-next-20190115-1-g6de6dba64dda) > >> >> >> [ 417.062660] MSR: 82009033 > >> >> >> CR: 44000842 XER: 2000 > >> >> >> [ 417.062750] CFAR: 7fff7f3108ac DAR: c0062ac4 DSISR: > >> >> >> 4000 IRQMASK: 0 > >> >> >>GPR00: c0062c0c36c0 > >> >> >> c17f4c00 c121a660 > >> >> >>GPR04: c0062ac3fff9 0004 > >> >> >> 0020 275b19c4 > >> >> >>GPR08: 000c 46494c45 > >> >> >> 5347495f41434c5f c26073a0 > >> >> >>GPR12: c27a > >> >> >> > >> >> >>GPR16: > >> >> >> > >> >> >>GPR20: c0062ea70020 c0062c0c38d0 > >> >> >> 0002 0002 > >> >> >>GPR24: c0062ac3ffe8 275b19c4 > >> >> >> 0001 c0062ac3 > >> >> >>GPR28: c0062c0c38d0 c0062ac30050 > >> >> >> c0062ac30058 > >> >> >> [ 417.063563] NIP [c0092240] memcmp+0x120/0x690 > >> >> >> [ 417.063635] LR [c066a55c] > >> >> >> xfs_attr3_leaf_lookup_int+0x53c/0x5b0 > >> >> >> [ 417.063709] Call Trace: > >> >> >> [ 417.063744] [c0062c0c36c0] [c066a098] > >> >> >> xfs_attr3_leaf_lookup_int+0x78/0x5b0 (unreliable) > >> >> >> [ 417.063851] [c0062c0c3760] [c0693f8c] > >> >> >> xfs_da3_node_lookup_int+0x32c/0x5a0 > >> >> >> [ 417.063944] [c0062c0c3820] [c06634a0] > >> >> >> xfs_attr_node_addname+0x170/0x6b0 > >> >> >> [ 417.064034] [c0062c0c38b0] [c0664ffc] > >> >> >> xfs_attr_set+0x2ac/0x340 > >> >> >> [ 417.064118] [c0062c0c39a0] [c0758d40] > >> >> >> __xfs_set_acl+0xf0/0x230 > >> >> >> [ 417.064190] [c0062c0c3a00] [c0758f50] > >> >> >> xfs_set_acl+0xd0/0x160 > >> >> >> [ 417.064268] [c0062c0c3aa0] [c04b69b0] > >> >> >> set_posix_acl+0xc0/0x130 > >> >> >> [ 417.064339] [c0062c0c3ae0] [c04b6a88] > >> >> >> posix_acl_xattr_set+0x68/0x110 > >> >> >> [ 417.064412] [c0062c0c3b20] [c04532d4] > >> >> >> __vfs_setxattr+0xa4/0x110 > >> >> >> [ 417.064485] [c0062c0c3b80] [c0454c2c] > >> >> >> __vfs_setxattr_noperm+0xac/0x240 > >> >> >> [ 417.064566] [c0062c0c3bd0] [c0454ee8] > >> >> >> vfs_setxattr+0x128/0x130 > >> >> >> [ 417.064638] [c0062c0c3c30] [c0455138] > >> >> >> setxattr+0x248/0x600 > >> >> >> [ 417.064710] [c0062c0c3d90] [c0455738] > >> >> >> path_setxattr+0x108/0x120 > >> >> >> [ 417.064785] [c0062c0c3e00] [c0455778] > >> >> >> sys_setxattr+0x28/0x40 > >> >> >> [ 417.064858] [c0062c0c3e20] [c000bae4] > >> >> >> system_call+0x5c/0x70 > >> >> >> [ 417.064930] Instruction dump: > >> >> >> [ 417.064964] 7d201c28 7d402428 7c295040 38630008 38840008 408201f0 > >> >> >> 4200ffe8 2c05 > >> >> >> [ 417.065051] 4182ff6c 20c50008 54c61838 7d201c28 <7d402428> > >> >> >> 7d293436 7d4a3436 7c295040 > >> >> >> [ 417.065150] ---[ end trace 0d060411b5e3741b ]--- > >> >> >> > >> >> >> > >> >> >> Both the memory locations passed to memcmp() had "SGI_ACL_FILE" and > >> >> >> len > >> >> >> argument of memcmp() was set to 12. s1 argument of memcmp() had the > >> >> >> value > >> >> >> 0xf4af0485, while s2 argument had the value > >> >> >> 0xce9e316f. > >> >> >> > >> >> >> The following is the code path within memcmp() that gets executed > >> >> >> for the > >> >> >> above mentioned values, > >> >> >> > >> >> >> - Since len (i.e. 12) is greater than 7, we branch to .Lno_short. > >> >>
Re: BUG: memcmp(): Accessing invalid memory location
Chandan Rajendra writes: > On Wednesday, February 6, 2019 5:20:04 PM IST Michael Ellerman wrote: >> Chandan Rajendra writes: >> > On Friday, February 1, 2019 4:43:52 PM IST Michael Ellerman wrote: >> >> Michael Ellerman writes: >> >> >> >> > Adding Simon who wrote the code. >> >> > >> >> > Chandan Rajendra writes: >> >> >> When executing fstests' generic/026 test, I hit the following call >> >> >> trace, >> >> >> >> >> >> [ 417.061038] BUG: Unable to handle kernel data access at >> >> >> 0xc0062ac4 >> >> >> [ 417.062172] Faulting instruction address: 0xc0092240 >> >> >> [ 417.062242] Oops: Kernel access of bad area, sig: 11 [#1] >> >> >> [ 417.062299] LE SMP NR_CPUS=2048 DEBUG_PAGEALLOC NUMA pSeries >> >> >> [ 417.062366] Modules linked in: >> >> >> [ 417.062401] CPU: 0 PID: 27828 Comm: chacl Not tainted >> >> >> 5.0.0-rc2-next-20190115-1-g6de6dba64dda #1 >> >> >> [ 417.062495] NIP: c0092240 LR: c066a55c CTR: >> >> >> >> >> >> [ 417.062567] REGS: c0062c0c3430 TRAP: 0300 Not tainted >> >> >> (5.0.0-rc2-next-20190115-1-g6de6dba64dda) >> >> >> [ 417.062660] MSR: 82009033 CR: >> >> >> 44000842 XER: 2000 >> >> >> [ 417.062750] CFAR: 7fff7f3108ac DAR: c0062ac4 DSISR: >> >> >> 4000 IRQMASK: 0 >> >> >>GPR00: c0062c0c36c0 >> >> >> c17f4c00 c121a660 >> >> >>GPR04: c0062ac3fff9 0004 >> >> >> 0020 275b19c4 >> >> >>GPR08: 000c 46494c45 >> >> >> 5347495f41434c5f c26073a0 >> >> >>GPR12: c27a >> >> >> >> >> >>GPR16: >> >> >> >> >> >>GPR20: c0062ea70020 c0062c0c38d0 >> >> >> 0002 0002 >> >> >>GPR24: c0062ac3ffe8 275b19c4 >> >> >> 0001 c0062ac3 >> >> >>GPR28: c0062c0c38d0 c0062ac30050 >> >> >> c0062ac30058 >> >> >> [ 417.063563] NIP [c0092240] memcmp+0x120/0x690 >> >> >> [ 417.063635] LR [c066a55c] >> >> >> xfs_attr3_leaf_lookup_int+0x53c/0x5b0 >> >> >> [ 417.063709] Call Trace: >> >> >> [ 417.063744] [c0062c0c36c0] [c066a098] >> >> >> xfs_attr3_leaf_lookup_int+0x78/0x5b0 (unreliable) >> >> >> [ 417.063851] [c0062c0c3760] [c0693f8c] >> >> >> xfs_da3_node_lookup_int+0x32c/0x5a0 >> >> >> [ 417.063944] [c0062c0c3820] [c06634a0] >> >> >> xfs_attr_node_addname+0x170/0x6b0 >> >> >> [ 417.064034] [c0062c0c38b0] [c0664ffc] >> >> >> xfs_attr_set+0x2ac/0x340 >> >> >> [ 417.064118] [c0062c0c39a0] [c0758d40] >> >> >> __xfs_set_acl+0xf0/0x230 >> >> >> [ 417.064190] [c0062c0c3a00] [c0758f50] >> >> >> xfs_set_acl+0xd0/0x160 >> >> >> [ 417.064268] [c0062c0c3aa0] [c04b69b0] >> >> >> set_posix_acl+0xc0/0x130 >> >> >> [ 417.064339] [c0062c0c3ae0] [c04b6a88] >> >> >> posix_acl_xattr_set+0x68/0x110 >> >> >> [ 417.064412] [c0062c0c3b20] [c04532d4] >> >> >> __vfs_setxattr+0xa4/0x110 >> >> >> [ 417.064485] [c0062c0c3b80] [c0454c2c] >> >> >> __vfs_setxattr_noperm+0xac/0x240 >> >> >> [ 417.064566] [c0062c0c3bd0] [c0454ee8] >> >> >> vfs_setxattr+0x128/0x130 >> >> >> [ 417.064638] [c0062c0c3c30] [c0455138] >> >> >> setxattr+0x248/0x600 >> >> >> [ 417.064710] [c0062c0c3d90] [c0455738] >> >> >> path_setxattr+0x108/0x120 >> >> >> [ 417.064785] [c0062c0c3e00] [c0455778] >> >> >> sys_setxattr+0x28/0x40 >> >> >> [ 417.064858] [c0062c0c3e20] [c000bae4] >> >> >> system_call+0x5c/0x70 >> >> >> [ 417.064930] Instruction dump: >> >> >> [ 417.064964] 7d201c28 7d402428 7c295040 38630008 38840008 408201f0 >> >> >> 4200ffe8 2c05 >> >> >> [ 417.065051] 4182ff6c 20c50008 54c61838 7d201c28 <7d402428> 7d293436 >> >> >> 7d4a3436 7c295040 >> >> >> [ 417.065150] ---[ end trace 0d060411b5e3741b ]--- >> >> >> >> >> >> >> >> >> Both the memory locations passed to memcmp() had "SGI_ACL_FILE" and len >> >> >> argument of memcmp() was set to 12. s1 argument of memcmp() had the >> >> >> value >> >> >> 0xf4af0485, while s2 argument had the value 0xce9e316f. >> >> >> >> >> >> The following is the code path within memcmp() that gets executed for >> >> >> the >> >> >> above mentioned values, >> >> >> >> >> >> - Since len (i.e. 12) is greater than 7, we branch to .Lno_short. >> >> >> - We then prefetch the contents of r3 & r4 and branch to >> >> >> .Ldiffoffset_8bytes_make_align_start. >> >> >> - Under .Ldiffoffset_novmx_cmp, Since r3 is unaligned we end up >> >> >> comparing >> >> >> "SGI" part of the string. r3's value is then aligned. r4's value is >> >>
Re: BUG: memcmp(): Accessing invalid memory location
On Wednesday, February 6, 2019 5:20:04 PM IST Michael Ellerman wrote: > Chandan Rajendra writes: > > On Friday, February 1, 2019 4:43:52 PM IST Michael Ellerman wrote: > >> Michael Ellerman writes: > >> > >> > Adding Simon who wrote the code. > >> > > >> > Chandan Rajendra writes: > >> >> When executing fstests' generic/026 test, I hit the following call > >> >> trace, > >> >> > >> >> [ 417.061038] BUG: Unable to handle kernel data access at > >> >> 0xc0062ac4 > >> >> [ 417.062172] Faulting instruction address: 0xc0092240 > >> >> [ 417.062242] Oops: Kernel access of bad area, sig: 11 [#1] > >> >> [ 417.062299] LE SMP NR_CPUS=2048 DEBUG_PAGEALLOC NUMA pSeries > >> >> [ 417.062366] Modules linked in: > >> >> [ 417.062401] CPU: 0 PID: 27828 Comm: chacl Not tainted > >> >> 5.0.0-rc2-next-20190115-1-g6de6dba64dda #1 > >> >> [ 417.062495] NIP: c0092240 LR: c066a55c CTR: > >> >> > >> >> [ 417.062567] REGS: c0062c0c3430 TRAP: 0300 Not tainted > >> >> (5.0.0-rc2-next-20190115-1-g6de6dba64dda) > >> >> [ 417.062660] MSR: 82009033 CR: > >> >> 44000842 XER: 2000 > >> >> [ 417.062750] CFAR: 7fff7f3108ac DAR: c0062ac4 DSISR: > >> >> 4000 IRQMASK: 0 > >> >>GPR00: c0062c0c36c0 > >> >> c17f4c00 c121a660 > >> >>GPR04: c0062ac3fff9 0004 > >> >> 0020 275b19c4 > >> >>GPR08: 000c 46494c45 > >> >> 5347495f41434c5f c26073a0 > >> >>GPR12: c27a > >> >> > >> >>GPR16: > >> >> > >> >>GPR20: c0062ea70020 c0062c0c38d0 > >> >> 0002 0002 > >> >>GPR24: c0062ac3ffe8 275b19c4 > >> >> 0001 c0062ac3 > >> >>GPR28: c0062c0c38d0 c0062ac30050 > >> >> c0062ac30058 > >> >> [ 417.063563] NIP [c0092240] memcmp+0x120/0x690 > >> >> [ 417.063635] LR [c066a55c] > >> >> xfs_attr3_leaf_lookup_int+0x53c/0x5b0 > >> >> [ 417.063709] Call Trace: > >> >> [ 417.063744] [c0062c0c36c0] [c066a098] > >> >> xfs_attr3_leaf_lookup_int+0x78/0x5b0 (unreliable) > >> >> [ 417.063851] [c0062c0c3760] [c0693f8c] > >> >> xfs_da3_node_lookup_int+0x32c/0x5a0 > >> >> [ 417.063944] [c0062c0c3820] [c06634a0] > >> >> xfs_attr_node_addname+0x170/0x6b0 > >> >> [ 417.064034] [c0062c0c38b0] [c0664ffc] > >> >> xfs_attr_set+0x2ac/0x340 > >> >> [ 417.064118] [c0062c0c39a0] [c0758d40] > >> >> __xfs_set_acl+0xf0/0x230 > >> >> [ 417.064190] [c0062c0c3a00] [c0758f50] > >> >> xfs_set_acl+0xd0/0x160 > >> >> [ 417.064268] [c0062c0c3aa0] [c04b69b0] > >> >> set_posix_acl+0xc0/0x130 > >> >> [ 417.064339] [c0062c0c3ae0] [c04b6a88] > >> >> posix_acl_xattr_set+0x68/0x110 > >> >> [ 417.064412] [c0062c0c3b20] [c04532d4] > >> >> __vfs_setxattr+0xa4/0x110 > >> >> [ 417.064485] [c0062c0c3b80] [c0454c2c] > >> >> __vfs_setxattr_noperm+0xac/0x240 > >> >> [ 417.064566] [c0062c0c3bd0] [c0454ee8] > >> >> vfs_setxattr+0x128/0x130 > >> >> [ 417.064638] [c0062c0c3c30] [c0455138] > >> >> setxattr+0x248/0x600 > >> >> [ 417.064710] [c0062c0c3d90] [c0455738] > >> >> path_setxattr+0x108/0x120 > >> >> [ 417.064785] [c0062c0c3e00] [c0455778] > >> >> sys_setxattr+0x28/0x40 > >> >> [ 417.064858] [c0062c0c3e20] [c000bae4] > >> >> system_call+0x5c/0x70 > >> >> [ 417.064930] Instruction dump: > >> >> [ 417.064964] 7d201c28 7d402428 7c295040 38630008 38840008 408201f0 > >> >> 4200ffe8 2c05 > >> >> [ 417.065051] 4182ff6c 20c50008 54c61838 7d201c28 <7d402428> 7d293436 > >> >> 7d4a3436 7c295040 > >> >> [ 417.065150] ---[ end trace 0d060411b5e3741b ]--- > >> >> > >> >> > >> >> Both the memory locations passed to memcmp() had "SGI_ACL_FILE" and len > >> >> argument of memcmp() was set to 12. s1 argument of memcmp() had the > >> >> value > >> >> 0xf4af0485, while s2 argument had the value 0xce9e316f. > >> >> > >> >> The following is the code path within memcmp() that gets executed for > >> >> the > >> >> above mentioned values, > >> >> > >> >> - Since len (i.e. 12) is greater than 7, we branch to .Lno_short. > >> >> - We then prefetch the contents of r3 & r4 and branch to > >> >> .Ldiffoffset_8bytes_make_align_start. > >> >> - Under .Ldiffoffset_novmx_cmp, Since r3 is unaligned we end up > >> >> comparing > >> >> "SGI" part of the string. r3's value is then aligned. r4's value is > >> >> incremented by 3. For comparing the remaining 9 bytes, we jump to > >> >> .Lcmp_lt32bytes. > >> >> - Here, 8 bytes of
Re: BUG: memcmp(): Accessing invalid memory location
Chandan Rajendra writes: > On Friday, February 1, 2019 4:43:52 PM IST Michael Ellerman wrote: >> Michael Ellerman writes: >> >> > Adding Simon who wrote the code. >> > >> > Chandan Rajendra writes: >> >> When executing fstests' generic/026 test, I hit the following call trace, >> >> >> >> [ 417.061038] BUG: Unable to handle kernel data access at >> >> 0xc0062ac4 >> >> [ 417.062172] Faulting instruction address: 0xc0092240 >> >> [ 417.062242] Oops: Kernel access of bad area, sig: 11 [#1] >> >> [ 417.062299] LE SMP NR_CPUS=2048 DEBUG_PAGEALLOC NUMA pSeries >> >> [ 417.062366] Modules linked in: >> >> [ 417.062401] CPU: 0 PID: 27828 Comm: chacl Not tainted >> >> 5.0.0-rc2-next-20190115-1-g6de6dba64dda #1 >> >> [ 417.062495] NIP: c0092240 LR: c066a55c CTR: >> >> >> >> [ 417.062567] REGS: c0062c0c3430 TRAP: 0300 Not tainted >> >> (5.0.0-rc2-next-20190115-1-g6de6dba64dda) >> >> [ 417.062660] MSR: 82009033 CR: >> >> 44000842 XER: 2000 >> >> [ 417.062750] CFAR: 7fff7f3108ac DAR: c0062ac4 DSISR: >> >> 4000 IRQMASK: 0 >> >>GPR00: c0062c0c36c0 c17f4c00 >> >> c121a660 >> >>GPR04: c0062ac3fff9 0004 0020 >> >> 275b19c4 >> >>GPR08: 000c 46494c45 5347495f41434c5f >> >> c26073a0 >> >>GPR12: c27a >> >> >> >>GPR16: >> >> >> >>GPR20: c0062ea70020 c0062c0c38d0 0002 >> >> 0002 >> >>GPR24: c0062ac3ffe8 275b19c4 0001 >> >> c0062ac3 >> >>GPR28: c0062c0c38d0 c0062ac30050 c0062ac30058 >> >> >> >> [ 417.063563] NIP [c0092240] memcmp+0x120/0x690 >> >> [ 417.063635] LR [c066a55c] xfs_attr3_leaf_lookup_int+0x53c/0x5b0 >> >> [ 417.063709] Call Trace: >> >> [ 417.063744] [c0062c0c36c0] [c066a098] >> >> xfs_attr3_leaf_lookup_int+0x78/0x5b0 (unreliable) >> >> [ 417.063851] [c0062c0c3760] [c0693f8c] >> >> xfs_da3_node_lookup_int+0x32c/0x5a0 >> >> [ 417.063944] [c0062c0c3820] [c06634a0] >> >> xfs_attr_node_addname+0x170/0x6b0 >> >> [ 417.064034] [c0062c0c38b0] [c0664ffc] >> >> xfs_attr_set+0x2ac/0x340 >> >> [ 417.064118] [c0062c0c39a0] [c0758d40] >> >> __xfs_set_acl+0xf0/0x230 >> >> [ 417.064190] [c0062c0c3a00] [c0758f50] >> >> xfs_set_acl+0xd0/0x160 >> >> [ 417.064268] [c0062c0c3aa0] [c04b69b0] >> >> set_posix_acl+0xc0/0x130 >> >> [ 417.064339] [c0062c0c3ae0] [c04b6a88] >> >> posix_acl_xattr_set+0x68/0x110 >> >> [ 417.064412] [c0062c0c3b20] [c04532d4] >> >> __vfs_setxattr+0xa4/0x110 >> >> [ 417.064485] [c0062c0c3b80] [c0454c2c] >> >> __vfs_setxattr_noperm+0xac/0x240 >> >> [ 417.064566] [c0062c0c3bd0] [c0454ee8] >> >> vfs_setxattr+0x128/0x130 >> >> [ 417.064638] [c0062c0c3c30] [c0455138] setxattr+0x248/0x600 >> >> [ 417.064710] [c0062c0c3d90] [c0455738] >> >> path_setxattr+0x108/0x120 >> >> [ 417.064785] [c0062c0c3e00] [c0455778] >> >> sys_setxattr+0x28/0x40 >> >> [ 417.064858] [c0062c0c3e20] [c000bae4] system_call+0x5c/0x70 >> >> [ 417.064930] Instruction dump: >> >> [ 417.064964] 7d201c28 7d402428 7c295040 38630008 38840008 408201f0 >> >> 4200ffe8 2c05 >> >> [ 417.065051] 4182ff6c 20c50008 54c61838 7d201c28 <7d402428> 7d293436 >> >> 7d4a3436 7c295040 >> >> [ 417.065150] ---[ end trace 0d060411b5e3741b ]--- >> >> >> >> >> >> Both the memory locations passed to memcmp() had "SGI_ACL_FILE" and len >> >> argument of memcmp() was set to 12. s1 argument of memcmp() had the value >> >> 0xf4af0485, while s2 argument had the value 0xce9e316f. >> >> >> >> The following is the code path within memcmp() that gets executed for the >> >> above mentioned values, >> >> >> >> - Since len (i.e. 12) is greater than 7, we branch to .Lno_short. >> >> - We then prefetch the contents of r3 & r4 and branch to >> >> .Ldiffoffset_8bytes_make_align_start. >> >> - Under .Ldiffoffset_novmx_cmp, Since r3 is unaligned we end up comparing >> >> "SGI" part of the string. r3's value is then aligned. r4's value is >> >> incremented by 3. For comparing the remaining 9 bytes, we jump to >> >> .Lcmp_lt32bytes. >> >> - Here, 8 bytes of the remaining 9 bytes are compared and execution moves >> >> to >> >> .Lcmp_rest_lt8bytes. >> >> - Here we execute "LD rB,0,r4". In the case of this bug, r4 has an >> >> unaligned >> >> value and hence ends up accessing the "next" double word. The "next" >> >> double >> >> word happens to occur after the last page
Re: BUG: memcmp(): Accessing invalid memory location
On Friday, February 1, 2019 4:43:52 PM IST Michael Ellerman wrote: > Michael Ellerman writes: > > > Adding Simon who wrote the code. > > > > Chandan Rajendra writes: > >> When executing fstests' generic/026 test, I hit the following call trace, > >> > >> [ 417.061038] BUG: Unable to handle kernel data access at > >> 0xc0062ac4 > >> [ 417.062172] Faulting instruction address: 0xc0092240 > >> [ 417.062242] Oops: Kernel access of bad area, sig: 11 [#1] > >> [ 417.062299] LE SMP NR_CPUS=2048 DEBUG_PAGEALLOC NUMA pSeries > >> [ 417.062366] Modules linked in: > >> [ 417.062401] CPU: 0 PID: 27828 Comm: chacl Not tainted > >> 5.0.0-rc2-next-20190115-1-g6de6dba64dda #1 > >> [ 417.062495] NIP: c0092240 LR: c066a55c CTR: > >> > >> [ 417.062567] REGS: c0062c0c3430 TRAP: 0300 Not tainted > >> (5.0.0-rc2-next-20190115-1-g6de6dba64dda) > >> [ 417.062660] MSR: 82009033 CR: > >> 44000842 XER: 2000 > >> [ 417.062750] CFAR: 7fff7f3108ac DAR: c0062ac4 DSISR: > >> 4000 IRQMASK: 0 > >>GPR00: c0062c0c36c0 c17f4c00 > >> c121a660 > >>GPR04: c0062ac3fff9 0004 0020 > >> 275b19c4 > >>GPR08: 000c 46494c45 5347495f41434c5f > >> c26073a0 > >>GPR12: c27a > >> > >>GPR16: > >> > >>GPR20: c0062ea70020 c0062c0c38d0 0002 > >> 0002 > >>GPR24: c0062ac3ffe8 275b19c4 0001 > >> c0062ac3 > >>GPR28: c0062c0c38d0 c0062ac30050 c0062ac30058 > >> > >> [ 417.063563] NIP [c0092240] memcmp+0x120/0x690 > >> [ 417.063635] LR [c066a55c] xfs_attr3_leaf_lookup_int+0x53c/0x5b0 > >> [ 417.063709] Call Trace: > >> [ 417.063744] [c0062c0c36c0] [c066a098] > >> xfs_attr3_leaf_lookup_int+0x78/0x5b0 (unreliable) > >> [ 417.063851] [c0062c0c3760] [c0693f8c] > >> xfs_da3_node_lookup_int+0x32c/0x5a0 > >> [ 417.063944] [c0062c0c3820] [c06634a0] > >> xfs_attr_node_addname+0x170/0x6b0 > >> [ 417.064034] [c0062c0c38b0] [c0664ffc] > >> xfs_attr_set+0x2ac/0x340 > >> [ 417.064118] [c0062c0c39a0] [c0758d40] > >> __xfs_set_acl+0xf0/0x230 > >> [ 417.064190] [c0062c0c3a00] [c0758f50] xfs_set_acl+0xd0/0x160 > >> [ 417.064268] [c0062c0c3aa0] [c04b69b0] > >> set_posix_acl+0xc0/0x130 > >> [ 417.064339] [c0062c0c3ae0] [c04b6a88] > >> posix_acl_xattr_set+0x68/0x110 > >> [ 417.064412] [c0062c0c3b20] [c04532d4] > >> __vfs_setxattr+0xa4/0x110 > >> [ 417.064485] [c0062c0c3b80] [c0454c2c] > >> __vfs_setxattr_noperm+0xac/0x240 > >> [ 417.064566] [c0062c0c3bd0] [c0454ee8] > >> vfs_setxattr+0x128/0x130 > >> [ 417.064638] [c0062c0c3c30] [c0455138] setxattr+0x248/0x600 > >> [ 417.064710] [c0062c0c3d90] [c0455738] > >> path_setxattr+0x108/0x120 > >> [ 417.064785] [c0062c0c3e00] [c0455778] sys_setxattr+0x28/0x40 > >> [ 417.064858] [c0062c0c3e20] [c000bae4] system_call+0x5c/0x70 > >> [ 417.064930] Instruction dump: > >> [ 417.064964] 7d201c28 7d402428 7c295040 38630008 38840008 408201f0 > >> 4200ffe8 2c05 > >> [ 417.065051] 4182ff6c 20c50008 54c61838 7d201c28 <7d402428> 7d293436 > >> 7d4a3436 7c295040 > >> [ 417.065150] ---[ end trace 0d060411b5e3741b ]--- > >> > >> > >> Both the memory locations passed to memcmp() had "SGI_ACL_FILE" and len > >> argument of memcmp() was set to 12. s1 argument of memcmp() had the value > >> 0xf4af0485, while s2 argument had the value 0xce9e316f. > >> > >> The following is the code path within memcmp() that gets executed for the > >> above mentioned values, > >> > >> - Since len (i.e. 12) is greater than 7, we branch to .Lno_short. > >> - We then prefetch the contents of r3 & r4 and branch to > >> .Ldiffoffset_8bytes_make_align_start. > >> - Under .Ldiffoffset_novmx_cmp, Since r3 is unaligned we end up comparing > >> "SGI" part of the string. r3's value is then aligned. r4's value is > >> incremented by 3. For comparing the remaining 9 bytes, we jump to > >> .Lcmp_lt32bytes. > >> - Here, 8 bytes of the remaining 9 bytes are compared and execution moves > >> to > >> .Lcmp_rest_lt8bytes. > >> - Here we execute "LD rB,0,r4". In the case of this bug, r4 has an > >> unaligned > >> value and hence ends up accessing the "next" double word. The "next" > >> double > >> word happens to occur after the last page mapped into the kernel's > >> address > >> space and hence this leads to the previously listed oops. > > > > Thanks for the analysis. > >
Re: BUG: memcmp(): Accessing invalid memory location
Michael Ellerman writes: > Adding Simon who wrote the code. > > Chandan Rajendra writes: >> When executing fstests' generic/026 test, I hit the following call trace, >> >> [ 417.061038] BUG: Unable to handle kernel data access at 0xc0062ac4 >> [ 417.062172] Faulting instruction address: 0xc0092240 >> [ 417.062242] Oops: Kernel access of bad area, sig: 11 [#1] >> [ 417.062299] LE SMP NR_CPUS=2048 DEBUG_PAGEALLOC NUMA pSeries >> [ 417.062366] Modules linked in: >> [ 417.062401] CPU: 0 PID: 27828 Comm: chacl Not tainted >> 5.0.0-rc2-next-20190115-1-g6de6dba64dda #1 >> [ 417.062495] NIP: c0092240 LR: c066a55c CTR: >> >> [ 417.062567] REGS: c0062c0c3430 TRAP: 0300 Not tainted >> (5.0.0-rc2-next-20190115-1-g6de6dba64dda) >> [ 417.062660] MSR: 82009033 CR: >> 44000842 XER: 2000 >> [ 417.062750] CFAR: 7fff7f3108ac DAR: c0062ac4 DSISR: 4000 >> IRQMASK: 0 >>GPR00: c0062c0c36c0 c17f4c00 >> c121a660 >>GPR04: c0062ac3fff9 0004 0020 >> 275b19c4 >>GPR08: 000c 46494c45 5347495f41434c5f >> c26073a0 >>GPR12: c27a >> >>GPR16: >> >>GPR20: c0062ea70020 c0062c0c38d0 0002 >> 0002 >>GPR24: c0062ac3ffe8 275b19c4 0001 >> c0062ac3 >>GPR28: c0062c0c38d0 c0062ac30050 c0062ac30058 >> >> [ 417.063563] NIP [c0092240] memcmp+0x120/0x690 >> [ 417.063635] LR [c066a55c] xfs_attr3_leaf_lookup_int+0x53c/0x5b0 >> [ 417.063709] Call Trace: >> [ 417.063744] [c0062c0c36c0] [c066a098] >> xfs_attr3_leaf_lookup_int+0x78/0x5b0 (unreliable) >> [ 417.063851] [c0062c0c3760] [c0693f8c] >> xfs_da3_node_lookup_int+0x32c/0x5a0 >> [ 417.063944] [c0062c0c3820] [c06634a0] >> xfs_attr_node_addname+0x170/0x6b0 >> [ 417.064034] [c0062c0c38b0] [c0664ffc] xfs_attr_set+0x2ac/0x340 >> [ 417.064118] [c0062c0c39a0] [c0758d40] __xfs_set_acl+0xf0/0x230 >> [ 417.064190] [c0062c0c3a00] [c0758f50] xfs_set_acl+0xd0/0x160 >> [ 417.064268] [c0062c0c3aa0] [c04b69b0] set_posix_acl+0xc0/0x130 >> [ 417.064339] [c0062c0c3ae0] [c04b6a88] >> posix_acl_xattr_set+0x68/0x110 >> [ 417.064412] [c0062c0c3b20] [c04532d4] >> __vfs_setxattr+0xa4/0x110 >> [ 417.064485] [c0062c0c3b80] [c0454c2c] >> __vfs_setxattr_noperm+0xac/0x240 >> [ 417.064566] [c0062c0c3bd0] [c0454ee8] vfs_setxattr+0x128/0x130 >> [ 417.064638] [c0062c0c3c30] [c0455138] setxattr+0x248/0x600 >> [ 417.064710] [c0062c0c3d90] [c0455738] >> path_setxattr+0x108/0x120 >> [ 417.064785] [c0062c0c3e00] [c0455778] sys_setxattr+0x28/0x40 >> [ 417.064858] [c0062c0c3e20] [c000bae4] system_call+0x5c/0x70 >> [ 417.064930] Instruction dump: >> [ 417.064964] 7d201c28 7d402428 7c295040 38630008 38840008 408201f0 >> 4200ffe8 2c05 >> [ 417.065051] 4182ff6c 20c50008 54c61838 7d201c28 <7d402428> 7d293436 >> 7d4a3436 7c295040 >> [ 417.065150] ---[ end trace 0d060411b5e3741b ]--- >> >> >> Both the memory locations passed to memcmp() had "SGI_ACL_FILE" and len >> argument of memcmp() was set to 12. s1 argument of memcmp() had the value >> 0xf4af0485, while s2 argument had the value 0xce9e316f. >> >> The following is the code path within memcmp() that gets executed for the >> above mentioned values, >> >> - Since len (i.e. 12) is greater than 7, we branch to .Lno_short. >> - We then prefetch the contents of r3 & r4 and branch to >> .Ldiffoffset_8bytes_make_align_start. >> - Under .Ldiffoffset_novmx_cmp, Since r3 is unaligned we end up comparing >> "SGI" part of the string. r3's value is then aligned. r4's value is >> incremented by 3. For comparing the remaining 9 bytes, we jump to >> .Lcmp_lt32bytes. >> - Here, 8 bytes of the remaining 9 bytes are compared and execution moves to >> .Lcmp_rest_lt8bytes. >> - Here we execute "LD rB,0,r4". In the case of this bug, r4 has an unaligned >> value and hence ends up accessing the "next" double word. The "next" double >> word happens to occur after the last page mapped into the kernel's address >> space and hence this leads to the previously listed oops. > > Thanks for the analysis. > > This is just a bug, we can't read past the end of the source or dest. How about this, works for me. cheers diff --git a/arch/powerpc/lib/memcmp_64.S b/arch/powerpc/lib/memcmp_64.S index 844d8e774492..2a302158cb53 100644 --- a/arch/powerpc/lib/memcmp_64.S +++ b/arch/powerpc/lib/memcmp_64.S @@ -215,20
Re: BUG: memcmp(): Accessing invalid memory location
Adding Simon who wrote the code. Chandan Rajendra writes: > When executing fstests' generic/026 test, I hit the following call trace, > > [ 417.061038] BUG: Unable to handle kernel data access at 0xc0062ac4 > [ 417.062172] Faulting instruction address: 0xc0092240 > [ 417.062242] Oops: Kernel access of bad area, sig: 11 [#1] > [ 417.062299] LE SMP NR_CPUS=2048 DEBUG_PAGEALLOC NUMA pSeries > [ 417.062366] Modules linked in: > [ 417.062401] CPU: 0 PID: 27828 Comm: chacl Not tainted > 5.0.0-rc2-next-20190115-1-g6de6dba64dda #1 > [ 417.062495] NIP: c0092240 LR: c066a55c CTR: > > [ 417.062567] REGS: c0062c0c3430 TRAP: 0300 Not tainted > (5.0.0-rc2-next-20190115-1-g6de6dba64dda) > [ 417.062660] MSR: 82009033 CR: > 44000842 XER: 2000 > [ 417.062750] CFAR: 7fff7f3108ac DAR: c0062ac4 DSISR: 4000 > IRQMASK: 0 >GPR00: c0062c0c36c0 c17f4c00 > c121a660 >GPR04: c0062ac3fff9 0004 0020 > 275b19c4 >GPR08: 000c 46494c45 5347495f41434c5f > c26073a0 >GPR12: c27a > >GPR16: > >GPR20: c0062ea70020 c0062c0c38d0 0002 > 0002 >GPR24: c0062ac3ffe8 275b19c4 0001 > c0062ac3 >GPR28: c0062c0c38d0 c0062ac30050 c0062ac30058 > > [ 417.063563] NIP [c0092240] memcmp+0x120/0x690 > [ 417.063635] LR [c066a55c] xfs_attr3_leaf_lookup_int+0x53c/0x5b0 > [ 417.063709] Call Trace: > [ 417.063744] [c0062c0c36c0] [c066a098] > xfs_attr3_leaf_lookup_int+0x78/0x5b0 (unreliable) > [ 417.063851] [c0062c0c3760] [c0693f8c] > xfs_da3_node_lookup_int+0x32c/0x5a0 > [ 417.063944] [c0062c0c3820] [c06634a0] > xfs_attr_node_addname+0x170/0x6b0 > [ 417.064034] [c0062c0c38b0] [c0664ffc] xfs_attr_set+0x2ac/0x340 > [ 417.064118] [c0062c0c39a0] [c0758d40] __xfs_set_acl+0xf0/0x230 > [ 417.064190] [c0062c0c3a00] [c0758f50] xfs_set_acl+0xd0/0x160 > [ 417.064268] [c0062c0c3aa0] [c04b69b0] set_posix_acl+0xc0/0x130 > [ 417.064339] [c0062c0c3ae0] [c04b6a88] > posix_acl_xattr_set+0x68/0x110 > [ 417.064412] [c0062c0c3b20] [c04532d4] __vfs_setxattr+0xa4/0x110 > [ 417.064485] [c0062c0c3b80] [c0454c2c] > __vfs_setxattr_noperm+0xac/0x240 > [ 417.064566] [c0062c0c3bd0] [c0454ee8] vfs_setxattr+0x128/0x130 > [ 417.064638] [c0062c0c3c30] [c0455138] setxattr+0x248/0x600 > [ 417.064710] [c0062c0c3d90] [c0455738] path_setxattr+0x108/0x120 > [ 417.064785] [c0062c0c3e00] [c0455778] sys_setxattr+0x28/0x40 > [ 417.064858] [c0062c0c3e20] [c000bae4] system_call+0x5c/0x70 > [ 417.064930] Instruction dump: > [ 417.064964] 7d201c28 7d402428 7c295040 38630008 38840008 408201f0 4200ffe8 > 2c05 > [ 417.065051] 4182ff6c 20c50008 54c61838 7d201c28 <7d402428> 7d293436 > 7d4a3436 7c295040 > [ 417.065150] ---[ end trace 0d060411b5e3741b ]--- > > > Both the memory locations passed to memcmp() had "SGI_ACL_FILE" and len > argument of memcmp() was set to 12. s1 argument of memcmp() had the value > 0xf4af0485, while s2 argument had the value 0xce9e316f. > > The following is the code path within memcmp() that gets executed for the > above mentioned values, > > - Since len (i.e. 12) is greater than 7, we branch to .Lno_short. > - We then prefetch the contents of r3 & r4 and branch to > .Ldiffoffset_8bytes_make_align_start. > - Under .Ldiffoffset_novmx_cmp, Since r3 is unaligned we end up comparing > "SGI" part of the string. r3's value is then aligned. r4's value is > incremented by 3. For comparing the remaining 9 bytes, we jump to > .Lcmp_lt32bytes. > - Here, 8 bytes of the remaining 9 bytes are compared and execution moves to > .Lcmp_rest_lt8bytes. > - Here we execute "LD rB,0,r4". In the case of this bug, r4 has an unaligned > value and hence ends up accessing the "next" double word. The "next" double > word happens to occur after the last page mapped into the kernel's address > space and hence this leads to the previously listed oops. Thanks for the analysis. This is just a bug, we can't read past the end of the source or dest. We have a selftest for memcmp, but clearly it doesn't exercise this case. Here's a patch to try and trip it: diff --git a/tools/testing/selftests/powerpc/stringloops/memcmp.c b/tools/testing/selftests/powerpc/stringloops/memcmp.c index b1fa7546957f..edca3abb6ecf 100644 --- a/tools/testing/selftests/powerpc/stringloops/memcmp.c +++
Re: BUG: memcmp(): Accessing invalid memory location
Le 25/01/2019 à 01:55, Benjamin Herrenschmidt a écrit : On Thu, 2019-01-24 at 19:48 +0530, Chandan Rajendra wrote: - Here we execute "LD rB,0,r4". In the case of this bug, r4 has an unaligned value and hence ends up accessing the "next" double word. The "next" double word happens to occur after the last page mapped into the kernel's address space and hence this leads to the previously listed oops. This is interesting ... should we mark the last page of any piece of mapped linear mapping as reserved to avoid that sort of issue ? Or revert to a normal comparison once remaining length is < 8 and r4 in unaligned ? Christophe Nick ? Aneesh ? Cheers, Ben.
Re: BUG: memcmp(): Accessing invalid memory location
On Thu, 2019-01-24 at 19:48 +0530, Chandan Rajendra wrote: > - Here we execute "LD rB,0,r4". In the case of this bug, r4 has an unaligned > value and hence ends up accessing the "next" double word. The "next" double > word happens to occur after the last page mapped into the kernel's address > space and hence this leads to the previously listed oops. > This is interesting ... should we mark the last page of any piece of mapped linear mapping as reserved to avoid that sort of issue ? Nick ? Aneesh ? Cheers, Ben.
BUG: memcmp(): Accessing invalid memory location
When executing fstests' generic/026 test, I hit the following call trace, [ 417.061038] BUG: Unable to handle kernel data access at 0xc0062ac4 [ 417.062172] Faulting instruction address: 0xc0092240 [ 417.062242] Oops: Kernel access of bad area, sig: 11 [#1] [ 417.062299] LE SMP NR_CPUS=2048 DEBUG_PAGEALLOC NUMA pSeries [ 417.062366] Modules linked in: [ 417.062401] CPU: 0 PID: 27828 Comm: chacl Not tainted 5.0.0-rc2-next-20190115-1-g6de6dba64dda #1 [ 417.062495] NIP: c0092240 LR: c066a55c CTR: [ 417.062567] REGS: c0062c0c3430 TRAP: 0300 Not tainted (5.0.0-rc2-next-20190115-1-g6de6dba64dda) [ 417.062660] MSR: 82009033 CR: 44000842 XER: 2000 [ 417.062750] CFAR: 7fff7f3108ac DAR: c0062ac4 DSISR: 4000 IRQMASK: 0 GPR00: c0062c0c36c0 c17f4c00 c121a660 GPR04: c0062ac3fff9 0004 0020 275b19c4 GPR08: 000c 46494c45 5347495f41434c5f c26073a0 GPR12: c27a GPR16: GPR20: c0062ea70020 c0062c0c38d0 0002 0002 GPR24: c0062ac3ffe8 275b19c4 0001 c0062ac3 GPR28: c0062c0c38d0 c0062ac30050 c0062ac30058 [ 417.063563] NIP [c0092240] memcmp+0x120/0x690 [ 417.063635] LR [c066a55c] xfs_attr3_leaf_lookup_int+0x53c/0x5b0 [ 417.063709] Call Trace: [ 417.063744] [c0062c0c36c0] [c066a098] xfs_attr3_leaf_lookup_int+0x78/0x5b0 (unreliable) [ 417.063851] [c0062c0c3760] [c0693f8c] xfs_da3_node_lookup_int+0x32c/0x5a0 [ 417.063944] [c0062c0c3820] [c06634a0] xfs_attr_node_addname+0x170/0x6b0 [ 417.064034] [c0062c0c38b0] [c0664ffc] xfs_attr_set+0x2ac/0x340 [ 417.064118] [c0062c0c39a0] [c0758d40] __xfs_set_acl+0xf0/0x230 [ 417.064190] [c0062c0c3a00] [c0758f50] xfs_set_acl+0xd0/0x160 [ 417.064268] [c0062c0c3aa0] [c04b69b0] set_posix_acl+0xc0/0x130 [ 417.064339] [c0062c0c3ae0] [c04b6a88] posix_acl_xattr_set+0x68/0x110 [ 417.064412] [c0062c0c3b20] [c04532d4] __vfs_setxattr+0xa4/0x110 [ 417.064485] [c0062c0c3b80] [c0454c2c] __vfs_setxattr_noperm+0xac/0x240 [ 417.064566] [c0062c0c3bd0] [c0454ee8] vfs_setxattr+0x128/0x130 [ 417.064638] [c0062c0c3c30] [c0455138] setxattr+0x248/0x600 [ 417.064710] [c0062c0c3d90] [c0455738] path_setxattr+0x108/0x120 [ 417.064785] [c0062c0c3e00] [c0455778] sys_setxattr+0x28/0x40 [ 417.064858] [c0062c0c3e20] [c000bae4] system_call+0x5c/0x70 [ 417.064930] Instruction dump: [ 417.064964] 7d201c28 7d402428 7c295040 38630008 38840008 408201f0 4200ffe8 2c05 [ 417.065051] 4182ff6c 20c50008 54c61838 7d201c28 <7d402428> 7d293436 7d4a3436 7c295040 [ 417.065150] ---[ end trace 0d060411b5e3741b ]--- Both the memory locations passed to memcmp() had "SGI_ACL_FILE" and len argument of memcmp() was set to 12. s1 argument of memcmp() had the value 0xf4af0485, while s2 argument had the value 0xce9e316f. The following is the code path within memcmp() that gets executed for the above mentioned values, - Since len (i.e. 12) is greater than 7, we branch to .Lno_short. - We then prefetch the contents of r3 & r4 and branch to .Ldiffoffset_8bytes_make_align_start. - Under .Ldiffoffset_novmx_cmp, Since r3 is unaligned we end up comparing "SGI" part of the string. r3's value is then aligned. r4's value is incremented by 3. For comparing the remaining 9 bytes, we jump to .Lcmp_lt32bytes. - Here, 8 bytes of the remaining 9 bytes are compared and execution moves to .Lcmp_rest_lt8bytes. - Here we execute "LD rB,0,r4". In the case of this bug, r4 has an unaligned value and hence ends up accessing the "next" double word. The "next" double word happens to occur after the last page mapped into the kernel's address space and hence this leads to the previously listed oops. -- chandan
