I'm writing some code for the Linux kernel and I noticed the interrupts are disabled when I need them to be enabled so that a process can handle a signal. It would be fantastic if I could just obtain a list of all the locks currently being hold in the system, as my suspicion is that a lock somewhere has disabled interruptions... This is, assuming that it was a lock that disabled the interruptions. If not, it would also be nice to know how did so (or where). Does the Linux kernel keep any record of this?
-
Can you please be more specific about Signals and Interrupts! Do you want to enable Signals or Interrupts? – Gaurav Pathak Feb 19 '20 at 10:08
-
I need to enable interrupts so that the process can handle the signal that has been sent. Or at least, as I don't want to enable interruptions without knowing why were they disabled on the first place, discover who disabled them. – Carlos Bilbao Feb 19 '20 at 10:17
-
Where is your code located in kernel, is it iptables-hook or something else? Are you trying to send or receive a signal? Please add details. Btw, if interrupts are disabled - there are good reasons for this. It is a regular Linux kernel procedure. All you have to do is decide whether you will work in the interrupt context or not. – z0lupka Feb 19 '20 at 12:28
1 Answers
Yes, the kernel definitely has the ability to keep track of currently held locks, but that's costly and only done for debugging purposes. You should configure and compile your kernel with debugging enabled (specifically CONFIG_LOCKDEP
, which also depends on other config options).
Once that is done, in struct task_struct
there are various fields such as lockdep_depth
(number of currently held locks) and held_locks
(array of struct held_lock
representing currently held locks) that could be useful for you. You could check those fields for the current
task when your module is running to find out what is going on.
Take a look at the two private functions lockdep_print_held_locks()
and print_lock()
from kernel/locking/lockdep.c
to see how to extract useful information from those struct held_lock
. You could also use the kgdb kernel debugger in order to look specifically at what is happening when your kernel code runs.

- 63,369
- 21
- 118
- 128