From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [PATCH] xen: resume console a bit later Date: Thu, 3 Jul 2014 11:12:33 +0100 Message-ID: <53B52C91.3050204@citrix.com> References: <1404318919-28626-1-git-send-email-david.vrabel@citrix.com> <53B43A27.3070007@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1X2e0N-0001Br-Se for xen-devel@lists.xenproject.org; Thu, 03 Jul 2014 10:12:39 +0000 In-Reply-To: <53B43A27.3070007@oracle.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Boris Ostrovsky Cc: xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org On 02/07/14 17:58, Boris Ostrovsky wrote: > On 07/02/2014 12:35 PM, David Vrabel wrote: >> Calling xen_console_resume() in xen_suspend() causes a (harmless) >> warning because it calls a function that might sleep. It occurs to me that this warning isn't harmless. Whilst the device power management will ensure no driver is playing with irqs, a userspace process might be using the evtchn device. I've updated the commit message to: xen/manage: fix potential deadlock when resuming the console Calling xen_console_resume() in xen_suspend() causes a warning because it locks irq_mapping_update_lock (a mutex) and this may sleep. If a userspace process is using the evtchn device then this mutex may be locked at the point of the stop_machine() call and xen_console_resume() would then deadlock. Resuming the console after stop_machine() returns avoids this deadlock. And tagged for stable and applied to stable/for-linus-3.6 David