On 04.03.2011 11:47, Kurt Van Dijck wrote: > Oliver, > > while sitting on the train back home, and looking in your isotp code, > I suspected a possible race condition between waiting for the socket > to become tx.state == ISOTP_IDLE and actually tx.state = ISOTP_SENDING. > I think I solved this by using a semaphore. > The patch is not tested, and may be incomplete. I just send it already > so people can start thinking about the problem.
Thanks. I tried to apply and compile your idea. Removing the entire wait_queue stuff and fixing some minor things (ret/err variables), the waiting for the transmission completion in isotp_release() turned out to be somehow tricky ... Then i asked myself what the problem of using the existing waitqueues would be - as you remarked?!? I found this on the web: --- http://www.linuxgrill.com/anonymous/fire/netfilter/kernel-hacking-HOWTO-5.html Wait Queues <include/linux/wait.h> <SLEEPS> A wait queue is not really a form of locking, but it's used to guarantee that if you are checking for a condition, and going to sleep if it's not true, that there is no gap between the check and the sleeping. You declared one wait_queue_head_t, and then processes which want to wait for that condition declare a wait_queue_t referring to themselves, and place that in the queue. --- Looks perfectly for my needs - and is widely used, even in networking code ... Regards, Oliver _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
