-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
[FEATURE] mechanism to ensure the consistent locking order #15446
Comments
glancing at the code, it requires you to actually make a deadlock happen, and then somehow trigger an assertion failure. reproducing a deadlock is not always easy. what i want to see is something more aggressive. |
Yes, the code assume that the deadlock will trigger panic finally. but it's easy to expose a nsh command to trigger the check periodly.
in a complex system, it's hard to know which mutexs and threads participant the deadlock chain, this tool help people identify the problem mutex and thread after the deadlock happen.
this feature requires to record the locking order. |
yes. |
Is your feature request related to a problem? Please describe.
it would be nice to have some debug feature which can detect issues like #15314
Describe the solution you'd like
precedents:
https://man.freebsd.org/cgi/man.cgi?witness(4)
https://docs.kernel.org/locking/lockdep-design.html
Describe alternatives you've considered
although adhoc local assertions like yamt@ac3dda4
can work, it would be nicer to have a generic mechanism in the upstream.
Verification
The text was updated successfully, but these errors were encountered: