From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B7B8CC55181 for ; Wed, 22 Apr 2020 06:56:39 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 976A6206D9 for ; Wed, 22 Apr 2020 06:56:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 976A6206D9 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=inria.fr Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 1579C6E9E3; Wed, 22 Apr 2020 06:56:10 +0000 (UTC) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by gabe.freedesktop.org (Postfix) with ESMTPS id 407276E13D for ; Tue, 21 Apr 2020 15:29:24 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.72,410,1580770800"; d="scan'208";a="446201452" Received: from abo-173-121-68.mrs.modulonet.fr (HELO hadrien) ([85.68.121.173]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Apr 2020 17:29:02 +0200 Date: Tue, 21 Apr 2020 17:29:02 +0200 (CEST) From: Julia Lawall X-X-Sender: jll@hadrien To: Dan Carpenter Subject: Re: [bug report] drm/xen-front: Add support for Xen PV display frontend In-Reply-To: <20200421104522.GA86681@mwanda> Message-ID: References: <20200421104522.GA86681@mwanda> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 22 Apr 2020 06:54:41 +0000 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, kernel-janitors@vger.kernel.org, dri-devel@lists.freedesktop.org, oleksandr_andrushchenko@epam.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Tue, 21 Apr 2020, Dan Carpenter wrote: > Hi Kernel Janitors, > > Here is another idea that someone could work on, fixing the > IS_ERR_OR_NULL() checks in the xen driver. > > The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV > display frontend" from Apr 3, 2018, leads to the following static > checker warning: > > drivers/gpu/drm/xen/xen_drm_front_gem.c:140 xen_drm_front_gem_create() > warn: passing zero to 'ERR_CAST' > > drivers/gpu/drm/xen/xen_drm_front_gem.c > 133 struct drm_gem_object *xen_drm_front_gem_create(struct drm_device *dev, > 134 size_t size) > 135 { > 136 struct xen_gem_object *xen_obj; > 137 > 138 xen_obj = gem_create(dev, size); > 139 if (IS_ERR_OR_NULL(xen_obj)) > 140 return ERR_CAST(xen_obj); Are the other occurrences of this also a possible problem? There are a few others outside of xen. julia > > This warning is old and it's actually the result of a bug I had in my > devel version of Smatch yesterday. xen_obj can't really be NULL, but > if it were then the caller would return success which would probably > create some issues. > > When a function returns both error pointers and NULL then NULL is a > special case of success. Like say you have: "p = start_feature();". > If there is an allocation failure, then the code should return -ENOMEM > and the whole thing should fail. But if the feature is optional and > the user has disabled it in the config then we return NULL and the > caller has to be able to accept that. There are a lot of these > IS_ERR_OR_NULL() checks in the xen driver... > > The one here is clearly buggy because returning NULL would lead to a > run time failure. All these IS_ERR_OR_NULL() should be checked and > probably changed to just IS_ERR(). > > This sort of change is probably change is probably easiest if you build > the Smatch DB and you can check if Smatch thinks the functions return > NULL. > > ~/smatch/smatch_data/db/smdb.py return_states gem_create | grep INTERNAL > drivers/gpu/drm/xen/xen_drm_front_gem.c | gem_create | 58 | (-4095)-(-1) | INTERNAL | -1 | | struct xen_gem_object*(*)(struct drm_device*, ulong) | > drivers/gpu/drm/xen/xen_drm_front_gem.c | gem_create | 62 | 4065035897849303040 | INTERNAL | -1 | | struct xen_gem_object*(*)(struct drm_device*, ulong) | > drivers/gpu/drm/xen/xen_drm_front_gem.c | gem_create | 66 | 4065035897849303040 | INTERNAL | -1 | | struct xen_gem_object*(*)(struct drm_device*, ulong) | > drivers/gpu/drm/xen/xen_drm_front_gem.c | gem_create | 68 | 0,(-4095)-(-1) | INTERNAL | -1 | | struct xen_gem_object*(*)(struct drm_device*, ulong) | > > Smatch thinks that gem_create() sometimes returns NULL or error pointers > but that's because of a bug in the unreleased version of Smatch and > because gem_create() uses IS_ERR_OR_NULL(). > > 141 > 142 return &xen_obj->base; > 143 } > > regards, > dan carpenter > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel