[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] Re: Should shadow_lock be spin_lock_recursive?

I think there's another bug somewhere that's provoking this.
There may be a flaw in my argument, below, but I currently think this
argument is correct:

Consider the call tree:

free_dom_mem() is trying to get rid of all shadow references to page X,
so that it can relinguish page X back to the free list.
*Note that free_dom_mem() has done a get_page() on X, so X's refcount
must be >= 1...

free_dom_mem() calls shadow_sync_and_drop_references(X),
which calls shadow_remove_all_access(X),
which calls remove_all_access_in_page(random shadow page, X),
which (when it finds references to X) calls put_page(X).

However, those calls to put_page(X) should never result in calls
to free_domheap_pages(), as X's refcount should always be >= 1
because of the get_page performed in free_dom_mem().

So that tells me the refcount on X was already broken before we got


-----Original Message-----
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Xiaofeng Ling
Sent: Thursday, May 12, 2005 2:57 AM
To: Sharma, Arun
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Re: Should shadow_lock be spin_lock_recursive?

This dead lock happened on VNIF code when enabled shadow mode.
The shadow_lock path is so complex and maybe using recurisve lock
is the easiest way to avoid dead lock currently before clearing
the path or splitting the lock .

Arun Sharma wrote:
> During our testing, we found this code path where xen attempts to grab 
> the shadow_lock, while holding it - leading to a deadlock.
>  >> free_dom_mem->
>  >> shadow_sync_and_drop_references->
>  >> shadow_lock -> ..................... first lock
>  >> shadow_remove_all_access->
>  >> remove_all_access_in_page->
>  >> put_page->
>  >> free_domheap_pages->
>  >> shadow_drop_references->
>  >> shadow_lock -> ..................... second lock
> Questions:
> - should shadow lock be recursive?
> - is shadow lock too coarse grained? It seems to have led to a lot of 
> code refactoring (__foo without lock and foo with lock). But there may 
> be more such instances we haven't found yet.
>     -Arun

Xen-devel mailing list

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.