Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp5101977ybc; Fri, 15 Nov 2019 14:56:39 -0800 (PST) X-Google-Smtp-Source: APXvYqycso3IJTUriSsriJLy57lJ0x4xtgjuB9QdM/bAPoaaNpb2Lch5U+Ff3Y6ySY3NsrcF1Qff X-Received: by 2002:a17:906:390a:: with SMTP id f10mr4717052eje.310.1573858599083; Fri, 15 Nov 2019 14:56:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573858599; cv=none; d=google.com; s=arc-20160816; b=EkpjgbUwNc1luoC89Zx/5kCJr0tRJJAgwNrJKa1d0kkS1bVuRoHYrRC4CF58HW32zp RYC6CUDDBqZcndPI2U/8QqVCkI0Pw9ZdeKjOoDLtsqFJbsdYhu5vHCHlh5lfH42jrvvo ZR/ov0rfzLrXtvibpyp4BBea2ZdsNAy+LwJQEEiF+YY5sltL/g7zFf2b+lFX7TDJTGr+ v8e1eOLhisqAqCpjBVnbrf9g3HmL3PmM2oDGY3Ia/eXcyZ2leX6oXt2MsTGz1zOt9xId lZGduS23iEI6dHyyqHfbfaNpPw7nqJLBDWoAVRHUFk/hvnIejY+rgru6KWa9yVcQjpHK InpA== 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:dkim-signature; bh=XxLRwCNIqyo3k0JMi1Xi1l9F+MTU6v0lA44sbxrMUCs=; b=uRmGKCX104OTFfMroMEmjThUCYu2DmbR+ZpjFkO8epSa0nlGuAmfc/CziYHpFaW5ZZ qm91evPw360my0xImWhAXniX1ovDuWCYZkrcEIVolb6smmRxGU/jUoPESz/S6tub+OCz ujgur0LYooELH5hJFCaw9MvnRej3/hLbaQ0kawjpcLKdVa+u7AjyUb5nUcyJd37yNMs6 1IxkNluxrcqKK2z3UsHXsO3Z+05SqbYZ6H3F2/bBtMhU3oM+YeZp9+QGf73lbb1dphNK TWmHniQFqMoOEKHIqzDr+rlk4iZXrZCtfBAIdUkmRbTnSzNcyAMvzGV+ReYHTlDZPULP RNAg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=aLZtKCqD; 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=pass (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 y9si6047147eju.209.2019.11.15.14.56.14; Fri, 15 Nov 2019 14:56:39 -0800 (PST) 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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=aLZtKCqD; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727110AbfKOWwV (ORCPT + 99 others); Fri, 15 Nov 2019 17:52:21 -0500 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:22314 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726969AbfKOWwV (ORCPT ); Fri, 15 Nov 2019 17:52:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573858340; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XxLRwCNIqyo3k0JMi1Xi1l9F+MTU6v0lA44sbxrMUCs=; b=aLZtKCqDOAvBdnAL2NFO1lXwmKa/eZLzFwp3EgUm1OERi1RT9C84EiZsrjz0OyJvTQ8nQ7 ljI6YR400XMjVWea9Uf4/aGUuorCjyta0ULkDzgD/pWd0mPOqExeTDDPtGMxPlS/TqXCT5 RVtGz1/AnVA4elm4ekAzf2g9vcVu3qk= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-357-HJK_wxZNOSqc8u6YXdGSGQ-1; Fri, 15 Nov 2019 17:52:18 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 211F3DBE5; Fri, 15 Nov 2019 22:52:17 +0000 (UTC) Received: from x1.home (ovpn-116-56.phx2.redhat.com [10.3.116.56]) by smtp.corp.redhat.com (Postfix) with ESMTP id AD06F6012E; Fri, 15 Nov 2019 22:52:16 +0000 (UTC) Date: Fri, 15 Nov 2019 15:52:14 -0700 From: Alex Williamson To: Andy Shevchenko Cc: linux-kernel@vger.kernel.org, Christoph Hellwig , Dan Williams , Cornelia Huck Subject: Re: [PATCH v1 5/5] vfio/pci: Drop duplicate check for size parameter of memremap() Message-ID: <20191115155214.55e949cc@x1.home> In-Reply-To: <20191115180044.83659-5-andriy.shevchenko@linux.intel.com> References: <20191115180044.83659-1-andriy.shevchenko@linux.intel.com> <20191115180044.83659-5-andriy.shevchenko@linux.intel.com> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-MC-Unique: HJK_wxZNOSqc8u6YXdGSGQ-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 15 Nov 2019 20:00:44 +0200 Andy Shevchenko wrote: > Since memremap() returns NULL pointer for size =3D 0, there is no need > to duplicate this check in the callers. >=20 > Cc: Christoph Hellwig > Cc: Dan Williams > Cc: Alex Williamson > Cc: Cornelia Huck > Signed-off-by: Andy Shevchenko > --- > drivers/vfio/pci/vfio_pci_igd.c | 8 +------- > 1 file changed, 1 insertion(+), 7 deletions(-) >=20 > diff --git a/drivers/vfio/pci/vfio_pci_igd.c b/drivers/vfio/pci/vfio_pci_= igd.c > index 53d97f459252..3088a33af271 100644 > --- a/drivers/vfio/pci/vfio_pci_igd.c > +++ b/drivers/vfio/pci/vfio_pci_igd.c > @@ -75,13 +75,7 @@ static int vfio_pci_igd_opregion_init(struct vfio_pci_= device *vdev) > =09=09return -EINVAL; > =09} > =20 > -=09size =3D le32_to_cpu(*(__le32 *)(base + 16)); > -=09if (!size) { > -=09=09memunmap(base); > -=09=09return -EINVAL; > -=09} > - > -=09size *=3D 1024; /* In KB */ > +=09size =3D le32_to_cpu(*(__le32 *)(base + 16)) * 1024; /* In KB */ > =20 > =09if (size !=3D OPREGION_SIZE) { > =09=09memunmap(base); This seems convoluted, patch 1/5 states "[t]here is no use of memremap() to be called with size =3D 0", which we weren't doing thanks to the check removed above. So now we are potentially calling it with zero, apparently only to take advantage of this new behavior, and we lose the error granularity that previously such a condition failed with an -EINVAL and now we fail with an -ENONMEM and cannot distinguish whether the OpRegion table size was empty or we just weren't able to memremap() it. I don't see how this is an improvement. Thanks, Alex