From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Hildenbrand Subject: Re: [s390] possible deadlock in handle_sigp? Date: Thu, 15 Sep 2016 21:21:42 +0200 Message-ID: <20160915212142.5fd5048e@thinkpad-w530> References: <33773797-04ec-413f-7ba2-4bb7a4350a44@de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Paolo Bonzini , KVM list , Cornelia Huck , qemu-devel To: Christian Borntraeger Return-path: Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:45762 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753899AbcIOTVv (ORCPT ); Thu, 15 Sep 2016 15:21:51 -0400 Received: from pps.filterd (m0098413.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u8FJIHPR087379 for ; Thu, 15 Sep 2016 15:21:50 -0400 Received: from e06smtp12.uk.ibm.com (e06smtp12.uk.ibm.com [195.75.94.108]) by mx0b-001b2d01.pphosted.com with ESMTP id 25fr7c5wau-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 15 Sep 2016 15:21:50 -0400 Received: from localhost by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 15 Sep 2016 20:21:48 +0100 Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id 1C7802190046 for ; Thu, 15 Sep 2016 20:21:07 +0100 (BST) Received: from d06av06.portsmouth.uk.ibm.com (d06av06.portsmouth.uk.ibm.com [9.149.37.217]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u8FJLkEZ12648896 for ; Thu, 15 Sep 2016 19:21:46 GMT Received: from d06av06.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av06.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u8FJLjVu010100 for ; Thu, 15 Sep 2016 15:21:45 -0400 In-Reply-To: <33773797-04ec-413f-7ba2-4bb7a4350a44@de.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: > On 09/12/2016 08:03 PM, Paolo Bonzini wrote: > > > > > > On 12/09/2016 19:37, Christian Borntraeger wrote: > >> On 09/12/2016 06:44 PM, Paolo Bonzini wrote: > >>> I think that two CPUs doing reciprocal SIGPs could in principle end up > >>> waiting on each other to complete their run_on_cpu. If the SIGP has to > >>> be synchronous the fix is not trivial (you'd have to put the CPU in a > >>> state similar to cpu->halted = 1), otherwise it's enough to replace > >>> run_on_cpu with async_run_on_cpu. > >> > >> IIRC the sigps are supossed to be serialized by the big QEMU lock. WIll > >> have a look. > > > > Yes, but run_on_cpu drops it when it waits on the qemu_work_cond > > condition variable. (Related: I stumbled upon it because I wanted to > > remove the BQL from run_on_cpu work items). > > Yes, seems you are right. If both CPUs have just exited from KVM doing a > crossover sigp, they will do the arch_exit handling before the run_on_cpu > stuff which might result in this hang. (luckily it seems quite unlikely > but still we need to fix it). > We cannot simply use async as the callbacks also provide the condition > code for the initiater, so this requires some rework. > > Smells like having to provide a lock per CPU. Trylock that lock, if that's not possible, cc=busy. SIGP SET ARCHITECTURE has to lock all CPUs. That was the initital design, until I realized that this was all protected by the BQL. David