linux-mips
[Top] [All Lists]

SMP spinlocks forever while doing a put_user

To: linux-mips@linux-mips.org
Subject: SMP spinlocks forever while doing a put_user
From: Joshua Wise <mips@joshuawise.com>
Date: Wed, 10 Aug 2005 15:36:43 -0400
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org
User-agent: KMail/1.8.1
So I've been doing some research into SMP on MIPS as I mentioned a while back, 
and as I think I mentioned, I've run into issues with put_user, well, not 
putting. In particular, I found that it was engaging in the classic SMP 
pastime of sitting in a spinlock forever, doing nothing.

My current configuration is one emulated 5kc with 64mb of emulated RAM. After 
adding some preliminary support to GXemul so that it can act as a GDB server, 
I managed to dig up the following backtrace before my crummy GDB server 
implementation blew up:

(gdb) bt
#0  0xffffffff8027f4b8 in _spin_lock (lock=0x3af0) at spinlock.h:60
#1  0xffffffff80194bac in handle_mm_fault (mm=0x3a80, vma=0x310948, 
address=64321698660352, write_access=0) at mm/memory.c:2029
Cannot access memory at address 0x81b758
(gdb)

In particular, line 2029 is the spinlock within the following snippet of code:
        /*
         * We need the page table lock to synchronize with kswapd
         * and the SMP-safe atomic PTE updates.
         */
        pgd = pgd_offset(mm, address);
        spin_lock(&mm->page_table_lock);

I'm not sure where this is being held that I'm not seeing it. I guess I should 
probably enable spinlock debugging, although I've tried that once in the past 
and gotten a total of zero spinlock-debug related messages. I'll give it 
another shot, in case I selected the wrong option or some such.

Does anyone have any insight as to what's going on here?

Thanks in advance,
joshua

<Prev in Thread] Current Thread [Next in Thread>