I've always assumed that interrupt handlers were absoluteley there to do the minimum work and get out as soon as possible. A question came to me today that challenged that view. The question was "Can I mutex_enter the pidlock while in an interrupt context?"
My instant reaction was no way, you should never block in an interrupt context. However it seems I was wrong. Take a look at fas_intr()
. You can see virtually the first thing it does is grab a mutex. This got me thinking.
There is a fundemental difference between grabbing a lock in an interrupt handler that is private to that code and using a lock which is in general use throughout the kernel. Take this example. Something is holding the pidlock. But for whatever reason (it's timeslice has run out) it has be scheduled off CPU. So we have our foo card installed in our Solaris machine and an interrupt comes in for it. foointr() has been written to grab the mutex for the pidlock to make sure it has a stable view of the process table. So it tries to grab the pidlock and it has to block till the owner frees it. Could be ages, and the interupt wouldn't be serviced in a timely manner.
I'd like to say I dredged through the code and found all this out by reading the code, but infact I just read the manual page
This says that you can acquire a mutex, kernel or high level interupt context. However there is a restriction that the mutex must have been initialised as type DRIVER_MUTEX, and have the ddi_iblock_cookie (returned from ddi_get_iblock_cookie(9f)
) as the arg to mutex_init(9f)
So there you have it. you can use a mutex in a high level interupt handler, just not ones like pidlock
Technorati Tag: OpenSolaris
Technorati Tag: Solaris