On Sun, 10 Mar 2002, Etay Meiri wrote: > On Sun, Mar 10, 2002 at 11:12:15AM +0000, arjan@fenrus.demon.nl wrote: > > In article <63342002301010163277@antisocial.com> you wrote: > > > > > > Why can the kernel deadlock when calling e.g copy_to_user while holding a > > > spinlock? > > > I understand that the function can block, but not that it could result in a > > > deadlock. > > > > you hold the spinlock and schedule. another process > > gets scheduled and wants to grab the exact same spinlock..... > > grabbing spinlock is busy waiting without scheduling so the > > original process never ever gets a chance to release the lock.... lock > > doesn't get released -> you busy wait forever > > -- > > You have a conflict there. First you say that the first process schedules > _because_ of the spinlock. No - he said it schedules while holding a spinlock. Doing that is always a mistake AIUI, because it leads to this situation. > Then you say that 'grabbing spinlock is busy waiting > without scheduling'. AFAIK, spinlocks are disabled for UP. They only work for SMP. > The idea is that while one process busy waits on the spinlock on one processor, > the other process on the other processor (the one actually holding the spinlock) > can do whatever it needs to do and than release the spinlock. Than the first process > is released and can aquire the lock. Still a problem on CPU-local spinlocks. BTW, spinlocks ARE enabled on UP if you use the preempt patch... Hence the rule "NEVER schedule holding a lock", I think. Otherwise, something might block waiting for that lock - which will never be released, since you never get scheduled again... BANG. James. -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
