Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp2457974ybg; Thu, 30 Jul 2020 23:17:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzeIG6VSOrWIG+DOABmO+obnL8jC/9kuHtvvMnraoZtQK8qff8wxiOmmEwv8NHwDrrxZnZ+ X-Received: by 2002:a50:e719:: with SMTP id a25mr2261927edn.15.1596176250836; Thu, 30 Jul 2020 23:17:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596176250; cv=none; d=google.com; s=arc-20160816; b=oColbzdqUIc4c2gn40yc4Dle11eE2eFBk3Dw/IF5DEwC5ZH7sSHneIOs2XY5mgQ7Gc R+QxH7FfCJ6oa91Q8v7GeF3KWL90aL+RdhPMcRxnrXJUdNQ3PE4TFTqEX4x1DPs3pu+6 x+os5u0nDrq1BJeAj45A0l9uI/kXq7BVngwSGtMjsobmilwWpONctAG9GnVRiYCJItoN Qj5AptG9EJ4ROHxljsYUuLqYqqu6gb6nRyuZ8a9XB8KtKGpxrZuvxQk7oU/mZ9KT8K36 P/mNv/xM/tW+czkswkBqCHFNMYMPoiPUWqo3FIBaCW4lhFqG9Rr4ZDVEeyAJA8Oijjue os8w== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=OalmUM+8GnIILq/ZlZiEJ95Zx+6wC2oiZqcMuFzZs8M=; b=juHYdn0MNwbuGp0anIMJzYIROJegNjkWE+uumwaMfC3M5uxj5jT8e2u6BBJoB99xeY TTXeUYhk8t1fvOD+9UePeAwNUCcgz9zXoCucq8UXf9kQ4Vo0KO+49Kr14AfFjh/IzWc4 u1YbgvxS+L0eLB8pMHHTf81e5ezH7XM+YtcL8y4OXiNLl05f894z6DeWzzge4O6ByWvW hdWSe5naNtDmQH+bxyAhO5Z+QVH4eOdfWe7+mT1NHhgIz02mgANIvVVKn97gkFBEDC0/ asdqhxcq77YybYr4bITRO4SKzJxlG9a+4sDuRSND9ppGIFOOKJihdpIX0+Wo6Hvhi6p/ 85bA== 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 mm22si4488391ejb.735.2020.07.30.23.16.51; Thu, 30 Jul 2020 23:17:30 -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 S1731236AbgGaGP1 (ORCPT + 99 others); Fri, 31 Jul 2020 02:15:27 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:8864 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726972AbgGaGP1 (ORCPT ); Fri, 31 Jul 2020 02:15:27 -0400 Received: from DGGEMS414-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 3B32FF126CD88B9C5463; Fri, 31 Jul 2020 14:15:17 +0800 (CST) Received: from [127.0.0.1] (10.174.179.33) by DGGEMS414-HUB.china.huawei.com (10.3.19.214) with Microsoft SMTP Server id 14.3.487.0; Fri, 31 Jul 2020 14:15:14 +0800 Subject: Re: [PATCH] drm/amdkfd: Put ACPI table after using it To: Felix Kuehling , Alex Deucher , =?UTF-8?Q?Christian_K=c3=b6nig?= , David Airlie , Daniel Vetter CC: References: <1595411308-15654-1-git-send-email-guohanjun@huawei.com> <443ace32-0860-f823-bc3f-3faafd5da54e@amd.com> From: Hanjun Guo Message-ID: <4d220f68-e259-ee4d-127d-7f9056aa7aa6@huawei.com> Date: Fri, 31 Jul 2020 14:15:14 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <443ace32-0860-f823-bc3f-3faafd5da54e@amd.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.179.33] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/7/31 10:41, Felix Kuehling wrote: > Hi Hanjun, > > Sorry for the late reply. > > Thank you for the patch and the explanation. This seems to have been > broken since the first version of KFD in 2014. See one suggestion inline. > > Am 2020-07-22 um 5:48 a.m. schrieb Hanjun Guo: >> The acpi_get_table() should be coupled with acpi_put_table() if >> the mapped table is not used at runtime to release the table >> mapping. >> >> In kfd_create_crat_image_acpi(), crat_table is copied to pcrat_image, >> and in kfd_create_vcrat_image_cpu(), the acpi_table is only used to >> get the OEM info, so those table mappings need to be release after >> using it. >> >> Signed-off-by: Hanjun Guo >> --- >> drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 16 +++++++++++----- >> 1 file changed, 11 insertions(+), 5 deletions(-) >> >> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c >> index 1009a3b..d378e61 100644 >> --- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c >> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c >> @@ -756,6 +756,7 @@ int kfd_create_crat_image_acpi(void **crat_image, size_t *size) >> struct acpi_table_header *crat_table; >> acpi_status status; >> void *pcrat_image; >> + int rc = 0; >> >> if (!crat_image) >> return -EINVAL; >> @@ -776,17 +777,21 @@ int kfd_create_crat_image_acpi(void **crat_image, size_t *size) >> >> if (ignore_crat) { >> pr_info("CRAT table disabled by module option\n"); > > We should probably move this check to before we get the CRAT table. > There is not point getting and putting it if we're going to ignore it > anyway. > > Do you want to send an updated patch with that change? Or maybe do it as > a 2-patch series? I will do it as 2-patch series and send a updated patch set. Thanks Hanjun