At 03:28 PM 5/28/2004, Eugene LiS User wrote:
Dave Grothe <[EMAIL PROTECTED]> wrote:
>At 02:40 PM 5/28/2004, Eugene LiS User wrote:
>
>>Is it OK to call lis_safe_putmsg() from interrupt context?
>
>No.
The put() is directly mapped to lis_safe_putmsg().
I was under impression that it is OK to call put()
from interrupt context.
Why not?
It is extremely bad practice and results in extending interrupt processing by performing protocol related functions that should be deferred to background. Use putq() at interrupt level and have the service routine process the message.
If the STREAMS executive is to provide protection from re-entry of put/srv procedures then it would have to surround each putnext() call with spinlock_irqsave() calls in order to protect against this case. This makes matters even worse, locking out interrupts while STREAMS service procedures and put procedures execute performing tasks totally unrelated to interrupt handling, or shared variables therewith.
In Linux your put/srv routines become further restricted as to the kernel calls that they can make if they are entered while holding a spin lock. That is why LiS now uses a semaphore for this exclusion rather than a spin lock.
An operating system such as Solaris which runs interrupts as threads, on their own stacks, can use adaptive mutexes for this exclusion because interrupt routines actually can sleep in Solaris. It is essentially the ability to use a semaphore at interrupt time!
Linux does not do this, so if you call putnext() from interrupt level you will be asking for a deadly embrace hang if the interrupted thread happens to be holding the semaphore associated with the queue, i.e., executing in the put/srv routine.
In the latest LiS Alphas there is a qlock option for drivers. If you set this option to 0, meaning no locking, then you can call putnext() from interrupt level without fear of deadlock, but still with the "bad practice" caveats stated above. Also, your driver put/srv routines can be entered simultaneously from multiple CPUs and you have to sort that out inside your driver. If you want to see an example of a driver that handles that nicely, look at Brian's inet.c driver and observe the locking mechanism that he uses. Just find the "put" procedure and start tracing down the code from there.
-- Dave
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.691 / Virus Database: 452 - Release Date: 5/26/2004
