On Fri, Oct 31, 2008 at 10:07:58AM -0700, Lovich, Vitali (vlovich@qualcomm.com) wrote:

quoted

quoted

Also, you've got a potential threading issue - you're not protecting
the frame index behind the spinlock.

You are right, I think I will spin-lock outside the do_while loop.

Can't do that I think - dev_queue_xmit sleeps AFAIK and you can't hold a spinlock when you sleep.

It does not and can be called from interrupt context, but interrupts
have to be turned on, since BH will be reenabled there.

Can you explain why you need a spinlock though?  I think you're trying to make it thread-safe if multiple threads make calls to send, correct?  In this case, just change it to a semaphore, and protect the entire send call (well - at least in a safe enough way to make sure you're properly unlocking upon exit).  Also, a better question is - is there any particular reason we need to support multiple threads calling send?  Just stipulate that the behaviour is undefined when there are calls to send from different threads.

If there will be no synchronization you should very carefully call
udnerlying functions not to race against each other. For example
device queue should be locked.

-- 
	Evgeniy Polyakov