Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp408759pxm; Wed, 2 Mar 2022 18:38:43 -0800 (PST) X-Google-Smtp-Source: ABdhPJz+4w1/T+TKTDUsWKmm8WchgIO/mhSBUgivVOZkRnOfaCOEKHC18sYIIF7qzA+WnrPDXiNG X-Received: by 2002:a63:2bc1:0:b0:35e:c54b:3be0 with SMTP id r184-20020a632bc1000000b0035ec54b3be0mr28505026pgr.105.1646275123411; Wed, 02 Mar 2022 18:38:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646275123; cv=none; d=google.com; s=arc-20160816; b=i7vMQJeSmn1BYFIROBLAQWjHlXnbrZ1qQb6tte9BxlIIlVOIq0DBbGj+Vql0QXdPvB /3R8N5+bgroUYIsPtfrL0XZCihKHT3mMWfpLqKhvzGdEVlcri0VfpZXKwkUo0qOkxmCL msTEqOi08iYfYn7eTYPC49ceHPEedCAKQGVX9/JxbYfi7px492sdHZ1R+O2iBD0frocY iF3a6mdqDBELwFcMcIXuw20ERbzcbf+xPBsVYoAvh6o5Bw6RhmrwCXE970x+xSXJmHQp axTc88JcIXnMbZa0InTXKB+dC1yMss+dOv8ekksX6cVY/fn4vpxXL8B7WT/3uPJczP7W WvSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:references :cc:to:from:content-language:subject:user-agent:mime-version:date :message-id:dkim-signature; bh=nQOigE7QabiClKkeHMgV2FSLBhCGcQcb4YbpktLX8W0=; b=WPZEgo/wTpYi4OkA47NnEaLCrkgfmGzxiFTEJIxWXv0HMDvgy+ZNBWNqGW7xt6C+YR fHnx0Hr9yVuCg6jlwl9xumoy6BGdDdV4LvK/sZTJlwHIVg4//oPPVCiTQGv0ZjH5zg1a 4mE3lbYYSxqjFJa+hKUS2l/GsdwANojy4mD1shgTXVyfPhNQwpW4bSFIVsuH93pknP+h U2wYveKCD+tRA+noMd/jVd4wPgsKC0zxrqSa5FPUpLcHJ0DpoS+EHeTyBYJ2DguMPhHE V8of+RwQrFy009R4xbSKaP1ZzrKQ9+kG56gbD1zL18BE9U57t9KjJsbEsbyZa2VmsR7s heag== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gnuweeb.org header.s=default header.b="V/yQ/RvN"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnuweeb.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id p11-20020a17090a4f0b00b001bee31fbd36si652024pjh.116.2022.03.02.18.38.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Mar 2022 18:38:43 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@gnuweeb.org header.s=default header.b="V/yQ/RvN"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnuweeb.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 7F844617C; Wed, 2 Mar 2022 18:32:45 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231700AbiCCCdN (ORCPT + 99 others); Wed, 2 Mar 2022 21:33:13 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59842 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231743AbiCCCdM (ORCPT ); Wed, 2 Mar 2022 21:33:12 -0500 Received: from gnuweeb.org (gnuweeb.org [51.81.211.47]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3ADCF13E81; Wed, 2 Mar 2022 18:32:27 -0800 (PST) Received: from [192.168.43.69] (unknown [182.2.41.243]) by gnuweeb.org (Postfix) with ESMTPSA id 121D27E216; Thu, 3 Mar 2022 02:32:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gnuweeb.org; s=default; t=1646274746; bh=TUzitEj4aBUgL+Bsby3W+X8ST/3/o4WMlq2+CFaMLXc=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From; b=V/yQ/RvNucXD536SfA72fKV1ZavNrFL3JskOc6rzZ4JeAVnJKjFgrUhmWgXrHn9OZ /LqDbtCdRLJgeLXxpr8h9rJafDc018OJ7E1OeSc3xzdA86Poh4aK39XkaRnNTNaa8u 4DoB5b3yOzFc48YJT3EkxRBl6oLIp9iWtwDuCPADZXTgUaAUAkOYt9amDHixCDTDI+ aj78JdonuLchwVUgUhiQHbqHFj6EFpsAmcyPdZgRbgKJWVHs8TuzQKm/vvxvfbUPlJ e3EpTdFpG1a0KP37WiWKUL793vefDKYlm4z+dkGgy/ukehmfOZE3G2p1wvuXRjP0HJ CiK7bZ5leNs4A== Message-ID: <9dfe087a-f941-1bc4-657d-7e7c198888ff@gnuweeb.org> Date: Thu, 3 Mar 2022 09:32:16 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH v4 2/2] x86/mce/amd: Fix memory leak when `threshold_create_bank()` fails Content-Language: en-US From: Ammar Faizi To: Alviro Iskandar Setiawan , Yazen Ghannam Cc: Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Ingo Molnar , Thomas Gleixner , Tony Luck , linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org, gwml@vger.gnuweeb.org, x86@kernel.org, stable@vger.kernel.org, Alviro Iskandar Setiawan , Jiri Hladky , Greg Kroah-Hartman References: <20220301094608.118879-1-ammarfaizi2@gnuweeb.org> <20220301094608.118879-3-ammarfaizi2@gnuweeb.org> <4371a592-6686-c535-4daf-993dedb43cd4@gnuweeb.org> <109a10da-d1d1-c47a-2f04-31796457f6ff@gnuweeb.org> <20220303015826.4176416-1-alviro.iskandar@gnuweeb.org> <49313736-61f8-d001-0fe4-b6166c859585@gnuweeb.org> In-Reply-To: <49313736-61f8-d001-0fe4-b6166c859585@gnuweeb.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE autolearn=no 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 On 3/3/22 9:07 AM, Ammar Faizi wrote: > On 3/3/22 8:58 AM, Alviro Iskandar Setiawan wrote: >> hi sir, i think this can be improved again, we can avoid calling >> this_cpu_read(mce_num_banks) twice if we pass the numbanks as an >> argument, plz review the changes below > > OK, nice improvement. I will fold this in... > It looks like this now. Yazen, Alviro, please review the following patch. If you think it looks good, I will submit it for the v5. From 91a447f837d502b7a040cd68f333fb98f4b941d9 Mon Sep 17 00:00:00 2001 From: Ammar Faizi Date: Thu, 3 Mar 2022 09:22:17 +0700 Subject: [PATCH v5 2/2] x86/MCE/AMD: Fix memory leak when `threshold_create_bank()` fails In mce_threshold_create_device(), if threshold_create_bank() fails, the @bp will be leaked, because mce_threshold_remove_device() will not free the @bp. It only frees the @bp when we've already written the @bp to the @threshold_banks per-CPU variable, but at the point, we haven't. Fix this by extracting the cleanup part into a new static function _mce_threshold_remove_device(), then use it from create/remove device function. Also, eliminate the "goto out_err". Just early return inside the loop if we fail. Cc: Borislav Petkov Cc: Thomas Gleixner Cc: Greg Kroah-Hartman Cc: stable@vger.kernel.org # v5.8+ Fixes: 6458de97fc15 ("x86/mce/amd: Straighten CPU hotplug path") Co-authored-by: Alviro Iskandar Setiawan Signed-off-by: Alviro Iskandar Setiawan Co-authored-by: Yazen Ghannam Signed-off-by: Yazen Ghannam Signed-off-by: Ammar Faizi --- arch/x86/kernel/cpu/mce/amd.c | 32 +++++++++++++++++++------------- 1 file changed, 19 insertions(+), 13 deletions(-) diff --git a/arch/x86/kernel/cpu/mce/amd.c b/arch/x86/kernel/cpu/mce/amd.c index 9f4b508886dd..e492efab68a2 100644 --- a/arch/x86/kernel/cpu/mce/amd.c +++ b/arch/x86/kernel/cpu/mce/amd.c @@ -1293,10 +1293,23 @@ static void threshold_remove_bank(struct threshold_bank *bank) kfree(bank); } +static void _mce_threshold_remove_device(struct threshold_bank **bp, + unsigned int numbanks) +{ + unsigned int bank; + + for (bank = 0; bank < numbanks; bank++) { + if (bp[bank]) { + threshold_remove_bank(bp[bank]); + bp[bank] = NULL; + } + } + kfree(bp); +} + int mce_threshold_remove_device(unsigned int cpu) { struct threshold_bank **bp = this_cpu_read(threshold_banks); - unsigned int bank, numbanks = this_cpu_read(mce_num_banks); if (!bp) return 0; @@ -1307,13 +1320,7 @@ int mce_threshold_remove_device(unsigned int cpu) */ this_cpu_write(threshold_banks, NULL); - for (bank = 0; bank < numbanks; bank++) { - if (bp[bank]) { - threshold_remove_bank(bp[bank]); - bp[bank] = NULL; - } - } - kfree(bp); + _mce_threshold_remove_device(bp, this_cpu_read(mce_num_banks)); return 0; } @@ -1350,15 +1357,14 @@ int mce_threshold_create_device(unsigned int cpu) if (!(this_cpu_read(bank_map) & (1 << bank))) continue; err = threshold_create_bank(bp, cpu, bank); - if (err) - goto out_err; + if (err) { + _mce_threshold_remove_device(bp, numbanks); + return err; + } } this_cpu_write(threshold_banks, bp); if (thresholding_irq_en) mce_threshold_vector = amd_threshold_interrupt; return 0; -out_err: - mce_threshold_remove_device(cpu); - return err; } -- Ammar Faizi