Received: by 10.213.65.68 with SMTP id h4csp1379365imn; Mon, 26 Mar 2018 06:30:35 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+KK7ln2umR2Fkvy5lBOlMyaSDSQEUJ+/vcX6BKQR0vbo9rFUDypTPPewYNSxeBKqUeXhQv X-Received: by 10.98.157.157 with SMTP id a29mr6202939pfk.39.1522071035438; Mon, 26 Mar 2018 06:30:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522071035; cv=none; d=google.com; s=arc-20160816; b=mFUnUyGYz6fiHqHn/9Z89OMdBTIS9+j8BAJf0g9mpH4jGgg2xRKAdI103on+AUo2AI MDKLlW5SgDwapD5kJp1bkyshvTvlN0dfxh+XVDf38aiAIb298Zr9VUUaN3/wuSL3dKbf gdsMbCbzabkQYt8XeOyEO1uxy3i+0ATmHpDxaZxxf+1v8Ke5+plL1SRQiyxMdlUP78uX oORIH3vW5SWi3qGlaEd1hZhODFpZoBOzfLx5O8qXQmfbyQHi/qJF3OeWhgW2QsVTHQiX 8rypEQDw1A2fyejWbzZMT2ma3dzrHPW4qul/nWm+GspLnbaKBkhzkp069QxxIMpoQE8+ OymQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:arc-authentication-results; bh=dcOBGr5GJWDqdDCJ1ROVNhnyHV3e1XVYQEih7/W6GzI=; b=bH0d76dKQfm0GcP1RPRH/9mQi4XQ1D/Dp6dmnQRTTlB9UAFhWk39HtpnmK0yvTJgKZ BF/mZeQeYR8y8XLfFK4suooHFDXTS0+YAYVOuYvTXGe85l1T8mgq+TR3NRM451N6bLdu OYbQFpYgvx8VgEBg3E59TcScWtcsJwBv+6pWsFqog7acNDRvZacpx6mNzoKGY5+Q6FxV WgMq1eCSkXAg/005GzectCTZDfLYnchDjdpz1/bNpMbLkE/niy5qp4amUrz28a9KSi75 MoWasj1WaeRPF+QduOvKc+lI5pEYrG0LVV3EJ3h4WJbflyjh8yXCShaS2sSyZi8OXkIU 4tDQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a35-v6si2894216pli.391.2018.03.26.06.30.05; Mon, 26 Mar 2018 06:30:35 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752046AbeCZN2v (ORCPT + 99 others); Mon, 26 Mar 2018 09:28:51 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:38002 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751981AbeCZN2u (ORCPT ); Mon, 26 Mar 2018 09:28:50 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AB23B406E8A4; Mon, 26 Mar 2018 13:28:49 +0000 (UTC) Received: from gondolin (dhcp-192-222.str.redhat.com [10.33.192.222]) by smtp.corp.redhat.com (Postfix) with ESMTP id 925692026609; Mon, 26 Mar 2018 13:28:48 +0000 (UTC) Date: Mon, 26 Mar 2018 15:28:46 +0200 From: Cornelia Huck To: Dong Jia Shi Cc: linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, kvm@vger.kernel.org, borntraeger@de.ibm.com, pasic@linux.vnet.ibm.com, pmorel@linux.vnet.ibm.com Subject: Re: [PATCH 2/4] vfio: ccw: refactor and improve pfn_array_alloc_pin() Message-ID: <20180326152846.2ef1ae07.cohuck@redhat.com> In-Reply-To: <20180321020822.86255-3-bjsdjshi@linux.vnet.ibm.com> References: <20180321020822.86255-1-bjsdjshi@linux.vnet.ibm.com> <20180321020822.86255-3-bjsdjshi@linux.vnet.ibm.com> Organization: Red Hat GmbH MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Mon, 26 Mar 2018 13:28:49 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Mon, 26 Mar 2018 13:28:49 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'cohuck@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 21 Mar 2018 03:08:20 +0100 Dong Jia Shi wrote: > This refactors pfn_array_alloc_pin() and also improves it by adding > defensive code in error handling so that calling pfn_array_unpin_free() > after error return won't lead to problem. This mains does: > 1. Merge pfn_array_pin() into pfn_array_alloc_pin(), since there is no > other user of pfn_array_pin(). As a result, also remove kernel-doc > for pfn_array_pin() and add kernel-doc for pfn_array_alloc_pin(). > 2. For a vfio_pin_pages() failure, set pa->pa_nr to zero to indicate > zero pages were pinned. > 3. Set pa->pa_iova_pfn to NULL right after it was freed. > > Signed-off-by: Dong Jia Shi > --- > drivers/s390/cio/vfio_ccw_cp.c | 84 ++++++++++++++++++------------------------ > 1 file changed, 36 insertions(+), 48 deletions(-) > > diff --git a/drivers/s390/cio/vfio_ccw_cp.c b/drivers/s390/cio/vfio_ccw_cp.c > index 2be114db02f9..3abc9770910a 100644 > --- a/drivers/s390/cio/vfio_ccw_cp.c > +++ b/drivers/s390/cio/vfio_ccw_cp.c > @@ -46,65 +46,32 @@ struct ccwchain { > }; > > /* > - * pfn_array_pin() - pin user pages in memory > + * pfn_array_alloc_pin() - alloc memory for PFNs, then pin user pages in memory > * @pa: pfn_array on which to perform the operation > * @mdev: the mediated device to perform pin/unpin operations > + * @iova: target guest physical address > + * @len: number of bytes that should be pinned from @iova > * > - * Attempt to pin user pages in memory. > + * Attempt to allocate memory for PFNs, and pin user pages in memory. > * > * Usage of pfn_array: > - * @pa->pa_iova starting guest physical I/O address. Assigned by caller. > + * @pa->pa_iova starting guest physical I/O address. Assigned by callee. > * @pa->pa_iova_pfn array that stores PFNs of the pages need to pin. Allocated > - * by caller. > + * by callee. > * @pa->pa_pfn array that receives PFNs of the pages pinned. Allocated by > - * caller. > - * @pa->pa_nr number of pages from @pa->pa_iova to pin. Assigned by > - * caller. > - * number of pages pinned. Assigned by callee. > + * callee. > + * @pa->pa_nr initiated as 0 by caller. s/initiated/initialized/ but see below > + * number of pages pinned from @pa->pa_iova. Assigned by callee. So, basically everything is filled by pfn_array_alloc_pin()? Should we expect a clean struct pfn_array handed in by the caller, then (not just pa_nr == 0)? Would it make sense to describe the contents of the struct pfn_array fields at the struct's definition instead? You could then shorten the description here to "we expect pa_nr == 0, any field in this structure will be filled in by this function". > * > * Returns: > * Number of pages pinned on success. > - * If @pa->pa_nr is 0 or negative, returns 0. > + * If @pa->pa_nr is not 0 initially, returns -EINVAL. > * If no pages were pinned, returns -errno. > */ The change itself looks good to me.