[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH]: Fix deadlock in mm_pin
On 20/11/08 10:31, "Chris Lalancette" <clalance@xxxxxxxxxx> wrote: > it applies to the 2.6.18 tree as well; the deadlock scenario is below. > > "After running an arbitrary workload involving network traffic for some time > (1-2 days), a xen guest running the 2.6.9-67 x86_64 xenU kernel locks up with > both vcpu's spinning at 100%. > > The problem is due to a race between the scheduler and network interrupts. On > one vcpu, the scheduler takes the runqueue spinlock of the other vcpu to > schedule a process, and attempts to lock mm_unpinned_lock. On the other vcpu, > another process is holding mm_unpinned_lock (because it is starting or > exiting), and is interrupted by a network interrupt. The network interrupt > handler attempts to wake up the same process that the first vcpu is trying to > schedule, and will try to get the runqueue spinlock that the first vcpu is > already holding." I don't believe that mm_unpinned_lock can ever be taken while a runqueue lock is already held in 2.6.18. If you can provide a call chain then I'll consider the patch -- but I think you'd still be screwed by the mm->page_table_lock (also acquired in mm_pin() code, also not IRQ safe, but less easy for you to go convert all the users of that lock). You might have some backporting from 2.6.18 to do... -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |