-
-
Notifications
You must be signed in to change notification settings - Fork 44
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
syzkaller: possible deadlock in sk_clone_lock
#447
Comments
[...]
The issue does not look like mptcp related (or memory corruption happens before the reported splat) because the above quoted stacktrace looks buggy: release_sock() disables local BH processing, the rcu_read_lock_bh()/rcu_read_unlock_bh() pair in __dev_queue_xmit() should not lead to irq processing, but indeed __do_softirq() is invoked. it looks like current->preempt_count is corrupted in between such calls?!? I think the lock debug options enabled in the current build should trigger if we have a pair of locking primitives mismatched ?!? All in all it looks confusing, and IIRC this is the 2nd stack trace we see in recent time that could be possibly a side effect of some random memory corruption. Perhaps it would be worthy increase the number of runners/configs with kasan enabled (and ev decreasing the number of config without such option, as needed)?!? Have you observed similar splats without any mptcp reference? |
I'm updating all my instances with KASAN. Any other "Memory Debugging" options you think may help ? I do wonder if the fail-injections could play a role here ? |
And no - I don't see other similar splats. |
@cpaasch: unless you observed more instances of this one I suggest to close it |
Yes! Hasn't happened since > a month. |
syzkaller-ID: 664c5311cf44e3aa732eaa6b2e79eb4a8961ec08
HEAD: 7a5720a
Trace:
Kconfig:
Kconfig_k5_lockdep.txt
No reproducer yet.
The text was updated successfully, but these errors were encountered: