On Fri, Sep 23, 2005 at 06:05:37AM +0200, Oliver Neukum wrote: > Am Freitag, 23. September 2005 00:49 schrieb David Kubicek: > > Ok, so what does that mean for me now? Should I change those to normal > > spin_locks too? Locks I used are not there "by design" it's just the way > > a similar piece of some other driver used them -- I needed to use locks, > > but wasn't sure about how it's done in kernel programming, so I studied > > other kernel code, how to use different types of locks. In the patch is > > the result of my findings. I do not insist on them if they are combined > > in a wrong manner. All locks in the patch are for simple internal data > > structures, it should be very easy to use correct ones. > > It is OK now. I'll send the patch onwards. > > A driver using spin_lock_irq() in a tasklet is buggy. You can always use > irqsave. It will just be slower. But in a tasklet or interrupt handler > spin_lock() will do. Basically these locks differ in whether they shut down > irq processing on the local CPU. In interrupt it is down and must not be > reenabled. Therefore spin_lock_irq() is deadly.
I see, thanks for your constructive comments. I'll have a detailed look at these kernel programming basics, in case I'd have to hack my way through again some day. ;) Can you tell me in which kernel version will the patch appear? Regards, -- David Kubíèek System Specialist gedas ÈR s.r.o. Mladá Boleslav, Husova 217 Phone: (420) 326 329 359 Mobile: (420) 724 073 280 Email: [EMAIL PROTECTED] Web: http://www.awk.cz ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
