Received: by 2002:a05:7412:8521:b0:e2:908c:2ebd with SMTP id t33csp2131947rdf; Mon, 6 Nov 2023 05:46:56 -0800 (PST) X-Google-Smtp-Source: AGHT+IEOHNk26RQ9Pt0wvgISJoHGvtg15s6lqXaSykbvF9mKZpEn7IQ10ovxJdpWPFWs9fY2OFNT X-Received: by 2002:a17:902:e744:b0:1cc:431f:55e3 with SMTP id p4-20020a170902e74400b001cc431f55e3mr12961931plf.28.1699278415460; Mon, 06 Nov 2023 05:46:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1699278415; cv=none; d=google.com; s=arc-20160816; b=EKjdHWiXoX3dq2ZHlerKWuX3jlDFfbu2RiezWWmLWdWFuRNXnz7aamKyRbX21CKybT nYyG25JhprTmCq+ikyVnZuYQFuptPcJkHPYEuQr6EIwBMLhKq0uLLdcElTJS7QnVvJU8 DxPR153doNxJy+lw4qMufFz5NKG/qbl9ebdNN4kXkIcww1DoW/zyHAw6r1ex6iChNd1m ba1yKx4leXT9rdR3n6ka+vMf2v3cL4mbj19j/5s7eNViuNjkpc5KU6li/9SXGuoODLTY wHwJyybE585VwvmiGJeRPxsTNwuHp2gPcMvZWHJ9MuNnXm1kjxwydvQqyrvu9b71Bys7 1paw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=/RhjdKd1guFXe/qQYYH2gwGu3xZCWb726LfHkjSe030=; fh=WcnaHuFRrOM3a1xNAwbDkYG6X69JWktIEB/yAmGSm+I=; b=mJy4TL86Sl3ZprMSfrOPMaP5Kkf+VGtU2Mp3Xcc5Eqd1iqoPJaprH+T85Kf0K+fJ33 XyqTSNh0GXyW15K53C1N7L/0NY0DehKw7yLcGhyi0nVq/Yuk8tiY9FilapIeQM2mGkYS z1/p6SLYmvMFfhcEAjQF26ubzo9MUh/yaaeqd+ByZlhU1q5TN8fVmgTga5msaYr6FISB rFpdlPg6JYutWPw1+srpKOiTpSKxWKaauBPyYu92rW7OcJhdI+wx6HZok89TeZeLQQFi 9AsEWb/z28L2KT5uEA5g66Pzsq/Fan/FtWF05y8cvrARVAfEPnXm8TBrwvpluvWDgsUZ fZVg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Vqlzg33r; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from snail.vger.email (snail.vger.email. [2620:137:e000::3:7]) by mx.google.com with ESMTPS id m12-20020a656a0c000000b00577960a815csi8832743pgu.188.2023.11.06.05.46.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Nov 2023 05:46:55 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Vqlzg33r; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 1DEDD8029C5E; Mon, 6 Nov 2023 05:46:54 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232700AbjKFNqr (ORCPT + 99 others); Mon, 6 Nov 2023 08:46:47 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34618 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231472AbjKFNqq (ORCPT ); Mon, 6 Nov 2023 08:46:46 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7C055D8; Mon, 6 Nov 2023 05:46:43 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CB78CC433C7; Mon, 6 Nov 2023 13:46:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1699278403; bh=UMo9qYG9JxxpGt1tXwkBsURejlZe7ea1mXalWt6sYSU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Vqlzg33ro2BWfJXpbHrXhNe2CcU6yPcQ59eO5vWnH8tzEqBPoVQfmfs3ZSKKv5zhY 4gVLTMGsua0PRJdMWWfG9QXKXAURFAiJE9/RskqdWwsMfNbtPvE/tP5faIUXRMN2aa cbYOcN82xmcl5udNag2AzoAwvBNHtfTjZVEIhOAa0PvXh0r5iX2qN36hY33XRPPy0f 4W8J+q+mWqoUxe4IWx3AJ1bJM1RlIuJ7yq02T26hiUxU0opRhYR/IhKoCIzAxgVq+h ui4qPeM/I56ocswP62wnegNhcHzo2XITTbl3k0CV5hcIJE1XLJ92jWAzqmaYu7M4l0 ZthyR6pinmgBQ== Date: Mon, 6 Nov 2023 14:46:40 +0100 From: Maxime Ripard To: Marco Pagani Cc: Maarten Lankhorst , Thomas Zimmermann , David Airlie , Daniel Vetter , Sumit Semwal , Christian Koenig , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org Subject: Re: [RFC PATCH] drm/test: add a test suite for GEM objects backed by shmem Message-ID: References: <20231023164541.92913-1-marpagan@redhat.com> <789aaf2b-4d68-4128-b8ff-c1ba4849e141@redhat.com> <3e32dbc2-c93f-45a1-a872-4e1798141a70@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="o32cap6w7m6manzj" Content-Disposition: inline In-Reply-To: <3e32dbc2-c93f-45a1-a872-4e1798141a70@redhat.com> X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE 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: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Mon, 06 Nov 2023 05:46:54 -0800 (PST) --o32cap6w7m6manzj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 30, 2023 at 11:58:20AM +0100, Marco Pagani wrote: > On 2023-10-25 10:43, Maxime Ripard wrote: > > On Tue, Oct 24, 2023 at 07:14:25PM +0200, Marco Pagani wrote: > >>>> +static void drm_gem_shmem_test_obj_create_private(struct kunit *tes= t) > >>>> +{ > >>>> + struct fake_dev *fdev =3D test->priv; > >>>> + struct drm_gem_shmem_object *shmem; > >>>> + struct drm_gem_object *gem_obj; > >>>> + struct dma_buf buf_mock; > >>>> + struct dma_buf_attachment attach_mock; > >>>> + struct sg_table *sgt; > >>>> + char *buf; > >>>> + int ret; > >>>> + > >>>> + /* Create a mock scatter/gather table */ > >>>> + buf =3D kunit_kzalloc(test, TEST_SIZE, GFP_KERNEL); > >>>> + KUNIT_ASSERT_NOT_NULL(test, buf); > >>>> + > >>>> + sgt =3D kzalloc(sizeof(*sgt), GFP_KERNEL); > >>>> + KUNIT_ASSERT_NOT_NULL(test, sgt); > >>>> + > >>>> + ret =3D sg_alloc_table(sgt, 1, GFP_KERNEL); > >>>> + KUNIT_ASSERT_EQ(test, ret, 0); > >>>> + sg_init_one(sgt->sgl, buf, TEST_SIZE); > >>>> + > >>>> + /* Init a mock DMA-BUF */ > >>>> + buf_mock.size =3D TEST_SIZE; > >>>> + attach_mock.dmabuf =3D &buf_mock; > >>>> + > >>>> + gem_obj =3D drm_gem_shmem_prime_import_sg_table(&fdev->drm_dev, &a= ttach_mock, sgt); > >>>> + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, gem_obj); > >>>> + KUNIT_ASSERT_EQ(test, gem_obj->size, TEST_SIZE); > >>>> + KUNIT_ASSERT_NULL(test, gem_obj->filp); > >>>> + KUNIT_ASSERT_NOT_NULL(test, gem_obj->funcs); > >>>> + > >>>> + shmem =3D to_drm_gem_shmem_obj(gem_obj); > >>>> + KUNIT_ASSERT_PTR_EQ(test, shmem->sgt, sgt); > >>>> + > >>>> + /* The scatter/gather table is freed by drm_gem_shmem_free */ > >>>> + drm_gem_shmem_free(shmem); > >>>> +} > >>> > >>> KUNIT_ASSERT_* will stop the execution of the test on failure, you > >>> should probably use a bit more of KUNIT_EXPECT_* calls otherwise you'= ll > >>> leak resources. > >>> > >>> You also probably want to use a kunit_action to clean up and avoid th= at > >>> whole discussion > >>> > >> > >> You are right. I slightly prefer using KUnit expectations (unless acti= ons > >> are strictly necessary) since I feel using actions makes test cases a = bit > >> less straightforward to understand. Is this okay for you? > >=20 > > I disagree. Actions make it easier to reason about, even when comparing > > assertion vs expectation > >=20 > > Like, for the call to sg_alloc_table and > > drm_gem_shmem_prime_import_sg_table(), the reasonable use of assert vs > > expect would be something like: > >=20 > > sgt =3D kzalloc(sizeof(*sgt), GFP_KERNEL); > > KUNIT_ASSERT_NOT_NULL(test, sgt); > >=20 > > ret =3D sg_alloc_table(sgt, 1, GFP_KERNEL); > > KUNIT_ASSERT_EQ(test, ret, 0); > >=20 > > /* > > * Here, it's already not super clear whether you want to expect vs > > * assert. expect will make you handle the failure case later, assert w= ill > > * force you to call kfree on sgt. Both kind of suck in their own ways. > > */ > >=20 > > sg_init_one(sgt->sgl, buf, TEST_SIZE); > >=20 > > gem_obj =3D drm_gem_shmem_prime_import_sg_table(&fdev->drm_dev, &attach= _mock, sgt); > > KUNIT_ASSERT_NOT_ERR_OR_NULL(test, gem_obj); > >=20 > > /* > > * If the assert fails, we forgot to call sg_free_table(sgt) and kfree(= sgt). > > */ > >=20 > > KUNIT_EXPECT_EQ(test, gem_obj->size, TEST_SIZE); > > KUNIT_EXPECT_NULL(test, gem_obj->filp); > > KUNIT_EXPECT_NOT_NULL(test, gem_obj->funcs); > >=20 > > /* > > * And here we have to handle the case where the expectation was wrong, > > * but the test still continued. > > */ > >=20 > > But if you're not using an action, you still have to call kfree(sgt), > > which means that you might still > >=20 > > shmem =3D to_drm_gem_shmem_obj(gem_obj); > > KUNIT_ASSERT_PTR_EQ(test, shmem->sgt, sgt); > >=20 > > /* > > * If the assertion fails, we now have to call drm_gem_shmem_free(shmem) > > */ > >=20 > > /* The scatter/gather table is freed by drm_gem_shmem_free */ > > drm_gem_shmem_free(shmem); > >=20 > > /* everything's fine now */ > >=20 > > The semantics around drm_gem_shmem_free make it a bit convoluted, but > > doing it using goto/labels, plus handling the assertions and error > > reporting would be difficult. > >=20 > > Using actions, we have: > >=20 > > sgt =3D kzalloc(sizeof(*sgt), GFP_KERNEL); > > KUNIT_ASSERT_NOT_NULL(test, sgt); > >=20 > > ret =3D kunit_add_action_or_reset(test, kfree_wrapper, sgt); > > KUNIT_ASSERT_EQ(test, ret, 0); > >=20 > > ret =3D sg_alloc_table(sgt, 1, GFP_KERNEL); > > KUNIT_ASSERT_EQ(test, ret, 0); > >=20 > > ret =3D kunit_add_action_or_reset(test, sg_free_table_wrapper, sgt); > > KUNIT_ASSERT_EQ(test, ret, 0); > >=20 > > sg_init_one(sgt->sgl, buf, TEST_SIZE); > >=20 > > gem_obj =3D drm_gem_shmem_prime_import_sg_table(&fdev->drm_dev, &attach= _mock, sgt); > > KUNIT_ASSERT_NOT_ERR_OR_NULL(test, gem_obj); > > KUNIT_EXPECT_EQ(test, gem_obj->size, TEST_SIZE); > > KUNIT_EXPECT_NULL(test, gem_obj->filp); > > KUNIT_EXPECT_NOT_NULL(test, gem_obj->funcs); > >=20 > > /* drm_gem_shmem_free will free the struct sg_table itself */ > > kunit_remove_action(test, sg_free_table_wrapper, sgt); > > kunit_remove_action(test, kfree_wrapper, sgt); >=20 > I agree that using actions makes error handling cleaner. However, I still > have some concerns about the additional complexity that actions introduce. > For instance, I feel these two lines make the testing harness more complex > without asserting any additional property of the component under test.=20 If anything, the API makes it more difficult to deal with. It would actually be harder/messier to handle without an action. > In some sense, I wonder if it is worth worrying about memory leaks when > a test case fails. At that point, the system is already in an inconsistent > state due to a bug in the component under test, so it is unsafe to contin= ue > anyway. I guess the larger issue is: once that code will be merged, we're going to have patches to convert to actions because they make it nicer and fix a couple of issues anyway. So, if it's still the state we're going to end up in, why not doing it right from the beginning? Maxime --o32cap6w7m6manzj Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCZUjuQAAKCRDj7w1vZxhR xZIUAP4nxKW5nlbzzvyXfNDLXwSOCafaX8ziFwHyO6uOpAaQ/wD/ahMbjKTpWtAv lSr9PJJaR+rJk7pnvNB14wMm6Ud7owo= =9b+7 -----END PGP SIGNATURE----- --o32cap6w7m6manzj--