Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4631640pxj; Tue, 25 May 2021 12:26:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz/pG1Et/YJX8KDuOqmfoRcDmO4ZKGc4S1Bjc/58wyxS3GUTuSmFlv/4pL3Tnpd7sod7cc5 X-Received: by 2002:a05:6402:2706:: with SMTP id y6mr5453864edd.355.1621970817564; Tue, 25 May 2021 12:26:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621970817; cv=none; d=google.com; s=arc-20160816; b=SMRF5e6tgyEMvqksXme3zXxYdGlpb56ys5MaNQ3FCv77otGit2JccZ6S6GmGkkAO8+ I9IOj0EbVoyTMy4FqbQkWsNFiYHY3szd8GRXF10NirSsiVrQew+37qZuQvu9Y53WvlY/ jXBM87VWiLhGRI/iYxHiAm66aPlWEHC/yAOxDNvvERccp75yUMx6MAijpcEl7yC8fOyx DkGZpUeIPsLz6WhPGBTlYA8OVKW/NfsY2bLapkH/8Vwc59EKRo4OPX7EzQPrDopoUZZy qIj0Q5g88uakMpuZvB3A6grQgUyS/nHwaMOPSBkFViIibXI/CHxdhbGpZuTuR9LiZBDA ZKnA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=ilqadP6miyG2ucaJRNhnH2nqbLOFKkZD7gQ8vrkxgcQ=; b=OaSGTP4cftzki+NQXpmOZbBeH6mG/aY8pew6DsEHbhUCRxcBTX2lbxaVYrb3uZeFQB s44y+kb0eOIPoBb4ap6ejpcn2yNflwDK2Y3wCx1/1rGjT+Q8TEGggHFuUspb3eL05zGp TYX+EaQwzvrKCuGm+nuggn8ktniPOpCmupm1busOXk2oiTqno1CLQaaWmDE08RliKWcf ZxzrntNxLxmMRHgwKkpVToDaUip5ypApKY5ILWug6Kl79a1X3JTaI5748c1dz9YGg8un EhDgidblzPq3hb2TamS95vDIzML9KltImvGikXv2D7QeNiD49zBGQsY4Hjb1LVn4ff7Q zb3g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=MZC9s1Pp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id kg7si14344882ejc.458.2021.05.25.12.26.34; Tue, 25 May 2021 12:26:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=MZC9s1Pp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232709AbhEYPBQ (ORCPT + 99 others); Tue, 25 May 2021 11:01:16 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:39910 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S231182AbhEYPBO (ORCPT ); Tue, 25 May 2021 11:01:14 -0400 Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 14PExFOU107432; Tue, 25 May 2021 10:59:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=ilqadP6miyG2ucaJRNhnH2nqbLOFKkZD7gQ8vrkxgcQ=; b=MZC9s1Pp4IsgjiDys5ewtgn+hG0oMLpezxWhIamRNIhIMiVzvLPCerGXbcbIcwu7qV2i wzkzHQms/4PfDtAtvwXxM/6Z8KRHYfDKv4NnUS/kSKD88RCDevsENj4TgPyfKWh/+2Cs I4Uok5RkqHlyAfeSu/Ekdl11VmycM6Q21ZvQ4g3t7plYAYkIOhlZQfNubgtaSS9VZmSb NaZhc4V3jv6z7wTfstC0b1HUMT58HzYUN880C9l2rfBUzDS9et68dbkupK2ty94EIweX WqC81V3Tb1nE5Veh8bSx/0gF6oOPYrETdDLOLNakBxuC00WbNqFS+ZDKXH+yPOmTxAEl Xw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com with ESMTP id 38s38r0nav-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 May 2021 10:59:42 -0400 Received: from m0098420.ppops.net (m0098420.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 14PExehG111005; Tue, 25 May 2021 10:59:40 -0400 Received: from ppma05wdc.us.ibm.com (1b.90.2fa9.ip4.static.sl-reverse.com [169.47.144.27]) by mx0b-001b2d01.pphosted.com with ESMTP id 38s38r0mxr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 May 2021 10:59:39 -0400 Received: from pps.filterd (ppma05wdc.us.ibm.com [127.0.0.1]) by ppma05wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 14PErumP024386; Tue, 25 May 2021 14:59:29 GMT Received: from b03cxnp08028.gho.boulder.ibm.com (b03cxnp08028.gho.boulder.ibm.com [9.17.130.20]) by ppma05wdc.us.ibm.com with ESMTP id 38s1ghh104-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 May 2021 14:59:28 +0000 Received: from b03ledav002.gho.boulder.ibm.com (b03ledav002.gho.boulder.ibm.com [9.17.130.233]) by b03cxnp08028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 14PExRhj31916494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 25 May 2021 14:59:27 GMT Received: from b03ledav002.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9012213604F; Tue, 25 May 2021 14:59:27 +0000 (GMT) Received: from b03ledav002.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6347A13605D; Tue, 25 May 2021 14:59:26 +0000 (GMT) Received: from cpe-172-100-179-72.stny.res.rr.com (unknown [9.85.177.219]) by b03ledav002.gho.boulder.ibm.com (Postfix) with ESMTP; Tue, 25 May 2021 14:59:26 +0000 (GMT) Subject: Re: [PATCH v4 2/2] s390/vfio-ap: control access to PQAP(AQIC) interception handler To: Jason Gunthorpe Cc: linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, borntraeger@de.ibm.com, cohuck@redhat.com, pasic@linux.vnet.ibm.com, jjherne@linux.ibm.com, alex.williamson@redhat.com, kwankhede@nvidia.com, frankja@linux.ibm.com, david@redhat.com, imbrenda@linux.ibm.com, hca@linux.ibm.com References: <20210521193648.940864-1-akrowiak@linux.ibm.com> <20210521193648.940864-3-akrowiak@linux.ibm.com> <20210523225746.GF1002214@nvidia.com> From: Tony Krowiak Message-ID: Date: Tue, 25 May 2021 10:59:25 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <20210523225746.GF1002214@nvidia.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: TaWADBqqPkb5YFjg1MtBJSc2-BGjm6FM X-Proofpoint-GUID: KRxNCKyuKPDOFaxatL_YT-HVr9VjXiTI X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-05-25_07:2021-05-25,2021-05-25 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 adultscore=0 clxscore=1015 priorityscore=1501 lowpriorityscore=0 impostorscore=0 spamscore=0 phishscore=0 malwarescore=0 mlxlogscore=999 suspectscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2105250090 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/23/21 6:57 PM, Jason Gunthorpe wrote: > On Fri, May 21, 2021 at 03:36:48PM -0400, Tony Krowiak wrote: >> +static struct kvm_s390_crypto_hook >> +*kvm_arch_crypto_find_hook(enum kvm_s390_crypto_hook_type type) >> +{ >> + struct kvm_s390_crypto_hook *crypto_hook; >> + >> + list_for_each_entry(crypto_hook, &crypto_hooks, node) { >> + if (crypto_hook->type == type) >> + return crypto_hook; >> + } >> + >> + return NULL; >> +} >> + >> +int kvm_arch_crypto_register_hook(struct kvm_s390_crypto_hook *hook) >> +{ >> + struct kvm_s390_crypto_hook *crypto_hook; >> + >> + mutex_lock(&crypto_hooks_lock); >> + crypto_hook = kvm_arch_crypto_find_hook(hook->type); >> + if (crypto_hook) { >> + if (crypto_hook->owner != hook->owner) >> + return -EACCES; >> + list_replace(&crypto_hook->node, &hook->node); > This is all dead code right? This is only called from a module init > function so it can't be called twice. That is true only if you are considering the current case. Is it guaranteed that only the vfio_ap module will call this function and is there a guarantee that it will always and only be called from the vfio_ap module init function? For example, suppose a hook is added to intercept the AP NQAP or DQAP instruction? We don't know how or when those handlers will be registered or unregistered. We don't even know if the handlers will be part of the vfio_ap module or not. > Just always fail if the hook is > already used and delete the owner stuff. I suppose that is reasonable and simpler. > > But this is alot of complicated and unused code to solve a lock > ordering problem.. If you have a better solution, I'm all ears. I've been down this road a couple of times now and solving lock ordering for multiple asynchronous processes is not trivial. This seems like a reasonable solution and provides for flexibility for including additional hooks to handle interception of other AP instructions. > > Jason