Message ID | 20221026224640.7542-3-dmitry.osipenko@collabora.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp520544wru; Wed, 26 Oct 2022 15:49:10 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5w8TX+Z6yDGPE+PX8Vb3njENjQEiaYQEojFIvtd7YQDxklV2lrnGSidqyV94g7tANZwL1t X-Received: by 2002:a17:907:7da5:b0:78e:2c3b:55a2 with SMTP id oz37-20020a1709077da500b0078e2c3b55a2mr38886729ejc.96.1666824550285; Wed, 26 Oct 2022 15:49:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666824550; cv=none; d=google.com; s=arc-20160816; b=xKK6wre3Q28EJh7utMRW7kavcFV/hDGTYuTK9ELSp6tlipBIYxIehB4jkUM3tTG2ge kjQSgs0cyNXxRIl4qIEgkcixSnI3OowfEg8VxSj9f54WqDoHwjTlwo+wiEVDIBHZHO8T hi81VCOw4F9ahNfXJ2F7+CwXELskmJV+PqSZ5JxWzdj2zF5W0BxoCfBRR7zj/Qx0PGrN uzItXM2lfRb5fs1YKBk92MsJMjKV1+NREFnQI+0bIo3upeGEQ9lHVVpCaP57wAefCEcc v3ItoLWnTGrfQ8RBZy451uXK2Sd2qr1AQOLolSGRM59jGAuFg4UzLpIbrpCvWgxEMZYc jPeg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=LFZsc9FN/HbKz5TOyr2KlpB+MP1p7KlrgqI8Jsnm74c=; b=vwS0rY0jZfEqobOl9uFUkJdMycl2G+Kc6UDmG+tfEwxydC6pJaFuhYG3egtECVRcwK WJ0VNkX7U5u0oXTiNfjAqAXPOpAsfyCpTxHtryzTUU59sBSacCNDNJ8NXwIvmHKZVbtA ZAATREWG3RdfGHoyJfXU5hwdE7TGfz5MNP4RlMXUlWg0LYGRved9PNg0yNhFZ12vlHYa 7yukMxwKsKW1q72bNC777bmyPLXzXlhHkrYrJE6EoRJJZUtoWz9oUAXCk+wRM6XD28dQ iZ4vYZ2vVpXvQVqopulm3PWnNR+pQvVsQOcc32NaU0Va4LowawlIyRxVEhrslYmPIQL+ 08nQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=SqNESA2f; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id kx3-20020a170907774300b0078b41dcf4b8si6135393ejc.479.2022.10.26.15.48.44; Wed, 26 Oct 2022 15:49:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=SqNESA2f; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233804AbiJZWr4 (ORCPT <rfc822;pwkd43@gmail.com> + 99 others); Wed, 26 Oct 2022 18:47:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54914 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233891AbiJZWrg (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 26 Oct 2022 18:47:36 -0400 Received: from madras.collabora.co.uk (madras.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e5ab]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C5F4C1BEAC for <linux-kernel@vger.kernel.org>; Wed, 26 Oct 2022 15:47:23 -0700 (PDT) Received: from dimapc.. (109-252-112-196.nat.spd-mgts.ru [109.252.112.196]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: dmitry.osipenko) by madras.collabora.co.uk (Postfix) with ESMTPSA id B449C66028B1; Wed, 26 Oct 2022 23:47:21 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1666824442; bh=1PIO06hn7jCRpnGP0u+Jtd9+O0JPNXdkS3SYQoY8CMI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SqNESA2fcICoaDUbmdf5nDit5oNiPedlCm15j7wjtZAE/3+DUBjfnbL73vcx/eEU5 eFj1ZJ/KvxMyF1SZsTcOPw0mo15AFs3pMncShRhhR/oJwsFn61AvPHHg3AxCZ8wiLX 6QnMb1rz1B5nXO6GLajXChPmIZA2InFfx1zDeCigGMlI12c+IvqLpCaa4B4M944DYb Hoc6Ml+tXAnDOXOF20hDjKWzBPXAekYgqoD/c2Ct2uI6T5QaxuPsUzSCGIseNXoKJF dOIhgKd1zvMVMUUprVNhanMOfV2dbbaS7Q4jsbj00Md5VXmOMvNwVHEphZzH2AHUaZ Tot9HZllpEOUQ== From: Dmitry Osipenko <dmitry.osipenko@collabora.com> To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Maxime Ripard <mripard@kernel.org>, Sumit Semwal <sumit.semwal@linaro.org>, Thomas Zimmermann <tzimmermann@suse.de>, =?utf-8?q?Christian_K=C3=B6nig?= <christian.koenig@amd.com>, David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>, noralf@tronnes.org, Dan Carpenter <dan.carpenter@oracle.com> Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: [PATCH v1 2/2] drm/gem: Check whether object is NULL in drm_gem_vunmap() Date: Thu, 27 Oct 2022 01:46:40 +0300 Message-Id: <20221026224640.7542-3-dmitry.osipenko@collabora.com> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20221026224640.7542-1-dmitry.osipenko@collabora.com> References: <20221026224640.7542-1-dmitry.osipenko@collabora.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747792219701225624?= X-GMAIL-MSGID: =?utf-8?q?1747792219701225624?= |
Series |
Fixes for dma-buf locking issues found by Smatch
|
|
Commit Message
Dmitry Osipenko
Oct. 26, 2022, 10:46 p.m. UTC
The drm_gem_vunmap() will crash with a NULL dereference if the passed
object pointer is NULL. It wasn't a problem before we added the locking
support to drm_gem_vunmap function because the mapping argument was always
NULL together with the object. Make drm_gem_vunmap() functions to handle
the NULL pointers better.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/dri-devel/Y1kFEGxT8MVlf32V@kili/
Fixes: 79e2cf2e7a19 ("drm/gem: Take reservation lock for vmap/vunmap operations")
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
drivers/gpu/drm/drm_gem.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
Comments
Am 27.10.22 um 00:46 schrieb Dmitry Osipenko: > The drm_gem_vunmap() will crash with a NULL dereference if the passed > object pointer is NULL. It wasn't a problem before we added the locking > support to drm_gem_vunmap function because the mapping argument was always > NULL together with the object. Make drm_gem_vunmap() functions to handle > the NULL pointers better. > > Reported-by: Dan Carpenter <dan.carpenter@oracle.com> > Link: https://lore.kernel.org/dri-devel/Y1kFEGxT8MVlf32V@kili/ > Fixes: 79e2cf2e7a19 ("drm/gem: Take reservation lock for vmap/vunmap operations") > Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> > --- > drivers/gpu/drm/drm_gem.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c > index b8db675e7fb5..ee0a246ff4ac 100644 > --- a/drivers/gpu/drm/drm_gem.c > +++ b/drivers/gpu/drm/drm_gem.c > @@ -1175,11 +1175,11 @@ EXPORT_SYMBOL(drm_gem_vmap); > > void drm_gem_vunmap(struct drm_gem_object *obj, struct iosys_map *map) > { > - dma_resv_assert_held(obj->resv); > - > - if (iosys_map_is_null(map)) > + if (!obj || iosys_map_is_null(map)) > return; I'm not very keen about that. Calling a function with all parameters NULL doesn't make much sense and is clearly a coding error. Hiding that somehow doesn't help but rather makes things worse. The only execption to that are things like kfree() or *_put() which work with the lifetime of objects. Why is the static checker complaining about that in the first place? Regards, Christian. > > + dma_resv_assert_held(obj->resv); > + > if (obj->funcs->vunmap) > obj->funcs->vunmap(obj, map); > > @@ -1202,6 +1202,9 @@ EXPORT_SYMBOL(drm_gem_vmap_unlocked); > > void drm_gem_vunmap_unlocked(struct drm_gem_object *obj, struct iosys_map *map) > { > + if (!obj || iosys_map_is_null(map)) > + return; > + > dma_resv_lock(obj->resv, NULL); > drm_gem_vunmap(obj, map); > dma_resv_unlock(obj->resv);
On Thu, Oct 27, 2022 at 08:17:31AM +0200, Christian König wrote: > > > Am 27.10.22 um 00:46 schrieb Dmitry Osipenko: > > The drm_gem_vunmap() will crash with a NULL dereference if the passed > > object pointer is NULL. It wasn't a problem before we added the locking > > support to drm_gem_vunmap function because the mapping argument was always > > NULL together with the object. Make drm_gem_vunmap() functions to handle > > the NULL pointers better. > > > > Reported-by: Dan Carpenter <dan.carpenter@oracle.com> > > Link: https://lore.kernel.org/dri-devel/Y1kFEGxT8MVlf32V@kili/ Fixes: > > 79e2cf2e7a19 ("drm/gem: Take reservation lock for vmap/vunmap > > operations") > > Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> > > --- > > drivers/gpu/drm/drm_gem.c | 9 ++++++--- > > 1 file changed, 6 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c > > index b8db675e7fb5..ee0a246ff4ac 100644 > > --- a/drivers/gpu/drm/drm_gem.c > > +++ b/drivers/gpu/drm/drm_gem.c > > @@ -1175,11 +1175,11 @@ EXPORT_SYMBOL(drm_gem_vmap); > > void drm_gem_vunmap(struct drm_gem_object *obj, struct iosys_map *map) > > { > > - dma_resv_assert_held(obj->resv); > > - > > - if (iosys_map_is_null(map)) > > + if (!obj || iosys_map_is_null(map)) > > return; > > I'm not very keen about that. Calling a function with all parameters NULL > doesn't make much sense and is clearly a coding error. Hiding that somehow > doesn't help but rather makes things worse. > > The only execption to that are things like kfree() or *_put() which work > with the lifetime of objects. > > Why is the static checker complaining about that in the first place? > drivers/gpu/drm/drm_client.c:240 drm_client_buffer_delete() warn: variable dereferenced before check 'buffer->gem' (see line 238) regards, dan carpenter
Am 27.10.22 um 09:28 schrieb Dan Carpenter: > On Thu, Oct 27, 2022 at 08:17:31AM +0200, Christian König wrote: >> >> Am 27.10.22 um 00:46 schrieb Dmitry Osipenko: >>> The drm_gem_vunmap() will crash with a NULL dereference if the passed >>> object pointer is NULL. It wasn't a problem before we added the locking >>> support to drm_gem_vunmap function because the mapping argument was always >>> NULL together with the object. Make drm_gem_vunmap() functions to handle >>> the NULL pointers better. >>> >>> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> >>> Link: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2FY1kFEGxT8MVlf32V%40kili%2F&data=05%7C01%7Cchristian.koenig%40amd.com%7C50d3b7e10eca4c7fb72108dab7ecd646%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638024525139985844%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ET0TRHscb1bQVVHgBkmYvTQyV2Q6WqcMC83LDlrY5ZM%3D&reserved=0 Fixes: >>> 79e2cf2e7a19 ("drm/gem: Take reservation lock for vmap/vunmap >>> operations") >>> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> >>> --- >>> drivers/gpu/drm/drm_gem.c | 9 ++++++--- >>> 1 file changed, 6 insertions(+), 3 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c >>> index b8db675e7fb5..ee0a246ff4ac 100644 >>> --- a/drivers/gpu/drm/drm_gem.c >>> +++ b/drivers/gpu/drm/drm_gem.c >>> @@ -1175,11 +1175,11 @@ EXPORT_SYMBOL(drm_gem_vmap); >>> void drm_gem_vunmap(struct drm_gem_object *obj, struct iosys_map *map) >>> { >>> - dma_resv_assert_held(obj->resv); >>> - >>> - if (iosys_map_is_null(map)) >>> + if (!obj || iosys_map_is_null(map)) >>> return; >> I'm not very keen about that. Calling a function with all parameters NULL >> doesn't make much sense and is clearly a coding error. Hiding that somehow >> doesn't help but rather makes things worse. >> >> The only execption to that are things like kfree() or *_put() which work >> with the lifetime of objects. >> >> Why is the static checker complaining about that in the first place? >> > drivers/gpu/drm/drm_client.c:240 drm_client_buffer_delete() > warn: variable dereferenced before check 'buffer->gem' (see line 238) Well than rather modify drm_client_buffer_delete() instead. Calling drm_gem_vunmap() with obj NULL is certainly not a good idea if we even check that for drm_gem_object_put(). Interesting that the static checkers complain about that :) Regards, Christian. > > regards, > dan carpenter >
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index b8db675e7fb5..ee0a246ff4ac 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -1175,11 +1175,11 @@ EXPORT_SYMBOL(drm_gem_vmap); void drm_gem_vunmap(struct drm_gem_object *obj, struct iosys_map *map) { - dma_resv_assert_held(obj->resv); - - if (iosys_map_is_null(map)) + if (!obj || iosys_map_is_null(map)) return; + dma_resv_assert_held(obj->resv); + if (obj->funcs->vunmap) obj->funcs->vunmap(obj, map); @@ -1202,6 +1202,9 @@ EXPORT_SYMBOL(drm_gem_vmap_unlocked); void drm_gem_vunmap_unlocked(struct drm_gem_object *obj, struct iosys_map *map) { + if (!obj || iosys_map_is_null(map)) + return; + dma_resv_lock(obj->resv, NULL); drm_gem_vunmap(obj, map); dma_resv_unlock(obj->resv);