kernel panic: Lock ADDR tried to spin when it shouldn't

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit: bf9a9ba0d6af Add panic_hwtf() for kernel faults
git tree: https://github.com/akaros/akaros.git/master
console output: https://syzkaller.appspot.com/x/log.txt?x=125bd178400000
kernel config: https://syzkaller.appspot.com/x/.config?x=efef8cf2939304d3
dashboard link: https://syzkaller.appspot.com/bug?extid=5898ae24d13a22ae7713
compiler:

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+5898ae...@syzkaller.appspotmail.com

kernel panic at kern/src/atomic.c:66, from core 2: Lock 0xffffffffc8665240
tried to spin when it shouldn't
Stack Backtrace on Core 2:
#01 [<0xffffffffc200a3e7>] in backtrace at src/kdebug.c:219
#02 [<0xffffffffc2009bb2>] in _panic at src/init.c:273
#03 [<0xffffffffc2003952>] in spin_lock at src/atomic.c:66
#04 [<0xffffffffc2031845>] in newchan at src/ns/chan.c:179
#05 [<0xffffffffc2036e42>] in devclone at src/ns/dev.c:189
#06 [<0xffffffffc2037334>] in devwalk at src/ns/dev.c:228
#07 [<0xffffffffc2016654>] in ipwalk at src/net/devip.c:419
#08 [<0xffffffffc2032efd>] in walk at src/ns/chan.c:809
#09 [<0xffffffffc2033609>] in __namec_from at src/ns/chan.c:1131
#10 [<0xffffffffc20341ef>] in namec at src/ns/chan.c:1509
#11 [<0xffffffffc20416d6>] in sysopenat at src/ns/sysfile.c:590
#12 [<0xffffffffc205881f>] in sys_openat at src/syscall.c:1805
#13 [<0xffffffffc20593c9>] in syscall at src/syscall.c:2528
#14 [<0xffffffffc2059584>] in run_local_syscall at src/syscall.c:2563
#15 [<0xffffffffc2059ab9>] in prep_syscalls at src/syscall.c:2583
#16 [<0xffffffffc20ab29a>] in sysenter_callwrapper at arch/x86/trap.c:851


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.

[Barret Rhoden]

On 2018-07-18 at 11:00 syzbot

Notes to whoever debugs this one: (future barret)

From the details of the log, it looks like the chan lock *thinks* its
an IRQ-OK lock (meaning callable from IRQ ctx), which it isn't. From
the BT, you can see it's called with IRQs enabled (and the log confirms
that).

Not sure why it thought that it was IRQ-OK. From looking at the code,
it shouldn't be. (actually the lock isn't initialized, but zero-init
== IRQ-not-ok). My guess is memory corruption accidentally sets the
bool.

Also note that all panics of this sort will have the same syzbot Title,
so you have to check the log and backtrace.

Barret

[Dmitry Vyukov]

Yes, unfortunately silent memory corruptions are possible. For Linux
we run with all possible debug configs, and most notably KASAN, which
catches most of corruptions promptly. This _mostly_ alleviates the
problem. Without KASAN, unfortunately, lots of memory corruptions can
manifest in random ways.

Unless we suddenly get a reproducer, the course of action can be as
follows. If we fix some other memory corruption and we see that this
bug stopped happening, we can tentatively close this as invalid of
dup. Then if it's in fact resolved, we are done. Otherwise syzbot we
reopen it later, but we already know that it's not the memory
corruption that we fixed.

[syzbot]

Auto-closing this bug as obsolete.
Crashes did not happen for a while, no reproducer and no activity.