Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reliable crashes of nodejs #21

Closed
cjdelisle opened this issue Feb 22, 2015 · 15 comments
Closed

Reliable crashes of nodejs #21

cjdelisle opened this issue Feb 22, 2015 · 15 comments

Comments

@cjdelisle
Copy link

To repeat:

  • dist-upgrade to jessie
  • install nodejs (only available for mipsel in jessie)
  • run some nodejs scripts (For me the cjdns build: https://github.com/cjdelisle/cjdns ) is 100% reliable
  • observe "Bus error", segfault or unexpected fault in js code

This is not fixed by reducing the memory to 256M as per #18

@cjdelisle
Copy link
Author

Often enough nodejs -e 'console.log("hi");' is enough to crash it

@cjdelisle
Copy link
Author

Linux ci20-3006 3.0.8-12439-gf697891 torvalds#98 SMP PREEMPT Thu Sep 11 15:52:29 BST 2014 mips GNU/Linu

@ZubairLK
Copy link

root@ci20-3110:# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 8.0 (jessie)
Release: 8.0
Codename: jessie
root@ci20-3110:
# while (true) ; do nodejs -e 'console.log("hi");' ; done;

path.js:326
resolvedPath = normalizeArray(resolvedPath.split('/').filter(function(p) {
^
<error: TypeError: Cannot call method '499138649' of undefined>
at Object.exports.resolve (path.js:326:48)
at Function.Module._nodeModulePaths (module.js:209:15)
at evalScript (node.js:523:27)
at startup (node.js:80:7)
at node.js:906:3

path.js:326
resolvedPath = normalizeArray(resolvedPath.split('/').filter(function(p) {
^
<error: illegal access>
at <error: illegal access>
at Function.Module._nodeModulePaths (module.js:209:15)
at evalScript (node.js:523:27)
at startup (node.js:80:7)
at node.js:906:3
[58087.026525] do_page_fault() #2: sending SIGSEGV to nodejs for invalid read access from
[58087.026537] 3beff000 (epc == 3beff000, ra == 3be14f4c)
Segmentation fault
[58092.050185] do_page_fault() #2: sending SIGSEGV to nodejs for invalid read access from
[58092.050195] 00000018 (epc == 2afbc208, ra == 2afbc730)
Segmentation fault
Bus error

path.js:326
resolvedPath = normalizeArray(resolvedPath.split('/').filter(function(p) {
^
TypeError: Object 880451265 has no method 'split'
at Object.exports.resolve (path.js:326:48)
at Function.Module._nodeModulePaths (module.js:209:15)
at evalScript (node.js:523:27)
at startup (node.js:80:7)
at node.js:906:3
hi
hi

path.js:326
resolvedPath = normalizeArray(resolvedPath.split('/').filter(function(p) {
^
TypeError: Object 1025155253 has no method 'split'
at Object.exports.resolve (path.js:326:48)
at Function.Module._nodeModulePaths (module.js:209:15)
at evalScript (node.js:523:27)
at startup (node.js:80:7)
at node.js:906:3
[58127.905001] do_page_fault() #2: sending SIGSEGV to nodejs for invalid read access from
[58127.905012] 40dff000 (epc == 40dff000, ra == 40d11c2c)
Segmentation fault
Bus error
Bus error
Segmentation fault
hi
Segmentation fault
Bus error

path.js:326
resolvedPath = normalizeArray(resolvedPath.split('/').filter(function(p) {
^
TypeError: Object 909287081 has no method 'split'
at Object.exports.resolve (path.js:326:48)
at Function.Module._nodeModulePaths (module.js:209:15)
at evalScript (node.js:523:27)
at startup (node.js:80:7)
at node.js:906:3
[58168.070701] do_page_fault() #2: sending SIGSEGV to nodejs for invalid read access from
[58168.070712] 5f3ff000 (epc == 5f3ff000, ra == 5f311c2c)
Segmentation fault
hi
[58180.338101] do_page_fault() #2: sending SIGSEGV to nodejs for invalid read access from
[58180.338112] 419ff000 (epc == 419ff000, ra == 41914c2c)
Segmentation fault
^C
root@ci20-3110:# uname -a
Linux ci20-3110 3.0.8-12439-gf697891 torvalds#98 SMP PREEMPT Thu Sep 11 15:52:29 BST 2014 mips GNU/Linux
root@ci20-3110:
#

@ZubairLK
Copy link

The plot thickens 👍

root@ci20:# uname -a
Linux ci20 4.0.0-rc1+ #15 SMP PREEMPT Mon Feb 23 17:44:38 GMT 2015 mips GNU/Linux
root@ci20:
# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 8.0 (jessie)
Release: 8.0
Codename: jessie
root@ci20:#
root@ci20:
# while (true) ; do nodejs -e 'console.log("hi");' ; done;
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
^Chi
^C^C^C^C
root@ci20:# ^C
root@ci20:
# ^C

@ZubairLK
Copy link

root@ci20:# lsb_release -a
uname -aNo LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 8.0 (jessie)
Release: 8.0
Codename: jessie
root@ci20:
# uname -a
Linux ci20 3.16.0-00055-g30327b7-dirty #45 SMP Tue Feb 24 10:18:13 GMT 2015 mips GNU/Linux
root@ci20:~# while (true) ; do nodejs -e 'console.log("hi");' ; done;
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi
hi

@ZubairLK
Copy link

@ZubairLK
Copy link

(gdb) run -e 'console.log("hi")'
Starting program: /usr/bin/nodejs -e 'console.log("hi")'
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/mipsel-linux-gnu/libthread_db.so.1".
[New Thread 0x2bd04490 (LWP 1966)]
hi
[Thread 0x2bd04490 (LWP 1966) exited]
Inferior 1 (process 1965) exited normally run -e 'console.log("hi")'
Starting program: /usr/bin/nodejs -e 'console.log("hi")'
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/mipsel-linux-gnu/libthread_db.so.1".
[New Thread 0x2bd04490 (LWP 1968)]
hi
[Thread 0x2bd04490 (LWP 1968) exited]
Inferior 1 (process 1967) exited normally run -e 'console.log("hi")'
Starting program: /usr/bin/nodejs -e 'console.log("hi")'
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/mipsel-linux-gnu/libthread_db.so.1".
[New Thread 0x2bd04490 (LWP 1970)]
warning: GDB can't find the start of the function at 0x55b1c830.

GDB is unable to find the start of the function at 0x55b1c830

and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
This problem is most likely caused by an invalid program counter or
stack pointer.
However, if you think GDB should simply search farther back
from 0x55b1c830 for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.

Program received signal SIGSEGV, Segmentation fault.
warning: GDB can't find the start of the function at 0x55b1c830.
0x55b1c830 in ?? ()
(gdb) info shared
From To Syms Read Shared Object Library
0x2aaa89c0 0x2aac51f0 Yes /lib/ld.so.1
0x2aaef720 0x2ab02720 Yes () /lib/mipsel-linux-gnu/libz.so.1
0x2ab19530 0x2ab26dd0 Yes (
) /usr/lib/mipsel-linux-gnu/libcares.so.2
0x2ab60430 0x2aea91a0 Yes /usr/lib/libv8.so.3.14.5
0x2af4fad0 0x2af8a720 Yes () /usr/lib/mipsel-linux-gnu/libssl.so.1.0.0
0x2afddef0 0x2b0fdc40 Yes (
) /usr/lib/mipsel-linux-gnu/libcrypto.so.1.0.0
0x2b155bc0 0x2b156c80 Yes /lib/mipsel-linux-gnu/libdl.so.2
0x2b169980 0x2b16e150 Yes /lib/mipsel-linux-gnu/librt.so.1
0x2b1c7fd0 0x2b2524d4 Yes () /usr/lib/mipsel-linux-gnu/libstdc++.so.6
0x2b295d50 0x2b2dabf0 Yes /lib/mipsel-linux-gnu/libm.so.6
0x2b32d9e0 0x2b3477c0 Yes (
) /lib/mipsel-linux-gnu/libgcc_s.so.1
0x2b35e6d0 0x2b36fd60 Yes /lib/mipsel-linux-gnu/libpthread.so.0
0x2b39d7e0 0x2b4c3440 Yes /lib/mipsel-linux-gnu/libc.so.6
(*): Shared library is missing debugging information.
(gdb)

@cjdelisle
Copy link
Author

with debug symbols

root@ci20-3006:~# gdb nodejs -ex 'set confirm no' -ex 'r -e "console.log(\"hi\")"' -ex 'backtrace' -ex 'info registers' -ex 'quit' | tee node-debug
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mipsel-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from nodejs...Reading symbols from /usr/lib/debug//usr/bin/nodejs...done.
done.
Starting program: /usr/bin/nodejs -e "console.log(\"hi\")"
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/mipsel-linux-gnu/libthread_db.so.1".

[New Thread 0x2bcf4490 (LWP 733)]

Program received signal SIGSEGV, Segmentation fault.
v8::internal::ExternalTwoByteString::ExternalTwoByteStringReadBlockIntoBuffer (this=<optimized out>, rbb=0x7fff61a8, offset_ptr=0x7fff61f0, 
    max_chars=646463582) at ../src/objects.cc:6482
6482    ../src/objects.cc: No such file or directory.
#0  v8::internal::ExternalTwoByteString::ExternalTwoByteStringReadBlockIntoBuffer (this=<optimized out>, rbb=0x7fff61a8, 
    offset_ptr=0x7fff61f0, max_chars=646463582) at ../src/objects.cc:6482
#1  0x2acf22e0 in v8::internal::String::ReadBlock (input=<optimized out>, rbb=0x7fff61a8, offset_ptr=0x7fff61f0, max_chars=646463582)
    at ../src/objects.cc:6576
#2  0x2acf2454 in v8::internal::String::ReadBlock (input=<optimized out>, util_buffer=<optimized out>, capacity=<optimized out>, 
    remaining=0x7fff61e4, offset_ptr=0x7fff61f0) at ../src/objects.cc:6748
#3  0x2acf60dc in Reset (input=0x24c08091, position=0, this=0x7fff61e0) at ../src/unicode-inl.h:229
#4  Reset (input=0x24c08091, this=0x7fff61e0) at ../src/unicode-inl.h:234
#5  InputBuffer (input=0x24c08091, this=0x7fff61e0) at ../src/unicode.h:230
#6  StringInputBuffer (backing=0x24c08091, this=0x7fff61e0) at ../src/objects.h:7909
#7  v8::internal::String::ComputeAndSetHash (this=0x24c08091) at ../src/objects.cc:7230
#8  0x2aba2304 in Hash (this=0x24c08091) at ../src/objects-inl.h:4890
#9  LinearSearch<(v8::internal::SearchMode)1, v8::internal::DescriptorArray> (len=<optimized out>, valid_entries=13, name=0x4d10bf05, 
    array=<optimized out>) at ../src/objects-inl.h:2007
#10 v8::internal::Search<(v8::internal::SearchMode)1, v8::internal::DescriptorArray> (array=<optimized out>, name=0x4d10bf05, valid_entries=13)
    at ../src/objects-inl.h:2032
#11 0x2ad13798 in Search (valid_descriptors=<optimized out>, name=0x4d10bf05, this=0x30714389) at ../src/objects-inl.h:2041
#12 SearchWithCache (map=0x5440937d, name=0x4d10bf05, this=0x30714389) at ../src/objects-inl.h:2053
#13 LookupDescriptor (result=0x7fff6730, name=0x4d10bf05, holder=0x3074c075, this=0x5440937d) at ../src/objects-inl.h:2065
#14 v8::internal::JSObject::LocalLookupRealNamedProperty (this=<optimized out>, name=0x4d10bf05, result=0x7fff6730) at ../src/objects.cc:2386
#15 0x2ad14574 in v8::internal::JSReceiver::Lookup (this=<optimized out>, name=0x4d10bf05, result=0x7fff6730) at ../src/objects.cc:4315
#16 0x2ac83794 in v8::internal::LookupForRead (object=..., name=..., lookup=0x7fff6730) at ../src/ic.cc:438
#17 0x2ac88000 in v8::internal::LoadIC::Load (this=0x7fff67a0, state=v8::internal::UNINITIALIZED, object=..., name=...) at ../src/ic.cc:904
#18 0x2ac88b18 in v8::internal::LoadIC_Miss (args=..., isolate=0x55f038) at ../src/ic.cc:2088
warning: GDB can't find the start of the function at 0x20c0a572.

    GDB is unable to find the start of the function at 0x20c0a572
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
    This problem is most likely caused by an invalid program counter or
stack pointer.
    However, if you think GDB should simply search farther back
from 0x20c0a572 for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
#19 0x20c0a574 in ?? ()
          zero       at       v0       v1       a0       a1       a2       a3
 R0   00000000 7fff67ec 00000002 00000000 0000000a 7fff61a8 7fff61f0 2688405e 
            t0       t1       t2       t3       t4       t5       t6       t7
 R8   24c08091 00000002 00000082 00000003 00000087 00000091 ffffffe0 7fff67fc 
            s0       s1       s2       s3       s4       s5       s6       s7
 R16  2688405e 7fff61a8 24c08091 7fff61f0 25c00498 4d10bf05 fff00000 00000082 
            t8       t9       k0       k1       gp       sp       s8       ra
 R24  00560734 2acf1774 2af36750 00000000 2af36750 7fff6128 7fff67fc 2acf22e0 
        status       lo       hi badvaddr    cause       pc
      00001c13 00008000 00000000 0000000a 00800010 2acf177c 
          fcsr      fir  restart
      00000064 00330100 00000000 
root@ci20-3006:~# 
root@ci20-3006:~# gdb nodejs -ex 'set confirm no' -ex 'r -e "console.log(\"hi\")"' -ex 'backtrace' -ex 'info registers' -ex 'quit'             
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mipsel-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from nodejs...Reading symbols from /usr/lib/debug//usr/bin/nodejs...done.
done.
Starting program: /usr/bin/nodejs -e "console.log(\"hi\")"
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/mipsel-linux-gnu/libthread_db.so.1".
[New Thread 0x2bcf4490 (LWP 719)]

warning: GDB can't find the start of the function at 0x38269204.

    GDB is unable to find the start of the function at 0x38269204
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
    This problem is most likely caused by an invalid program counter or
stack pointer.
    However, if you think GDB should simply search farther back
from 0x38269204 for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.

Program received signal SIGILL, Illegal instruction.
warning: GDB can't find the start of the function at 0x38269204.
0x38269204 in ?? ()
#0  0x38269204 in ?? ()
          zero       at       v0       v1       a0       a1       a2       a3
 R0   00000000 0000029c 0000029c 0057f0c8 0000029c 4d74c979 00000000 4d74c1c4 
            t0       t1       t2       t3       t4       t5       t6       t7
 R8   00005512 37b080c1 80028350 0000053e 4d714371 7fff67d8 2ac8ad34 7fff67d8 
            s0       s1       s2       s3       s4       s5       s6       s7
 R16  ffffffff 7fff67e4 2ac8b920 37b08091 37b08091 37b08091 0055f044 4d714371 
            t8       t9       k0       k1       gp       sp       s8       ra
 R24  00000008 38269200 2af36750 00000000 2af36750 7fff67e8 7fff6804 4cc1862c 
        status       lo       hi badvaddr    cause       pc
      00001f13 00008000 00000000 2ac82d48 00800028 38269204 
---Type <return> to continue, or q <return> to quit---
          fcsr      fir  restart
      00000064 00330000 00000000 
root@ci20-3006:~#

If I had a guess, I'd say some system call is returning garbage

@cjdelisle
Copy link
Author

Sample of running with strace:
while :; do strace -f nodejs -e 'console.log("hi")' 2>&1 | tail; done | tee debug.dump2

(successful entries removed)

[pid  4974] syscall(0x1033, 0x5541efa8, 0x10001, 0x1, 0x2b924750, 0x5541ee41, 0x5541ee80) = 0
[pid  4974] syscall(0x1033, 0x5541efc0, 0x10001, 0x1, 0x2b924750, 0x5541ee41, 0x5541ee80) = 0
[pid  4974] syscall(0x1033, 0x5541ee80, 0x10001, 0x1, 0x2b924750, 0x5541ee41, 0x5541ee80) = 0
[pid  4974] futex(0x2c70046c, FUTEX_WAKE_PRIVATE, 1) = 1
[pid  4975] <... futex resumed> )       = 0
[pid  4975] nanosleep({0, 900000},  <unfinished ...>
[pid  4974] syscall(0x1033, 0x5541eebc, 0x10001, 0x1, 0x2b924750, 0x1, 0x7fba9f1c) = 0
[pid  4974] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} ---
[pid  4975] +++ killed by SIGSEGV +++
+++ killed by SIGSEGV +++

[pid  5054] syscall(0x1033, 0x2d71efa8, 0x10001, 0x1, 0x2b8ff750, 0x2d71ee41, 0x2d71ee80) = 0
[pid  5054] syscall(0x1033, 0x2d71efc0, 0x10001, 0x1, 0x2b8ff750, 0x2d71ee41, 0x2d71ee80) = 0
[pid  5054] syscall(0x1033, 0x2d71ee80, 0x10001, 0x1, 0x2b8ff750, 0x2d71ee41, 0x2d71ee80) = 0
[pid  5054] futex(0x2c70046c, FUTEX_WAKE_PRIVATE, 1) = 1
[pid  5055] <... futex resumed> )       = 0
[pid  5055] nanosleep({0, 900000},  <unfinished ...>
[pid  5054] syscall(0x1033, 0x2d71eebc, 0x10001, 0x1, 0x2b8ff750, 0x1, 0x7f8b8e0c) = 0
[pid  5054] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} ---
[pid  5055] +++ killed by SIGSEGV +++
+++ killed by SIGSEGV +++

[pid  5110] futex(0x2c70046c, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
[pid  5111] <... futex resumed> )       = 0
[pid  5111] nanosleep({0, 900000},  <unfinished ...>
[pid  5110] <... futex resumed> )       = 1
[pid  5110] syscall(0x1033, 0x5ab1eebc, 0x10001, 0x1, 0x2b8ef750, 0x1, 0x7fbdf47c) = 0
[pid  5111] <... nanosleep resumed> NULL) = 0
[pid  5111] nanosleep({0, 900000},  <unfinished ...>
[pid  5110] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} ---
[pid  5111] +++ killed by SIGSEGV +++
+++ killed by SIGSEGV +++

[pid  5182] syscall(0x1033, 0x4551efc0, 0x10001, 0x1, 0x2badd750, 0x4551ee41, 0x4551ee80) = 0
[pid  5182] syscall(0x1033, 0x4551ee80, 0x10001, 0x1, 0x2badd750, 0x4551ee41, 0x4551ee80) = 0
[pid  5182] futex(0x2c90046c, FUTEX_WAKE_PRIVATE, 1) = 1
[pid  5183] <... futex resumed> )       = 0
[pid  5182] syscall(0x1033, 0x4551eebc, 0x10001, 0x1, 0x2badd750, 0x1, 0x7f9ad61c <unfinished ...>
[pid  5183] nanosleep({0, 900000},  <unfinished ...>
[pid  5182] <... syscall resumed> )     = 0
[pid  5182] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} ---
[pid  5183] +++ killed by SIGSEGV +++
+++ killed by SIGSEGV +++

[pid  5198] syscall(0x1033, 0x4e91efc0, 0x10001, 0x1, 0x2af8d750, 0x4e91ee41, 0x4e91ee80) = 0
[pid  5198] syscall(0x1033, 0x4e91ee80, 0x10001, 0x1, 0x2af8d750, 0x4e91ee41, 0x4e91ee80) = 0
[pid  5198] futex(0x2be0046c, FUTEX_WAKE_PRIVATE, 1) = 1
[pid  5199] <... futex resumed> )       = 0
[pid  5199] nanosleep({0, 900000},  <unfinished ...>
[pid  5198] syscall(0x1033, 0x4e91eebc, 0x10001, 0x1, 0x2af8d750, 0x1, 0x7fe7183c) = 0
[pid  5198] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} ---
[pid  5199] <... nanosleep resumed> )   = ? <unavailable>
[pid  5199] +++ killed by SIGSEGV +++
+++ killed by SIGSEGV +++

[pid  5278] syscall(0x1033, 0x4d020008, 0x10001, 0x1, 0x2b5f8750, 0x4d01fea1, 0x4d01fee0) = 0
[pid  5278] syscall(0x1033, 0x4d020020, 0x10001, 0x1, 0x2b5f8750, 0x4d01fea1, 0x4d01fee0) = 0
[pid  5278] syscall(0x1033, 0x4d01fee0, 0x10001, 0x1, 0x2b5f8750, 0x4d01fea1, 0x4d01fee0) = 0
[pid  5278] futex(0x2c40046c, FUTEX_WAKE_PRIVATE, 1) = 1
[pid  5279] <... futex resumed> )       = 0
[pid  5279] nanosleep({0, 900000},  <unfinished ...>
[pid  5278] syscall(0x1033, 0x4d01ff1c, 0x10001, 0x1, 0x2b5f8750, 0x1, 0x7fced9fc) = 0
[pid  5278] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} ---
[pid  5279] +++ killed by SIGSEGV +++
+++ killed by SIGSEGV +++

@ghost
Copy link

ghost commented Feb 24, 2015

syscall 0x1033 = 4000+147 = __NR_cacheflush

@cjdelisle
Copy link
Author

Does not repeat on @ZubairLK 's v3.18 but no SMP so that's not at all surprising.

@chrisdearman
Copy link

You could take a look at the dev-mips-kitkat-v3.0.8 branch which has a number of cacheflush fixes for SMP. As far as I remember these fixes only affected a Java JIT and not V8, but it might be worth trying them as it looks as if there may be SMP cache flushing problems...

@cjdelisle
Copy link
Author

Good news! Repeats on 3.0.8 even with upper memory section dropped and with nosmp on kernel command line, this tells me it might actually be fixed... testing 3.18 next

@cjdelisle
Copy link
Author

More good news (for me), with kernel v3.0.8 and SMP but no high memory section in boot args, the problem does not repeat.

root@ci20-3006:~# uname -a
Linux ci20-3006 3.18.3+ #4 SMP PREEMPT Sat Mar 7 10:25:33 EST 2015 mips GNU/Linux
root@ci20-3006:~# cat /proc/cpuinfo
system type     : JZ4780
machine         : imgtec,ci20
processor       : 0
cpu model       : Ingenic JZRISC V4.15  FPU V0.0
BogoMIPS        : 1196.85
wait instruction    : yes
microsecond timers  : no
tlb_entries     : 32
extra interrupt vector  : yes
hardware watchpoint : yes, count: 1, address/irw mask: [0x0fff]
isa         : mips1 mips2 mips32r1 mips32r2
ASEs implemented    :
shadow register sets    : 1
kscratch registers  : 0
package         : 0
core            : 0
VCED exceptions     : not available
VCEI exceptions     : not available

processor       : 1
cpu model       : Ingenic JZRISC V4.15  FPU V0.0
BogoMIPS        : 4.50
wait instruction    : yes
microsecond timers  : no
tlb_entries     : 32
extra interrupt vector  : yes
hardware watchpoint : yes, count: 1, address/irw mask: [0x0fff]
isa         : mips1 mips2 mips32r1 mips32r2
ASEs implemented    :
shadow register sets    : 1
kscratch registers  : 0
package         : 0
core            : 1
VCED exceptions     : not available
VCEI exceptions     : not available

root@ci20-3006:~# free -h
             total       used       free     shared    buffers     cached
Mem:          244M        80M       164M       4.6M         0B        30M
-/+ buffers/cache:        49M       195M
Swap:           0B         0B         0B
root@ci20-3006:~# for x in {0..100}; do nodejs -e 'console.log("hello")'; done
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
root@ci20-3006:~# 

I cannot test with the high memory section because am unable to get my new kernel to boot with it, I get the following:

[   15.390000] VFS: Mounted root (ubifs filesystem) on device 0:14.
[   15.390000] Freeing unused kernel memory: 244K (80813000 - 80850000)
[   15.480000] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
[   15.480000] 
[   15.490000] drm_kms_helper: panic occurred, switching back to text console
[   15.490000] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
[   15.490000] 

My .config is here: http://sprunge.us/VYAB if anyone has a suggestion how I should change it to be able to boot with the high memory section.

@ZubairLK
Copy link

ZubairLK commented Jul 7, 2015

4c51e3b fixes this in 3.0.8

@ZubairLK ZubairLK closed this as completed Jul 7, 2015
pcercuei pushed a commit to OpenDingux/linux that referenced this issue May 16, 2018
syzbot caught an infinite recursion in nsh_gso_segment().

Problem here is that we need to make sure the NSH header is of
reasonable length.

BUG: MAX_LOCK_DEPTH too low!
turning off the locking correctness validator.
depth: 48  max: 48!
48 locks held by syz-executor0/10189:
 #0:         (ptrval) (rcu_read_lock_bh){....}, at: __dev_queue_xmit+0x30f/0x34c0 net/core/dev.c:3517
 #1:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #1:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #2:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #2:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #3:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #3:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #4:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #4:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #5:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #5:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #6:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #6:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #7:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #7:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #8:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #8:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #9:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #9:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #10:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #10:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #11:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #11:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #12:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #12:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #13:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #13:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #14:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #14:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #15:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #15:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 MIPS#16:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 MIPS#16:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 MIPS#17:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 MIPS#17:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 MIPS#18:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 MIPS#18:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 MIPS#19:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 MIPS#19:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 MIPS#20:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 MIPS#20:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 MIPS#21:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 MIPS#21:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 MIPS#22:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 MIPS#22:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 MIPS#23:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 MIPS#23:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 MIPS#24:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 MIPS#24:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 MIPS#25:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 MIPS#25:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 MIPS#26:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 MIPS#26:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 MIPS#27:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 MIPS#27:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 MIPS#28:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 MIPS#28:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 MIPS#29:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 MIPS#29:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 MIPS#30:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 MIPS#30:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 MIPS#31:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 MIPS#31:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
dccp_close: ABORT with 65423 bytes unread
 MIPS#32:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 MIPS#32:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 MIPS#33:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 MIPS#33:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 MIPS#34:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 MIPS#34:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 MIPS#35:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 MIPS#35:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 MIPS#36:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 MIPS#36:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 MIPS#37:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 MIPS#37:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 MIPS#38:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 MIPS#38:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 MIPS#39:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 MIPS#39:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 MIPS#40:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 MIPS#40:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 MIPS#41:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 MIPS#41:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 MIPS#42:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 MIPS#42:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 MIPS#43:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 MIPS#43:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 MIPS#44:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 MIPS#44:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 MIPS#45:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 MIPS#45:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 MIPS#46:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 MIPS#46:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 MIPS#47:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 MIPS#47:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
INFO: lockdep is turned off.
CPU: 1 PID: 10189 Comm: syz-executor0 Not tainted 4.17.0-rc2+ MIPS#26
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1b9/0x294 lib/dump_stack.c:113
 __lock_acquire+0x1788/0x5140 kernel/locking/lockdep.c:3449
 lock_acquire+0x1dc/0x520 kernel/locking/lockdep.c:3920
 rcu_lock_acquire include/linux/rcupdate.h:246 [inline]
 rcu_read_lock include/linux/rcupdate.h:632 [inline]
 skb_mac_gso_segment+0x25b/0x720 net/core/dev.c:2789
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 __skb_gso_segment+0x3bb/0x870 net/core/dev.c:2865
 skb_gso_segment include/linux/netdevice.h:4025 [inline]
 validate_xmit_skb+0x54d/0xd90 net/core/dev.c:3118
 validate_xmit_skb_list+0xbf/0x120 net/core/dev.c:3168
 sch_direct_xmit+0x354/0x11e0 net/sched/sch_generic.c:312
 qdisc_restart net/sched/sch_generic.c:399 [inline]
 __qdisc_run+0x741/0x1af0 net/sched/sch_generic.c:410
 __dev_xmit_skb net/core/dev.c:3243 [inline]
 __dev_queue_xmit+0x28ea/0x34c0 net/core/dev.c:3551
 dev_queue_xmit+0x17/0x20 net/core/dev.c:3616
 packet_snd net/packet/af_packet.c:2951 [inline]
 packet_sendmsg+0x40f8/0x6070 net/packet/af_packet.c:2976
 sock_sendmsg_nosec net/socket.c:629 [inline]
 sock_sendmsg+0xd5/0x120 net/socket.c:639
 __sys_sendto+0x3d7/0x670 net/socket.c:1789
 __do_sys_sendto net/socket.c:1801 [inline]
 __se_sys_sendto net/socket.c:1797 [inline]
 __x64_sys_sendto+0xe1/0x1a0 net/socket.c:1797
 do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x49/0xbe

Fixes: c411ed8 ("nsh: add GSO support")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jiri Benc <jbenc@redhat.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Acked-by: Jiri Benc <jbenc@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
nemunaire pushed a commit to nemunaire/CI20_linux that referenced this issue Jun 6, 2018
[ Upstream commit 2bbea6e ]

when mounting an ISO filesystem sometimes (very rarely)
the system hangs because of a race condition between two tasks.

PID: 6766   TASK: ffff88007b2a6dd0  CPU: 0   COMMAND: "mount"
 #0 [ffff880078447ae0] __schedule at ffffffff8168d605
 MIPS#1 [ffff880078447b48] schedule_preempt_disabled at ffffffff8168ed49
 MIPS#2 [ffff880078447b58] __mutex_lock_slowpath at ffffffff8168c995
 MIPS#3 [ffff880078447bb8] mutex_lock at ffffffff8168bdef
 MIPS#4 [ffff880078447bd0] sr_block_ioctl at ffffffffa00b6818 [sr_mod]
 MIPS#5 [ffff880078447c10] blkdev_ioctl at ffffffff812fea50
 MIPS#6 [ffff880078447c70] ioctl_by_bdev at ffffffff8123a8b3
 MIPS#7 [ffff880078447c90] isofs_fill_super at ffffffffa04fb1e1 [isofs]
 MIPS#8 [ffff880078447da8] mount_bdev at ffffffff81202570
 MIPS#9 [ffff880078447e18] isofs_mount at ffffffffa04f9828 [isofs]
MIPS#10 [ffff880078447e28] mount_fs at ffffffff81202d09
MIPS#11 [ffff880078447e70] vfs_kern_mount at ffffffff8121ea8f
MIPS#12 [ffff880078447ea8] do_mount at ffffffff81220fee
MIPS#13 [ffff880078447f28] sys_mount at ffffffff812218d6
MIPS#14 [ffff880078447f80] system_call_fastpath at ffffffff81698c49
    RIP: 00007fd9ea914e9a  RSP: 00007ffd5d9bf648  RFLAGS: 00010246
    RAX: 00000000000000a5  RBX: ffffffff81698c49  RCX: 0000000000000010
    RDX: 00007fd9ec2bc210  RSI: 00007fd9ec2bc290  RDI: 00007fd9ec2bcf30
    RBP: 0000000000000000   R8: 0000000000000000   R9: 0000000000000010
    R10: 00000000c0ed0001  R11: 0000000000000206  R12: 00007fd9ec2bc040
    R13: 00007fd9eb6b2380  R14: 00007fd9ec2bc210  R15: 00007fd9ec2bcf30
    ORIG_RAX: 00000000000000a5  CS: 0033  SS: 002b

This task was trying to mount the cdrom.  It allocated and configured a
super_block struct and owned the write-lock for the super_block->s_umount
rwsem. While exclusively owning the s_umount lock, it called
sr_block_ioctl and waited to acquire the global sr_mutex lock.

PID: 6785   TASK: ffff880078720fb0  CPU: 0   COMMAND: "systemd-udevd"
 #0 [ffff880078417898] __schedule at ffffffff8168d605
 MIPS#1 [ffff880078417900] schedule at ffffffff8168dc59
 MIPS#2 [ffff880078417910] rwsem_down_read_failed at ffffffff8168f605
 MIPS#3 [ffff880078417980] call_rwsem_down_read_failed at ffffffff81328838
 MIPS#4 [ffff8800784179d0] down_read at ffffffff8168cde0
 MIPS#5 [ffff8800784179e8] get_super at ffffffff81201cc7
 MIPS#6 [ffff880078417a10] __invalidate_device at ffffffff8123a8de
 MIPS#7 [ffff880078417a40] flush_disk at ffffffff8123a94b
 MIPS#8 [ffff880078417a88] check_disk_change at ffffffff8123ab50
 MIPS#9 [ffff880078417ab0] cdrom_open at ffffffffa00a29e1 [cdrom]
MIPS#10 [ffff880078417b68] sr_block_open at ffffffffa00b6f9b [sr_mod]
MIPS#11 [ffff880078417b98] __blkdev_get at ffffffff8123ba86
MIPS#12 [ffff880078417bf0] blkdev_get at ffffffff8123bd65
MIPS#13 [ffff880078417c78] blkdev_open at ffffffff8123bf9b
MIPS#14 [ffff880078417c90] do_dentry_open at ffffffff811fc7f7
MIPS#15 [ffff880078417cd8] vfs_open at ffffffff811fc9cf
MIPS#16 [ffff880078417d00] do_last at ffffffff8120d53d
MIPS#17 [ffff880078417db0] path_openat at ffffffff8120e6b2
MIPS#18 [ffff880078417e48] do_filp_open at ffffffff8121082b
MIPS#19 [ffff880078417f18] do_sys_open at ffffffff811fdd33
MIPS#20 [ffff880078417f70] sys_open at ffffffff811fde4e
MIPS#21 [ffff880078417f80] system_call_fastpath at ffffffff81698c49
    RIP: 00007f29438b0c20  RSP: 00007ffc76624b78  RFLAGS: 00010246
    RAX: 0000000000000002  RBX: ffffffff81698c49  RCX: 0000000000000000
    RDX: 00007f2944a5fa70  RSI: 00000000000a0800  RDI: 00007f2944a5fa70
    RBP: 00007f2944a5f540   R8: 0000000000000000   R9: 0000000000000020
    R10: 00007f2943614c40  R11: 0000000000000246  R12: ffffffff811fde4e
    R13: ffff880078417f78  R14: 000000000000000c  R15: 00007f2944a4b010
    ORIG_RAX: 0000000000000002  CS: 0033  SS: 002b

This task tried to open the cdrom device, the sr_block_open function
acquired the global sr_mutex lock. The call to check_disk_change()
then saw an event flag indicating a possible media change and tried
to flush any cached data for the device.
As part of the flush, it tried to acquire the super_block->s_umount
lock associated with the cdrom device.
This was the same super_block as created and locked by the previous task.

The first task acquires the s_umount lock and then the sr_mutex_lock;
the second task acquires the sr_mutex_lock and then the s_umount lock.

This patch fixes the issue by moving check_disk_change() out of
cdrom_open() and let the caller take care of it.

Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
pcercuei pushed a commit to OpenDingux/linux that referenced this issue Jul 24, 2018
Crash dump shows following instructions

crash> bt
PID: 0      TASK: ffffffffbe412480  CPU: 0   COMMAND: "swapper/0"
 #0 [ffff891ee0003868] machine_kexec at ffffffffbd063ef1
 #1 [ffff891ee00038c8] __crash_kexec at ffffffffbd12b6f2
 #2 [ffff891ee0003998] crash_kexec at ffffffffbd12c84c
 #3 [ffff891ee00039b8] oops_end at ffffffffbd030f0a
 #4 [ffff891ee00039e0] no_context at ffffffffbd074643
 #5 [ffff891ee0003a40] __bad_area_nosemaphore at ffffffffbd07496e
 #6 [ffff891ee0003a90] bad_area_nosemaphore at ffffffffbd074a64
 #7 [ffff891ee0003aa0] __do_page_fault at ffffffffbd074b0a
 #8 [ffff891ee0003b18] do_page_fault at ffffffffbd074fc8
 #9 [ffff891ee0003b50] page_fault at ffffffffbda01925
    [exception RIP: qlt_schedule_sess_for_deletion+15]
    RIP: ffffffffc02e526f  RSP: ffff891ee0003c08  RFLAGS: 00010046
    RAX: 0000000000000000  RBX: 0000000000000000  RCX: ffffffffc0307847
    RDX: 00000000000020e6  RSI: ffff891edbc377c8  RDI: 0000000000000000
    RBP: ffff891ee0003c18   R8: ffffffffc02f0b20   R9: 0000000000000250
    R10: 0000000000000258  R11: 000000000000b780  R12: ffff891ed9b43000
    R13: 00000000000000f0  R14: 0000000000000006  R15: ffff891edbc377c8
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
 #10 [ffff891ee0003c20] qla2x00_fcport_event_handler at ffffffffc02853d3 [qla2xxx]
 #11 [ffff891ee0003cf0] __dta_qla24xx_async_gnl_sp_done_333 at ffffffffc0285a1d [qla2xxx]
 #12 [ffff891ee0003de8] qla24xx_process_response_queue at ffffffffc02a2eb5 [qla2xxx]
 #13 [ffff891ee0003e88] qla24xx_msix_rsp_q at ffffffffc02a5403 [qla2xxx]
 #14 [ffff891ee0003ec0] __handle_irq_event_percpu at ffffffffbd0f4c59
 #15 [ffff891ee0003f10] handle_irq_event_percpu at ffffffffbd0f4e02
 MIPS#16 [ffff891ee0003f40] handle_irq_event at ffffffffbd0f4e90
 MIPS#17 [ffff891ee0003f68] handle_edge_irq at ffffffffbd0f8984
 MIPS#18 [ffff891ee0003f88] handle_irq at ffffffffbd0305d5
 MIPS#19 [ffff891ee0003fb8] do_IRQ at ffffffffbda02a18
 --- <IRQ stack> ---
 MIPS#20 [ffffffffbe403d30] ret_from_intr at ffffffffbda0094e
    [exception RIP: unknown or invalid address]
    RIP: 000000000000001f  RSP: 0000000000000000  RFLAGS: fff3b8c2091ebb3f
    RAX: ffffbba5a0000200  RBX: 0000be8cdfa8f9fa  RCX: 0000000000000018
    RDX: 0000000000000101  RSI: 000000000000015d  RDI: 0000000000000193
    RBP: 0000000000000083   R8: ffffffffbe403e38   R9: 0000000000000002
    R10: 0000000000000000  R11: ffffffffbe56b820  R12: ffff891ee001cf00
    R13: ffffffffbd11c0a4  R14: ffffffffbe403d60  R15: 0000000000000001
    ORIG_RAX: ffff891ee0022ac0  CS: 0000  SS: ffffffffffffffb9
 bt: WARNING: possibly bogus exception frame
 MIPS#21 [ffffffffbe403dd8] cpuidle_enter_state at ffffffffbd67c6fd
 MIPS#22 [ffffffffbe403e40] cpuidle_enter at ffffffffbd67c907
 MIPS#23 [ffffffffbe403e50] call_cpuidle at ffffffffbd0d98f3
 MIPS#24 [ffffffffbe403e60] do_idle at ffffffffbd0d9b42
 MIPS#25 [ffffffffbe403e98] cpu_startup_entry at ffffffffbd0d9da3
 MIPS#26 [ffffffffbe403ec0] rest_init at ffffffffbd81d4aa
 MIPS#27 [ffffffffbe403ed0] start_kernel at ffffffffbe67d2ca
 MIPS#28 [ffffffffbe403f28] x86_64_start_reservations at ffffffffbe67c675
 MIPS#29 [ffffffffbe403f38] x86_64_start_kernel at ffffffffbe67c6eb
 MIPS#30 [ffffffffbe403f50] secondary_startup_64 at ffffffffbd0000d5

Fixes: 040036b ("scsi: qla2xxx: Delay loop id allocation at login")
Cc: <stable@vger.kernel.org> # v4.17+
Signed-off-by: Chuck Anderson <chuck.anderson@oracle.com>
Signed-off-by: Himanshu Madhani <himanshu.madhani@cavium.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
pcercuei pushed a commit to OpenDingux/linux that referenced this issue Feb 24, 2019
[ Upstream commit 85744e9 ]

A bad job is the one triggered TDR(In the current amdgpu's
implementation, actually all the jobs in the current joq-queue will
be treated as bad jobs). In the recovery process, its fence
will be fake signaled and as a result, the work behind will be scheduled
to delete it from the mirror list, but if the TDR process is invoked
before the work's execution, then this bad job might be processed again
and the call dma_fence_set_error to its fence in TDR process will lead to
kernel warning trace:

[  143.033605] WARNING: CPU: 2 PID: 53 at ./include/linux/dma-fence.h:437 amddrm_sched_job_recovery+0x1af/0x1c0 [amd_sched]
kernel: [  143.033606] Modules linked in: amdgpu(OE) amdchash(OE) amdttm(OE) amd_sched(OE) amdkcl(OE) amd_iommu_v2 drm_kms_helper drm i2c_algo_bit fb_sys_fops syscopyarea sysfillrect sysimgblt kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 snd_hda_codec_generic crypto_simd glue_helper cryptd snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq joydev snd_seq_device snd_timer snd soundcore binfmt_misc input_leds mac_hid serio_raw nfsd auth_rpcgss nfs_acl lockd grace sunrpc sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 8139too floppy psmouse 8139cp mii i2c_piix4 pata_acpi
[  143.033649] CPU: 2 PID: 53 Comm: kworker/2:1 Tainted: G           OE    4.15.0-20-generic MIPS#21-Ubuntu
[  143.033650] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
[  143.033653] Workqueue: events drm_sched_job_timedout [amd_sched]
[  143.033656] RIP: 0010:amddrm_sched_job_recovery+0x1af/0x1c0 [amd_sched]
[  143.033657] RSP: 0018:ffffa9f880fe7d48 EFLAGS: 00010202
[  143.033659] RAX: 0000000000000007 RBX: ffff9b98f2b24c00 RCX: ffff9b98efef4f08
[  143.033660] RDX: ffff9b98f2b27400 RSI: ffff9b98f2b24c50 RDI: ffff9b98efef4f18
[  143.033660] RBP: ffffa9f880fe7d98 R08: 0000000000000001 R09: 00000000000002b6
[  143.033661] R10: 0000000000000000 R11: 0000000000000000 R12: ffff9b98efef3430
[  143.033662] R13: ffff9b98efef4d80 R14: ffff9b98efef4e98 R15: ffff9b98eaf91c00
[  143.033663] FS:  0000000000000000(0000) GS:ffff9b98ffd00000(0000) knlGS:0000000000000000
[  143.033664] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  143.033665] CR2: 00007fc49c96d470 CR3: 000000001400a005 CR4: 00000000003606e0
[  143.033669] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  143.033669] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  143.033670] Call Trace:
[  143.033744]  amdgpu_device_gpu_recover+0x144/0x820 [amdgpu]
[  143.033788]  amdgpu_job_timedout+0x9b/0xa0 [amdgpu]
[  143.033791]  drm_sched_job_timedout+0xcc/0x150 [amd_sched]
[  143.033795]  process_one_work+0x1de/0x410
[  143.033797]  worker_thread+0x32/0x410
[  143.033799]  kthread+0x121/0x140
[  143.033801]  ? process_one_work+0x410/0x410
[  143.033803]  ? kthread_create_worker_on_cpu+0x70/0x70
[  143.033806]  ret_from_fork+0x35/0x40

So just delete the bad job from mirror list directly

Changes in v3:
	- Add a helper function to delete the bad jobs from mirror list and call
		it directly *before* the job's fence is signaled

Changes in v2:
	- delete the useless list node check
	- also delete bad jobs in drm_sched_main because:
		kthread_unpark(ring->sched.thread) will be invoked very early before
		amdgpu_device_gpu_recover's return, then drm_sched_main will have
		chance to pick up a new job from the job queue. This new job will be
		added into the mirror list and processed by amdgpu_job_run, but may
		not be deleted from the mirror list on time due to the same reason.
		And finally re-processed by drm_sched_job_recovery

Signed-off-by: Trigger Huang <Trigger.Huang@amd.com>
Reviewed-by: Christian König <chrstian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
pcercuei pushed a commit to OpenDingux/linux that referenced this issue Feb 24, 2019
[ Upstream commit b058809 ]

A bug is present in GDB which causes early string termination when
parsing variables.  This has been reported [0], but we should ensure
that we can support at least basic printing of the core kernel strings.

For current gdb version (has been tested with 7.3 and 8.1), 'lx-version'
only prints one character.

  (gdb) lx-version
  L(gdb)

This can be fixed by casting 'linux_banner' as (char *).

  (gdb) lx-version
  Linux version 4.19.0-rc1+ (changbin@acer) (gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)) MIPS#21 SMP Sat Sep 1 21:43:30 CST 2018

[0] https://sourceware.org/bugzilla/show_bug.cgi?id=20077

[kbingham@kernel.org: add detail to commit message]
Link: http://lkml.kernel.org/r/20181111162035.8356-1-kieran.bingham@ideasonboard.com
Fixes: 2d061d9 ("scripts/gdb: add version command")
Signed-off-by: Du Changbin <changbin.du@gmail.com>
Signed-off-by: Kieran Bingham <kbingham@kernel.org>
Acked-by: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Jason Wessel <jason.wessel@windriver.com>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
pcercuei pushed a commit to OpenDingux/linux that referenced this issue Jun 2, 2019
af_inet sets sock->sk to NULL which trips strparser over:

BUG: kernel NULL pointer dereference, address: 0000000000000012
PGD 0 P4D 0
Oops: 0000 [#1] SMP PTI
CPU: 7 PID: 0 Comm: swapper/7 Not tainted 5.2.0-rc1-00139-g14629453a6d3 MIPS#21
RIP: 0010:tcp_peek_len+0x10/0x60
RSP: 0018:ffffc02e41c54b98 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff9cf924c4e030 RCX: 0000000000000051
RDX: 0000000000000000 RSI: 000000000000000c RDI: ffff9cf97128f480
RBP: ffff9cf9365e0300 R08: ffff9cf94fe7d2c0 R09: 0000000000000000
R10: 000000000000036b R11: ffff9cf939735e00 R12: ffff9cf91ad9ae40
R13: ffff9cf924c4e000 R14: ffff9cf9a8fcbaae R15: 0000000000000020
FS: 0000000000000000(0000) GS:ffff9cf9af7c0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000012 CR3: 000000013920a003 CR4: 00000000003606e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 Call Trace:
 <IRQ>
 strp_data_ready+0x48/0x90
 tls_data_ready+0x22/0xd0 [tls]
 tcp_rcv_established+0x569/0x620
 tcp_v4_do_rcv+0x127/0x1e0
 tcp_v4_rcv+0xad7/0xbf0
 ip_protocol_deliver_rcu+0x2c/0x1c0
 ip_local_deliver_finish+0x41/0x50
 ip_local_deliver+0x6b/0xe0
 ? ip_protocol_deliver_rcu+0x1c0/0x1c0
 ip_rcv+0x52/0xd0
 ? ip_rcv_finish_core.isra.20+0x380/0x380
 __netif_receive_skb_one_core+0x7e/0x90
 netif_receive_skb_internal+0x42/0xf0
 napi_gro_receive+0xed/0x150
 nfp_net_poll+0x7a2/0xd30 [nfp]
 ? kmem_cache_free_bulk+0x286/0x310
 net_rx_action+0x149/0x3b0
 __do_softirq+0xe3/0x30a
 ? handle_irq_event_percpu+0x6a/0x80
 irq_exit+0xe8/0xf0
 do_IRQ+0x85/0xd0
 common_interrupt+0xf/0xf
 </IRQ>
RIP: 0010:cpuidle_enter_state+0xbc/0x450

To avoid this issue set sock->sk after sk_prot->close.
My grepping and testing did not discover any code which
would depend on the current behaviour.

Fixes: c46234e ("tls: RX path for ktls")
Reported-by: David Beckett <david.beckett@netronome.com>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
pcercuei pushed a commit to OpenDingux/linux that referenced this issue Jan 7, 2020
Some QPs (e.g. XRC QP) are not tracked in kernel, in this case they have
an invalid res and should not be bound to any dynamically-allocated
counter in auto mode.

This fixes below call trace:
BUG: kernel NULL pointer dereference, address: 0000000000000390
PGD 80000001a7233067 P4D 80000001a7233067 PUD 1a7215067 PMD 0
Oops: 0000 [#1] SMP PTI
CPU: 2 PID: 24822 Comm: ibv_xsrq_pingpo Not tainted 5.4.0-rc5+ MIPS#21
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014
RIP: 0010:rdma_counter_bind_qp_auto+0x142/0x270 [ib_core]
Code: e1 48 85 c0 48 89 c2 0f 84 bc 00 00 00 49 8b 06 48 39 42 48 75 d6 40 3a aa 90 00 00 00 75 cd 49 8b 86 00 01 00 00 48 8b 4a 28 <8b> 80 90 03 00 00 39 81 90 03 00 00 75 b4 85 c0 74 b0 48 8b 04 24
RSP: 0018:ffffc900003f39c0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000
RDX: ffff88820020ec00 RSI: 0000000000000004 RDI: ffffffffffffffc0
RBP: 0000000000000001 R08: ffff888224149ff0 R09: ffffc900003f3968
R10: ffffffffffffffff R11: ffff8882249c5848 R12: ffffffffffffffff
R13: ffff88821d5aca50 R14: ffff8881f7690800 R15: ffff8881ff890000
FS:  00007fe53a3e1740(0000) GS:ffff888237b00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000390 CR3: 00000001a7292006 CR4: 00000000003606a0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 _ib_modify_qp+0x3a4/0x3f0 [ib_core]
 ? lookup_get_idr_uobject.part.8+0x23/0x40 [ib_uverbs]
 modify_qp+0x322/0x3e0 [ib_uverbs]
 ib_uverbs_modify_qp+0x43/0x70 [ib_uverbs]
 ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xb1/0xf0 [ib_uverbs]
 ib_uverbs_run_method+0x6be/0x760 [ib_uverbs]
 ? uverbs_disassociate_api+0xd0/0xd0 [ib_uverbs]
 ib_uverbs_cmd_verbs+0x18d/0x3a0 [ib_uverbs]
 ? get_acl+0x1a/0x120
 ? __alloc_pages_nodemask+0x15d/0x2c0
 ib_uverbs_ioctl+0xa7/0x110 [ib_uverbs]
 do_vfs_ioctl+0xa5/0x610
 ksys_ioctl+0x60/0x90
 __x64_sys_ioctl+0x16/0x20
 do_syscall_64+0x48/0x110
 entry_SYSCALL_64_after_hwframe+0x44/0xa9

Fixes: 99fa331 ("RDMA/counter: Add "auto" configuration mode support")
Signed-off-by: Mark Zhang <markz@mellanox.com>
Reviewed-by: Maor Gottlieb <maorg@mellanox.com>
Reviewed-by: Ido Kalir <idok@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Link: https://lore.kernel.org/r/20191212091214.315005-2-leon@kernel.org
Signed-off-by: Doug Ledford <dledford@redhat.com>
pcercuei pushed a commit to OpenDingux/linux that referenced this issue Mar 31, 2020
When experimenting with bpf_send_signal() helper in our production
environment (5.2 based), we experienced a deadlock in NMI mode:
   #5 [ffffc9002219f770] queued_spin_lock_slowpath at ffffffff8110be24
   #6 [ffffc9002219f770] _raw_spin_lock_irqsave at ffffffff81a43012
   #7 [ffffc9002219f780] try_to_wake_up at ffffffff810e7ecd
   #8 [ffffc9002219f7e0] signal_wake_up_state at ffffffff810c7b55
   #9 [ffffc9002219f7f0] __send_signal at ffffffff810c8602
  #10 [ffffc9002219f830] do_send_sig_info at ffffffff810ca31a
  #11 [ffffc9002219f868] bpf_send_signal at ffffffff8119d227
  #12 [ffffc9002219f988] bpf_overflow_handler at ffffffff811d4140
  #13 [ffffc9002219f9e0] __perf_event_overflow at ffffffff811d68cf
  #14 [ffffc9002219fa10] perf_swevent_overflow at ffffffff811d6a09
  #15 [ffffc9002219fa38] ___perf_sw_event at ffffffff811e0f47
  MIPS#16 [ffffc9002219fc30] __schedule at ffffffff81a3e04d
  MIPS#17 [ffffc9002219fc90] schedule at ffffffff81a3e219
  MIPS#18 [ffffc9002219fca0] futex_wait_queue_me at ffffffff8113d1b9
  MIPS#19 [ffffc9002219fcd8] futex_wait at ffffffff8113e529
  MIPS#20 [ffffc9002219fdf0] do_futex at ffffffff8113ffbc
  MIPS#21 [ffffc9002219fec0] __x64_sys_futex at ffffffff81140d1c
  MIPS#22 [ffffc9002219ff38] do_syscall_64 at ffffffff81002602
  MIPS#23 [ffffc9002219ff50] entry_SYSCALL_64_after_hwframe at ffffffff81c00068

The above call stack is actually very similar to an issue
reported by Commit eac9153 ("bpf/stackmap: Fix deadlock with
rq_lock in bpf_get_stack()") by Song Liu. The only difference is
bpf_send_signal() helper instead of bpf_get_stack() helper.

The above deadlock is triggered with a perf_sw_event.
Similar to Commit eac9153, the below almost identical reproducer
used tracepoint point sched/sched_switch so the issue can be easily caught.
  /* stress_test.c */
  #include <stdio.h>
  #include <stdlib.h>
  #include <sys/mman.h>
  #include <pthread.h>
  #include <sys/types.h>
  #include <sys/stat.h>
  #include <fcntl.h>

  #define THREAD_COUNT 1000
  char *filename;
  void *worker(void *p)
  {
        void *ptr;
        int fd;
        char *pptr;

        fd = open(filename, O_RDONLY);
        if (fd < 0)
                return NULL;
        while (1) {
                struct timespec ts = {0, 1000 + rand() % 2000};

                ptr = mmap(NULL, 4096 * 64, PROT_READ, MAP_PRIVATE, fd, 0);
                usleep(1);
                if (ptr == MAP_FAILED) {
                        printf("failed to mmap\n");
                        break;
                }
                munmap(ptr, 4096 * 64);
                usleep(1);
                pptr = malloc(1);
                usleep(1);
                pptr[0] = 1;
                usleep(1);
                free(pptr);
                usleep(1);
                nanosleep(&ts, NULL);
        }
        close(fd);
        return NULL;
  }

  int main(int argc, char *argv[])
  {
        void *ptr;
        int i;
        pthread_t threads[THREAD_COUNT];

        if (argc < 2)
                return 0;

        filename = argv[1];

        for (i = 0; i < THREAD_COUNT; i++) {
                if (pthread_create(threads + i, NULL, worker, NULL)) {
                        fprintf(stderr, "Error creating thread\n");
                        return 0;
                }
        }

        for (i = 0; i < THREAD_COUNT; i++)
                pthread_join(threads[i], NULL);
        return 0;
  }
and the following command:
  1. run `stress_test /bin/ls` in one windown
  2. hack bcc trace.py with the following change:
     --- a/tools/trace.py
     +++ b/tools/trace.py
     @@ -513,6 +513,7 @@ BPF_PERF_OUTPUT(%s);
              __data.tgid = __tgid;
              __data.pid = __pid;
              bpf_get_current_comm(&__data.comm, sizeof(__data.comm));
     +        bpf_send_signal(10);
      %s
      %s
              %s.perf_submit(%s, &__data, sizeof(__data));
  3. in a different window run
     ./trace.py -p $(pidof stress_test) t:sched:sched_switch

The deadlock can be reproduced in our production system.

Similar to Song's fix, the fix is to delay sending signal if
irqs is disabled to avoid deadlocks involving with rq_lock.
With this change, my above stress-test in our production system
won't cause deadlock any more.

I also implemented a scale-down version of reproducer in the
selftest (a subsequent commit). With latest bpf-next,
it complains for the following potential deadlock.
  [   32.832450] -> #1 (&p->pi_lock){-.-.}:
  [   32.833100]        _raw_spin_lock_irqsave+0x44/0x80
  [   32.833696]        task_rq_lock+0x2c/0xa0
  [   32.834182]        task_sched_runtime+0x59/0xd0
  [   32.834721]        thread_group_cputime+0x250/0x270
  [   32.835304]        thread_group_cputime_adjusted+0x2e/0x70
  [   32.835959]        do_task_stat+0x8a7/0xb80
  [   32.836461]        proc_single_show+0x51/0xb0
  ...
  [   32.839512] -> #0 (&(&sighand->siglock)->rlock){....}:
  [   32.840275]        __lock_acquire+0x1358/0x1a20
  [   32.840826]        lock_acquire+0xc7/0x1d0
  [   32.841309]        _raw_spin_lock_irqsave+0x44/0x80
  [   32.841916]        __lock_task_sighand+0x79/0x160
  [   32.842465]        do_send_sig_info+0x35/0x90
  [   32.842977]        bpf_send_signal+0xa/0x10
  [   32.843464]        bpf_prog_bc13ed9e4d3163e3_send_signal_tp_sched+0x465/0x1000
  [   32.844301]        trace_call_bpf+0x115/0x270
  [   32.844809]        perf_trace_run_bpf_submit+0x4a/0xc0
  [   32.845411]        perf_trace_sched_switch+0x10f/0x180
  [   32.846014]        __schedule+0x45d/0x880
  [   32.846483]        schedule+0x5f/0xd0
  ...

  [   32.853148] Chain exists of:
  [   32.853148]   &(&sighand->siglock)->rlock --> &p->pi_lock --> &rq->lock
  [   32.853148]
  [   32.854451]  Possible unsafe locking scenario:
  [   32.854451]
  [   32.855173]        CPU0                    CPU1
  [   32.855745]        ----                    ----
  [   32.856278]   lock(&rq->lock);
  [   32.856671]                                lock(&p->pi_lock);
  [   32.857332]                                lock(&rq->lock);
  [   32.857999]   lock(&(&sighand->siglock)->rlock);

  Deadlock happens on CPU0 when it tries to acquire &sighand->siglock
  but it has been held by CPU1 and CPU1 tries to grab &rq->lock
  and cannot get it.

  This is not exactly the callstack in our production environment,
  but sympotom is similar and both locks are using spin_lock_irqsave()
  to acquire the lock, and both involves rq_lock. The fix to delay
  sending signal when irq is disabled also fixed this issue.

Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Cc: Song Liu <songliubraving@fb.com>
Link: https://lore.kernel.org/bpf/20200304191104.2796501-1-yhs@fb.com
pcercuei pushed a commit to OpenDingux/linux that referenced this issue Nov 28, 2020
This fix is for a failure that occurred in the DWARF unwind perf test.

Stack unwinders may probe memory when looking for frames.

Memory sanitizer will poison and track uninitialized memory on the
stack, and on the heap if the value is copied to the heap.

This can lead to false memory sanitizer failures for the use of an
uninitialized value.

Avoid this problem by removing the poison on the copied stack.

The full msan failure with track origins looks like:

==2168==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x559ceb10755b in handle_cfi elfutils/libdwfl/frame_unwind.c:648:8
    #1 0x559ceb105448 in __libdwfl_frame_unwind elfutils/libdwfl/frame_unwind.c:741:4
    #2 0x559ceb0ece90 in dwfl_thread_getframes elfutils/libdwfl/dwfl_frame.c:435:7
    #3 0x559ceb0ec6b7 in get_one_thread_frames_cb elfutils/libdwfl/dwfl_frame.c:379:10
    #4 0x559ceb0ec6b7 in get_one_thread_cb elfutils/libdwfl/dwfl_frame.c:308:17
    #5 0x559ceb0ec6b7 in dwfl_getthreads elfutils/libdwfl/dwfl_frame.c:283:17
    #6 0x559ceb0ec6b7 in getthread elfutils/libdwfl/dwfl_frame.c:354:14
    #7 0x559ceb0ec6b7 in dwfl_getthread_frames elfutils/libdwfl/dwfl_frame.c:388:10
    #8 0x559ceaff6ae6 in unwind__get_entries tools/perf/util/unwind-libdw.c:236:8
    #9 0x559ceabc9dbc in test_dwarf_unwind__thread tools/perf/tests/dwarf-unwind.c:111:8
    #10 0x559ceabca5cf in test_dwarf_unwind__compare tools/perf/tests/dwarf-unwind.c:138:26
    #11 0x7f812a6865b0 in bsearch (libc.so.6+0x4e5b0)
    #12 0x559ceabca871 in test_dwarf_unwind__krava_3 tools/perf/tests/dwarf-unwind.c:162:2
    #13 0x559ceabca926 in test_dwarf_unwind__krava_2 tools/perf/tests/dwarf-unwind.c:169:9
    #14 0x559ceabca946 in test_dwarf_unwind__krava_1 tools/perf/tests/dwarf-unwind.c:174:9
    #15 0x559ceabcae12 in test__dwarf_unwind tools/perf/tests/dwarf-unwind.c:211:8
    MIPS#16 0x559ceabbc4ab in run_test tools/perf/tests/builtin-test.c:418:9
    MIPS#17 0x559ceabbc4ab in test_and_print tools/perf/tests/builtin-test.c:448:9
    MIPS#18 0x559ceabbac70 in __cmd_test tools/perf/tests/builtin-test.c:669:4
    MIPS#19 0x559ceabbac70 in cmd_test tools/perf/tests/builtin-test.c:815:9
    MIPS#20 0x559cea960e30 in run_builtin tools/perf/perf.c:313:11
    MIPS#21 0x559cea95fbce in handle_internal_command tools/perf/perf.c:365:8
    MIPS#22 0x559cea95fbce in run_argv tools/perf/perf.c:409:2
    MIPS#23 0x559cea95fbce in main tools/perf/perf.c:539:3

  Uninitialized value was stored to memory at
    #0 0x559ceb106acf in __libdwfl_frame_reg_set elfutils/libdwfl/frame_unwind.c:77:22
    #1 0x559ceb106acf in handle_cfi elfutils/libdwfl/frame_unwind.c:627:13
    #2 0x559ceb105448 in __libdwfl_frame_unwind elfutils/libdwfl/frame_unwind.c:741:4
    #3 0x559ceb0ece90 in dwfl_thread_getframes elfutils/libdwfl/dwfl_frame.c:435:7
    #4 0x559ceb0ec6b7 in get_one_thread_frames_cb elfutils/libdwfl/dwfl_frame.c:379:10
    #5 0x559ceb0ec6b7 in get_one_thread_cb elfutils/libdwfl/dwfl_frame.c:308:17
    #6 0x559ceb0ec6b7 in dwfl_getthreads elfutils/libdwfl/dwfl_frame.c:283:17
    #7 0x559ceb0ec6b7 in getthread elfutils/libdwfl/dwfl_frame.c:354:14
    #8 0x559ceb0ec6b7 in dwfl_getthread_frames elfutils/libdwfl/dwfl_frame.c:388:10
    #9 0x559ceaff6ae6 in unwind__get_entries tools/perf/util/unwind-libdw.c:236:8
    #10 0x559ceabc9dbc in test_dwarf_unwind__thread tools/perf/tests/dwarf-unwind.c:111:8
    #11 0x559ceabca5cf in test_dwarf_unwind__compare tools/perf/tests/dwarf-unwind.c:138:26
    #12 0x7f812a6865b0 in bsearch (libc.so.6+0x4e5b0)
    #13 0x559ceabca871 in test_dwarf_unwind__krava_3 tools/perf/tests/dwarf-unwind.c:162:2
    #14 0x559ceabca926 in test_dwarf_unwind__krava_2 tools/perf/tests/dwarf-unwind.c:169:9
    #15 0x559ceabca946 in test_dwarf_unwind__krava_1 tools/perf/tests/dwarf-unwind.c:174:9
    MIPS#16 0x559ceabcae12 in test__dwarf_unwind tools/perf/tests/dwarf-unwind.c:211:8
    MIPS#17 0x559ceabbc4ab in run_test tools/perf/tests/builtin-test.c:418:9
    MIPS#18 0x559ceabbc4ab in test_and_print tools/perf/tests/builtin-test.c:448:9
    MIPS#19 0x559ceabbac70 in __cmd_test tools/perf/tests/builtin-test.c:669:4
    MIPS#20 0x559ceabbac70 in cmd_test tools/perf/tests/builtin-test.c:815:9
    MIPS#21 0x559cea960e30 in run_builtin tools/perf/perf.c:313:11
    MIPS#22 0x559cea95fbce in handle_internal_command tools/perf/perf.c:365:8
    MIPS#23 0x559cea95fbce in run_argv tools/perf/perf.c:409:2
    MIPS#24 0x559cea95fbce in main tools/perf/perf.c:539:3

  Uninitialized value was stored to memory at
    #0 0x559ceb106a54 in handle_cfi elfutils/libdwfl/frame_unwind.c:613:9
    #1 0x559ceb105448 in __libdwfl_frame_unwind elfutils/libdwfl/frame_unwind.c:741:4
    #2 0x559ceb0ece90 in dwfl_thread_getframes elfutils/libdwfl/dwfl_frame.c:435:7
    #3 0x559ceb0ec6b7 in get_one_thread_frames_cb elfutils/libdwfl/dwfl_frame.c:379:10
    #4 0x559ceb0ec6b7 in get_one_thread_cb elfutils/libdwfl/dwfl_frame.c:308:17
    #5 0x559ceb0ec6b7 in dwfl_getthreads elfutils/libdwfl/dwfl_frame.c:283:17
    #6 0x559ceb0ec6b7 in getthread elfutils/libdwfl/dwfl_frame.c:354:14
    #7 0x559ceb0ec6b7 in dwfl_getthread_frames elfutils/libdwfl/dwfl_frame.c:388:10
    #8 0x559ceaff6ae6 in unwind__get_entries tools/perf/util/unwind-libdw.c:236:8
    #9 0x559ceabc9dbc in test_dwarf_unwind__thread tools/perf/tests/dwarf-unwind.c:111:8
    #10 0x559ceabca5cf in test_dwarf_unwind__compare tools/perf/tests/dwarf-unwind.c:138:26
    #11 0x7f812a6865b0 in bsearch (libc.so.6+0x4e5b0)
    #12 0x559ceabca871 in test_dwarf_unwind__krava_3 tools/perf/tests/dwarf-unwind.c:162:2
    #13 0x559ceabca926 in test_dwarf_unwind__krava_2 tools/perf/tests/dwarf-unwind.c:169:9
    #14 0x559ceabca946 in test_dwarf_unwind__krava_1 tools/perf/tests/dwarf-unwind.c:174:9
    #15 0x559ceabcae12 in test__dwarf_unwind tools/perf/tests/dwarf-unwind.c:211:8
    MIPS#16 0x559ceabbc4ab in run_test tools/perf/tests/builtin-test.c:418:9
    MIPS#17 0x559ceabbc4ab in test_and_print tools/perf/tests/builtin-test.c:448:9
    MIPS#18 0x559ceabbac70 in __cmd_test tools/perf/tests/builtin-test.c:669:4
    MIPS#19 0x559ceabbac70 in cmd_test tools/perf/tests/builtin-test.c:815:9
    MIPS#20 0x559cea960e30 in run_builtin tools/perf/perf.c:313:11
    MIPS#21 0x559cea95fbce in handle_internal_command tools/perf/perf.c:365:8
    MIPS#22 0x559cea95fbce in run_argv tools/perf/perf.c:409:2
    MIPS#23 0x559cea95fbce in main tools/perf/perf.c:539:3

  Uninitialized value was stored to memory at
    #0 0x559ceaff8800 in memory_read tools/perf/util/unwind-libdw.c:156:10
    #1 0x559ceb10f053 in expr_eval elfutils/libdwfl/frame_unwind.c:501:13
    #2 0x559ceb1060cc in handle_cfi elfutils/libdwfl/frame_unwind.c:603:18
    #3 0x559ceb105448 in __libdwfl_frame_unwind elfutils/libdwfl/frame_unwind.c:741:4
    #4 0x559ceb0ece90 in dwfl_thread_getframes elfutils/libdwfl/dwfl_frame.c:435:7
    #5 0x559ceb0ec6b7 in get_one_thread_frames_cb elfutils/libdwfl/dwfl_frame.c:379:10
    #6 0x559ceb0ec6b7 in get_one_thread_cb elfutils/libdwfl/dwfl_frame.c:308:17
    #7 0x559ceb0ec6b7 in dwfl_getthreads elfutils/libdwfl/dwfl_frame.c:283:17
    #8 0x559ceb0ec6b7 in getthread elfutils/libdwfl/dwfl_frame.c:354:14
    #9 0x559ceb0ec6b7 in dwfl_getthread_frames elfutils/libdwfl/dwfl_frame.c:388:10
    #10 0x559ceaff6ae6 in unwind__get_entries tools/perf/util/unwind-libdw.c:236:8
    #11 0x559ceabc9dbc in test_dwarf_unwind__thread tools/perf/tests/dwarf-unwind.c:111:8
    #12 0x559ceabca5cf in test_dwarf_unwind__compare tools/perf/tests/dwarf-unwind.c:138:26
    #13 0x7f812a6865b0 in bsearch (libc.so.6+0x4e5b0)
    #14 0x559ceabca871 in test_dwarf_unwind__krava_3 tools/perf/tests/dwarf-unwind.c:162:2
    #15 0x559ceabca926 in test_dwarf_unwind__krava_2 tools/perf/tests/dwarf-unwind.c:169:9
    MIPS#16 0x559ceabca946 in test_dwarf_unwind__krava_1 tools/perf/tests/dwarf-unwind.c:174:9
    MIPS#17 0x559ceabcae12 in test__dwarf_unwind tools/perf/tests/dwarf-unwind.c:211:8
    MIPS#18 0x559ceabbc4ab in run_test tools/perf/tests/builtin-test.c:418:9
    MIPS#19 0x559ceabbc4ab in test_and_print tools/perf/tests/builtin-test.c:448:9
    MIPS#20 0x559ceabbac70 in __cmd_test tools/perf/tests/builtin-test.c:669:4
    MIPS#21 0x559ceabbac70 in cmd_test tools/perf/tests/builtin-test.c:815:9
    MIPS#22 0x559cea960e30 in run_builtin tools/perf/perf.c:313:11
    MIPS#23 0x559cea95fbce in handle_internal_command tools/perf/perf.c:365:8
    MIPS#24 0x559cea95fbce in run_argv tools/perf/perf.c:409:2
    MIPS#25 0x559cea95fbce in main tools/perf/perf.c:539:3

  Uninitialized value was stored to memory at
    #0 0x559cea9027d9 in __msan_memcpy llvm/llvm-project/compiler-rt/lib/msan/msan_interceptors.cpp:1558:3
    #1 0x559cea9d2185 in sample_ustack tools/perf/arch/x86/tests/dwarf-unwind.c:41:2
    #2 0x559cea9d202c in test__arch_unwind_sample tools/perf/arch/x86/tests/dwarf-unwind.c:72:9
    #3 0x559ceabc9cbd in test_dwarf_unwind__thread tools/perf/tests/dwarf-unwind.c:106:6
    #4 0x559ceabca5cf in test_dwarf_unwind__compare tools/perf/tests/dwarf-unwind.c:138:26
    #5 0x7f812a6865b0 in bsearch (libc.so.6+0x4e5b0)
    #6 0x559ceabca871 in test_dwarf_unwind__krava_3 tools/perf/tests/dwarf-unwind.c:162:2
    #7 0x559ceabca926 in test_dwarf_unwind__krava_2 tools/perf/tests/dwarf-unwind.c:169:9
    #8 0x559ceabca946 in test_dwarf_unwind__krava_1 tools/perf/tests/dwarf-unwind.c:174:9
    #9 0x559ceabcae12 in test__dwarf_unwind tools/perf/tests/dwarf-unwind.c:211:8
    #10 0x559ceabbc4ab in run_test tools/perf/tests/builtin-test.c:418:9
    #11 0x559ceabbc4ab in test_and_print tools/perf/tests/builtin-test.c:448:9
    #12 0x559ceabbac70 in __cmd_test tools/perf/tests/builtin-test.c:669:4
    #13 0x559ceabbac70 in cmd_test tools/perf/tests/builtin-test.c:815:9
    #14 0x559cea960e30 in run_builtin tools/perf/perf.c:313:11
    #15 0x559cea95fbce in handle_internal_command tools/perf/perf.c:365:8
    MIPS#16 0x559cea95fbce in run_argv tools/perf/perf.c:409:2
    MIPS#17 0x559cea95fbce in main tools/perf/perf.c:539:3

  Uninitialized value was created by an allocation of 'bf' in the stack frame of function 'perf_event__synthesize_mmap_events'
    #0 0x559ceafc5f60 in perf_event__synthesize_mmap_events tools/perf/util/synthetic-events.c:445

SUMMARY: MemorySanitizer: use-of-uninitialized-value elfutils/libdwfl/frame_unwind.c:648:8 in handle_cfi
Signed-off-by: Ian Rogers <irogers@google.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: clang-built-linux@googlegroups.com
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sandeep Dasgupta <sdasgup@google.com>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lore.kernel.org/lkml/20201113182053.754625-1-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
pcercuei pushed a commit to OpenDingux/linux that referenced this issue Aug 23, 2021
When using kprobe on powerpc booke series processor, Oops happens
as show bellow:

/ # echo "p:myprobe do_nanosleep" > /sys/kernel/debug/tracing/kprobe_events
/ # echo 1 > /sys/kernel/debug/tracing/events/kprobes/myprobe/enable
/ # sleep 1
[   50.076730] Oops: Exception in kernel mode, sig: 5 [#1]
[   50.077017] BE PAGE_SIZE=4K SMP NR_CPUS=24 QEMU e500
[   50.077221] Modules linked in:
[   50.077462] CPU: 0 PID: 77 Comm: sleep Not tainted 5.14.0-rc4-00022-g251a1524293d MIPS#21
[   50.077887] NIP:  c0b9c4e0 LR: c00ebecc CTR: 00000000
[   50.078067] REGS: c3883de0 TRAP: 0700   Not tainted (5.14.0-rc4-00022-g251a1524293d)
[   50.078349] MSR:  00029000 <CE,EE,ME>  CR: 24000228  XER: 20000000
[   50.078675]
[   50.078675] GPR00: c00ebdf0 c3883e90 c313e300 c3883ea0 00000001 00000000 c3883ecc 00000001
[   50.078675] GPR08: c100598c c00ea250 00000004 00000000 24000222 102490c2 bff4180c 101e60d4
[   50.078675] GPR16: 00000000 102454ac 00000040 10240000 10241100 102410f 10240000 00500000
[   50.078675] GPR24: 00000002 00000000 c3883ea0 00000001 00000000 0000c350 3b9b8d50 00000000
[   50.080151] NIP [c0b9c4e0] do_nanosleep+0x0/0x190
[   50.080352] LR [c00ebecc] hrtimer_nanosleep+0x14c/0x1e0
[   50.080638] Call Trace:
[   50.080801] [c3883e90] [c00ebdf0] hrtimer_nanosleep+0x70/0x1e0 (unreliable)
[   50.081110] [c3883f00] [c00ec004] sys_nanosleep_time32+0xa4/0x110
[   50.081336] [c3883f40] [c001509c] ret_from_syscall+0x0/0x28
[   50.081541] --- interrupt: c00 at 0x100a4d08
[   50.081749] NIP:  100a4d08 LR: 101b5234 CTR: 00000003
[   50.081931] REGS: c3883f50 TRAP: 0c00   Not tainted (5.14.0-rc4-00022-g251a1524293d)
[   50.082183] MSR:  0002f902 <CE,EE,PR,FP,ME>  CR: 24000222  XER: 00000000
[   50.082457]
[   50.082457] GPR00: 000000a2 bf980040 1024b4d0 bf980084 bf980084 64000000 00555345 fefefeff
[   50.082457] GPR08: 7f7f7f7f 101e0000 00000069 00000003 28000422 102490c2 bff4180c 101e60d4
[   50.082457] GPR16: 00000000 102454ac 00000040 10240000 10241100 102410f 10240000 00500000
[   50.082457] GPR24: 00000002 bf9803f4 10240000 00000000 00000000 100039e0 00000000 102444e8
[   50.083789] NIP [100a4d08] 0x100a4d08
[   50.083917] LR [101b5234] 0x101b5234
[   50.084042] --- interrupt: c00
[   50.084238] Instruction dump:
[   50.084483] 4bfffc40 60000000 60000000 60000000 9421fff0 39400402 914200c0 38210010
[   50.084841] 4bfffc20 00000000 00000000 00000000 <7fe00008> 7c0802a6 7c892378 93c10048
[   50.085487] ---[ end trace f6fffe98e2fa8f3e ]---
[   50.085678]
Trace/breakpoint trap

There is no real mode for booke arch and the MMU translation is
always on. The corresponding MSR_IS/MSR_DS bit in booke is used
to switch the address space, but not for real mode judgment.

Fixes: 21f8b2f ("powerpc/kprobes: Ignore traps that happened in real mode")
Signed-off-by: Pu Lehui <pulehui@huawei.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210809023658.218915-1-pulehui@huawei.com
pcercuei pushed a commit to OpenDingux/linux that referenced this issue Oct 15, 2021
The id of slv_cnoc_mnoc_cfg node is mistakenly coded as id of
slv_blsp_1.  It causes the following warning on slv_blsp_1 node adding.
Correct the id of slv_cnoc_mnoc_cfg node.

[    1.948180] ------------[ cut here ]------------
[    1.954122] WARNING: CPU: 2 PID: 7 at drivers/interconnect/core.c:962 icc_node_add+0xe4/0xf8
[    1.958994] Modules linked in:
[    1.967399] CPU: 2 PID: 7 Comm: kworker/u16:0 Not tainted 5.14.0-rc6-next-20210818 MIPS#21
[    1.970275] Hardware name: Xiaomi Redmi Note 7 (DT)
[    1.978169] Workqueue: events_unbound deferred_probe_work_func
[    1.982945] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    1.988849] pc : icc_node_add+0xe4/0xf8
[    1.995699] lr : qnoc_probe+0x350/0x438
[    1.999519] sp : ffff80001008bb10
[    2.003337] x29: ffff80001008bb10 x28: 000000000000001a x27: ffffb83ddc61ee28
[    2.006818] x26: ffff2fe341d44080 x25: ffff2fe340f3aa80 x24: ffffb83ddc98f0e8
[    2.013938] x23: 0000000000000024 x22: ffff2fe3408b7400 x21: 0000000000000000
[    2.021054] x20: ffff2fe3408b7410 x19: ffff2fe341d44080 x18: 0000000000000010
[    2.028173] x17: ffff2fe3bdd0aac0 x16: 0000000000000281 x15: ffff2fe3400f5528
[    2.035290] x14: 000000000000013f x13: ffff2fe3400f5528 x12: 00000000ffffffea
[    2.042410] x11: ffffb83ddc9109d0 x10: ffffb83ddc8f8990 x9 : ffffb83ddc8f89e8
[    2.049527] x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000000001
[    2.056645] x5 : 0000000000057fa8 x4 : 0000000000000000 x3 : ffffb83ddc9903b0
[    2.063764] x2 : 1a1f6fde34d45500 x1 : ffff2fe340f3a880 x0 : ffff2fe340f3a880
[    2.070882] Call trace:
[    2.077989]  icc_node_add+0xe4/0xf8
[    2.080247]  qnoc_probe+0x350/0x438
[    2.083718]  platform_probe+0x68/0xd8
[    2.087191]  really_probe+0xb8/0x300
[    2.091011]  __driver_probe_device+0x78/0xe0
[    2.094659]  driver_probe_device+0x80/0x110
[    2.098911]  __device_attach_driver+0x90/0xe0
[    2.102818]  bus_for_each_drv+0x78/0xc8
[    2.107331]  __device_attach+0xf0/0x150
[    2.110977]  device_initial_probe+0x14/0x20
[    2.114796]  bus_probe_device+0x9c/0xa8
[    2.118963]  deferred_probe_work_func+0x88/0xc0
[    2.122784]  process_one_work+0x1a4/0x338
[    2.127296]  worker_thread+0x1f8/0x420
[    2.131464]  kthread+0x150/0x160
[    2.135107]  ret_from_fork+0x10/0x20
[    2.138495] ---[ end trace 5eea8768cb620e87 ]---

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Fixes: f80a1d4 ("interconnect: qcom: Add SDM660 interconnect provider driver")
Link: https://lore.kernel.org/r/20210823014003.31391-1-shawn.guo@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
pcercuei pushed a commit to OpenDingux/linux that referenced this issue Nov 29, 2023
commit 133466c ("net: stmmac: use per-queue 64 bit statistics
where necessary") caused one regression as found by Uwe, the backtrace
looks like:

	INFO: trying to register non-static key.
	The code is fine but needs lockdep annotation, or maybe
	you didn't initialize this object before use?
	turning off the locking correctness validator.
	CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.5.0-rc1-00449-g133466c3bbe1-dirty MIPS#21
	Hardware name: STM32 (Device Tree Support)
	 unwind_backtrace from show_stack+0x18/0x1c
	 show_stack from dump_stack_lvl+0x60/0x90
	 dump_stack_lvl from register_lock_class+0x98c/0x99c
	 register_lock_class from __lock_acquire+0x74/0x293c
	 __lock_acquire from lock_acquire+0x134/0x398
	 lock_acquire from stmmac_get_stats64+0x2ac/0x2fc
	 stmmac_get_stats64 from dev_get_stats+0x44/0x130
	 dev_get_stats from rtnl_fill_stats+0x38/0x120
	 rtnl_fill_stats from rtnl_fill_ifinfo+0x834/0x17f4
	 rtnl_fill_ifinfo from rtmsg_ifinfo_build_skb+0xc0/0x144
	 rtmsg_ifinfo_build_skb from rtmsg_ifinfo+0x50/0x88
	 rtmsg_ifinfo from __dev_notify_flags+0xc0/0xec
	 __dev_notify_flags from dev_change_flags+0x50/0x5c
	 dev_change_flags from ip_auto_config+0x2f4/0x1260
	 ip_auto_config from do_one_initcall+0x70/0x35c
	 do_one_initcall from kernel_init_freeable+0x2ac/0x308
	 kernel_init_freeable from kernel_init+0x1c/0x138
	 kernel_init from ret_from_fork+0x14/0x2c

The reason is the rxq|txq_stats structures are not what expected
because stmmac_open() -> __stmmac_open() the structure is overwritten
by "memcpy(&priv->dma_conf, dma_conf, sizeof(*dma_conf));"
This causes the well initialized syncp member of rxq|txq_stats is
overwritten unexpectedly as pointed out by Johannes and Uwe.

Fix this issue by moving rxq|txq_stats back to stmmac_extra_stats. For
SMP cache friendly, we also mark stmmac_txq_stats and stmmac_rxq_stats
as ____cacheline_aligned_in_smp.

Fixes: 133466c ("net: stmmac: use per-queue 64 bit statistics where necessary")
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Tested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230917165328.3403-1-jszhang@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants