From mboxrd@z Thu Jan 1 00:00:00 1970 From: Xiaofeng Ling Subject: Re: Should shadow_lock be spin_lock_recursive? Date: Thu, 12 May 2005 09:57:24 +0800 Message-ID: <4282B804.5010403@intel.com> References: <4282441E.6080900@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4282441E.6080900@intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Arun Sharma Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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