Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp271174pxj; Wed, 23 Jun 2021 21:54:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw8W0P5gy63Or3/SccfyvCQGV077DvohDAg540IbagtvwtuZHsc4C+su5Z+sDc3nCEIuxnO X-Received: by 2002:aa7:c902:: with SMTP id b2mr4415290edt.287.1624510474873; Wed, 23 Jun 2021 21:54:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624510474; cv=none; d=google.com; s=arc-20160816; b=p6w8mWaVl+T/7PKn+MoRZs6EEvJ4J8TUmzheShvzATIQYcBZ33OaPPQKluiBzg/4GZ lBpps9z1++94z87OEpyOWWH5YKO8labNFg0Xe9Kg0Dv/9szjUa7oGXiuemWdEaG5xm8C MBuzlvJTE3C4Dw9qpr0T6dCyr+vghrKshScmPB7F85I5RNa8ovE0SMk0Jdl0xgiTYsMp rRCuc4ytIkVgw3nNIl7w+JYUDbYrmLTP73gwMEKOar2JEGjseJ+AzTFA4vyKNOvcLL41 E3TuJwWdDLVp6J00cCFPiyjCQ5oqqt4OVRay32NTYCk5wySW3Wx7zd8kGUBe84VI0h8l ZH1Q== 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; bh=lSSlX/4IOylMo/uUyuLsQt15g/l5g3BhmMGkReCM9C8=; b=zzRTpMw0AoaDISXpHMbQGjFOllP+dwIk9ntiE/SwHPssE+z/GiX2HlbwV4mCKpmatW q2C7IEZ+DsmddOg6w7vd2CdIH9rQsjXuqI+Y1QVD07TBmNoOpvmd/jEdUYi42RxGzWfK Gjdctrutll0awYbxezwfrL3HQb3CSZNzViL8ROOHCdGG7i61H9h7lUJgmieuYbiHpHXf +V44NIETk4c9sFM15wx5mclhI+5LkbZpQNU0+Q4DiOT78t92UDzJkjoVT9zrTGbJTn/N lMoKfLeNBvBNiBl4E+uuHpUK1Gx4AcufGfWzWVT4SK7a/MxQSulcKNnaHGKudH6itAie dU7A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hg1si1912342ejc.245.2021.06.23.21.54.12; Wed, 23 Jun 2021 21:54:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230146AbhFXEyw convert rfc822-to-8bit (ORCPT + 99 others); Thu, 24 Jun 2021 00:54:52 -0400 Received: from yyz.mikelr.com ([170.75.163.43]:34238 "EHLO yyz.mikelr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229932AbhFXEys (ORCPT ); Thu, 24 Jun 2021 00:54:48 -0400 Received: from glidewell.localnet (198-84-194-208.cpe.teksavvy.com [198.84.194.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by yyz.mikelr.com (Postfix) with ESMTPSA id 2E7E54FA68; Thu, 24 Jun 2021 00:52:02 -0400 (EDT) From: Mikel Rychliski To: Christian =?ISO-8859-1?Q?K=F6nig?= Cc: Alex Deucher , "Pan, Xinhui" , David Airlie , Daniel Vetter , Thomas =?ISO-8859-1?Q?Hellstr=F6m?= , amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] drm/radeon: Fix NULL dereference when updating memory stats Date: Thu, 24 Jun 2021 00:52:01 -0400 Message-ID: <12410445.c4f2iDpdjA@glidewell> In-Reply-To: <085b7f51-15b8-42e0-fcf0-66da839542c8@amd.com> References: <20210622212613.16302-1-mikel@mikelr.com> <085b7f51-15b8-42e0-fcf0-66da839542c8@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday, June 23, 2021 2:55:04 AM EDT Christian K?nig wrote: > Please rather keep the new resource as parameter here and update before > adjusting bo->resource. > > This way you also don't need to export radeon_update_memory_usage(). I wasn't sure exactly what you intended with the request to "update before adjusting bo->resource". Assuming the statistics update is done as part of radeon_bo_move_notify(), I believe that function cannot be called any earlier in radeon_bo_move(). If it were, the source object would be invalidated before it moved. So I assume you're suggesting updating the memory usage earlier in bo_move_notify (before the early return for ghost objects). Thanks, Mikel