In article <20020310155508.A27243.fenrus.linux.kernelnewbies@amber> you 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. copy_to_user schedules >Then you say that 'grabbing spinlock is busy waiting > without scheduling'. AFAIK, spinlocks are disabled for UP. They only work for SMP. you can run SMP kernels on UP and in fact do that quite often... > 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. Now have 2 such bugs so 2 cpus are busy waiting.... what causes the process to schedule then ? or run the SMP kernel on a system with a broken bios where UP doesn't work ? -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
