Spinlocks are used to avoid the simultaneous execution of the critical section in the kernel. It makes more sense in SMP architecture, where the code can be executed simultaneously. However, in UP systems code will not be executed simultaneously. As the name suggests, the processor will be spinning continuosly on a spinlock. Once you are in the kernel and you are spinning, there is no way you would be rescheduled. Therefore it is not possible to preempt from the lock. If you are rescheduled then the whole purpose of spinlock is lost. You can use semaphores either. It is a bad programming practice to hold the lock and go to sleep. As it may be possible that the one who has to wake the previous guy would be waiting for the lock and thereby causing the deadlock. In the scenario of copy_to_user, if you hold the lock and go to sleep to get some pages in the memory. It may be possible that there is a large process in the memory who has taken up almost complete memory is also waiting on the same lock. As the pages are locked by this process they would not be swapped out and similarly the one who grabbed the lock would not be able to get his pages in the memory and hence cannot release the lock. Resultant is a deadlock. >Now have 2 such bugs so 2 cpus are busy waiting.... what >causes the process to schedule then ? That is ofcourse a deadlock where everyone is running in a tight loop on the processor. But remember once you go to sleep, the scheduler is ready to run. Also you have to be sure that if you have disabled the interrupts on the processor or not. If you are saying copy_to_user will cause a deadlock, then I 'll say it will not. Check the code again for it. I hope it made sense. thanks, Sumit ----- Original Message ----- From: arjan@fenrus.demon.nl Date: Monday, March 11, 2002 3:03 am Subject: Re: Q: deadlock > 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/ > >
begin:vcard n:Agarwal;Sumit fn:Sumit Agarwal tel;cell:+919845205210 tel;fax:+91-80-5732696 tel;home:+919845205210 tel;work:+91-805732296 / 93 extn. 5243 url:www.wipro.com org:Wipro Technologies;SIDC, Embedded and Internet Division adr:;;Wipro Technologies, Chamundi Complex, No.26, Hosur Main Road, Bommanahalli;Bangalore;Karnataka;560068;INDIA version:2.1 email;internet:sumit.agarwal@wipro.com title:Senior Software Engineer end:vcard
**************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ********************************************************************
