Emard wrote: > Johannes Stezenbach wrote: > > I think that spin_lock_irq() is "stronger" than spin_lock_bh(). > > On SMP the critical region will be protected by the spin lock, > > on UP you can't get interrupted when irqs are disabled. But > > it is of course more efficient to not to lock irqs when not > > necessary, that's the whole point of using tasklets.
Ack. We should not even think about these optimizations before the driver is stable. Using stronger locks does not hurt. > It is stronger, but from some people machine lockup > reports (machine hosed, ICMP PING still working) I think that this > lock happens during execution of hardware irq, and it's (sometimes) > released before finish of tasklet execution (after the hardware > irq has finished), while it should be actually keep locked after > the hardware irq, during the tasklet running and then released. Locks should never be held longer than necessary. Taking a lock in the interrupt handler and releasing it in the tasklet might lead to deadlocks. If you take a lock in the interrupt handler you have to release in in the interrupt handler. If you take a lock in the tasklet you have to release it in the tasklet. spin_lock_irq() / spin_unlock_irq(): Routines called from HW interrupts should never use spin_lock_irq() / spin_unlock_irq() because spin_unlock_irq() enables interrupts. Obviously this is not correct if (and only if) spin_lock_irq() was called with interrupts disabled. In this case spin_lock_irqsave() / spin_unlock_irqrestore() should be used which will restore interrupts to the previous state. (I have not seen any issues related to this in the driver.) > So we can replace them in dvb_demux.c with spin_lock_bh() and test > it a bit if it still works after the change :-)? If you are using spin_lock_bh(), interrupt handlers cannot access the protected data anymore, i.e. you must not call these routines from an interrupt handler. Oliver -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
