Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp17623876ybl; Thu, 2 Jan 2020 08:53:32 -0800 (PST) X-Google-Smtp-Source: APXvYqwLjGG1xCmN/JtdDEdzeUhOfqFI6UWCU7Y6T+ogM2nyeXfULRRb4fCko34hvYNy3AOLQHhO X-Received: by 2002:a9d:674f:: with SMTP id w15mr94921636otm.243.1577984012340; Thu, 02 Jan 2020 08:53:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1577984012; cv=none; d=google.com; s=arc-20160816; b=IyxdU7N97rTlNi3vruxv9EjX1GSwtaUYg07Za8gLeKtn15DArhS4V1Hqao2eIYuwwc MSJK3O4D+YSgR6gK08aq6mTHXbva9r2+7zZ2QNAJZcrGymvmD2fGKRwr9C4Et1qACW4M yiEwNXRm6McbLmfXnsHBFmPMg8W4IcqcIZq6jZkAVL/XH0wJuEG9zwZ7U1iuogYoQbSh +QM1IV6Dx5tfbBFF7snMN6vah3UIB2LAdEX7yMYvX7Jzw77I7ECKVvvPWRLbJSKUOSck fAQx08v7xiSFUlL37LUolnT6ah8CQQANcGIVtZM2s8hpOoxcpJjEisQn1pj/3M1Kxxqh js5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=njeWI+KAXYGUA6SsOkGlHRQz/PusOL22Pz6zm9pBi9Y=; b=WKoruWFddsbY1MHLJf0U804mbE8CoxOF+vj739WGgDR9zNezOfn3TcVnGYI4J5GoCV ydCbnqPe6MSkkyAdBKOk4xYUeL9x3HylN/b8aok6W8YDYZxSbewFpPmXEYy7l8YQz5A9 igcmrKF2LnzUzx0vECXQ4Jkx7a6TF9uKSe7b/ibNY/j5VuRqY2UEOXuRA3bUbcQX5DgV Y942xNrZR2IrqY6DDVL0gK1NqY60HqC6BNMwz80Ks6K0p1Ihd+trI656RhngUHE6vhjX P9BxlLMg3YtPvhDjzX7KsHOV7IHFPW/M+ua9mXHHvwrb9SsvcI2xYuHjCAmxtXidrgCL rg2A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Xhvs6Ahg; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i6si29370671oth.182.2020.01.02.08.53.19; Thu, 02 Jan 2020 08:53:32 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Xhvs6Ahg; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728859AbgABQwe (ORCPT + 99 others); Thu, 2 Jan 2020 11:52:34 -0500 Received: from mail-oi1-f193.google.com ([209.85.167.193]:34811 "EHLO mail-oi1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728824AbgABQwd (ORCPT ); Thu, 2 Jan 2020 11:52:33 -0500 Received: by mail-oi1-f193.google.com with SMTP id l136so13146719oig.1 for ; Thu, 02 Jan 2020 08:52:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=njeWI+KAXYGUA6SsOkGlHRQz/PusOL22Pz6zm9pBi9Y=; b=Xhvs6AhgXjGPRJsGfLuOFsppL+pozXfXVOU94GdDcR+GCLskgSifoDz6bhAyaf3vGO DTjfr6X1g4RPDJDWE50mJzNFZuvnK/PLp6pRtnbCtiZ4HMO9xY8D930q/NXrz5qJcoyx LwNnmJlxvzfsDBeydPVcy9fsp4QPUfQ2ZVQ2GyG0IcPQc8XT4YSEGOQ6B6yTcU73XawV A0XAjH+JbCqVSIgrUU62QilwC80dKWbtPOJHYGS/1qX9gNeKMZmv9nirN37wvJzlQWmI tYEjl56qUTM8ZTxvtN5BxDQUmEQGQCGiy7uxKzkWnBXxhUA8Byu8aCb90J92OBoSPHic XN8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=njeWI+KAXYGUA6SsOkGlHRQz/PusOL22Pz6zm9pBi9Y=; b=qUDGWoLb2CK02sh+kOrOB473iP/ILqV9FZ7RMI0EkyG1ITa7Lg9Krq8n/+6fPL8GDE rrAlWfjDewswz4bxVrfH6uL+lmLTxykczqM7qzTqAzGlGjZkfJGDKttf/mjXKk1+LeqS Y6lH5YSWGPSFxD3+2rgZNbvrbYcgUw2LRpgWISED7W/Kgws5L7CORatgaLbFHunZ3SSU vbYho5HLy7cYe5B70vhJECQYCY5P0Ta8/nYUm9isot/DNWWtmtZNnaMymQyh/QnNn0LY 8zXHYvaOnB9fDIGZTBWKirJJ19tNN7362+9DEmaeGyxvPyuP7MAzHhZenAQ2LvrhmpLB dnlA== X-Gm-Message-State: APjAAAWQcbtYXu1AwD+Vs4iphXsyctXIGuZzi87yMFXzHJOIB/0Lb2o1 Q8M5FhLNOciFWCRlAqtWjpGlsPmE/BIqXWqm4ZxnNg== X-Received: by 2002:a05:6808:30d:: with SMTP id i13mr2382287oie.144.1577983952440; Thu, 02 Jan 2020 08:52:32 -0800 (PST) MIME-Version: 1.0 References: <20191220164358.177202-1-shakeelb@google.com> <20200101101708.GA14315@zn.tnic> In-Reply-To: <20200101101708.GA14315@zn.tnic> From: Shakeel Butt Date: Thu, 2 Jan 2020 08:52:21 -0800 Message-ID: Subject: Re: [PATCH v2] x86/resctrl: Fix potential memory leak To: Borislav Petkov Cc: Reinette Chatre , Fenghua Yu , Thomas Gleixner , Ingo Molnar , x86@kernel.org, LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 1, 2020 at 2:17 AM Borislav Petkov wrote: > > On Fri, Dec 20, 2019 at 08:43:58AM -0800, Shakeel Butt wrote: > > The set_cache_qos_cfg() is leaking memory when the given level is not > > RDT_RESOURCE_L3 or RDT_RESOURCE_L2. However at the moment, this function > > is called with only valid levels but to make it more robust and future > > proof, we should be handling the error path gracefully. > > > > Fixes: 99adde9b370de ("x86/intel_rdt: Enable L2 CDP in MSR IA32_L2_QOS_CFG") > > Signed-off-by: Shakeel Butt > > Acked-by: Fenghua Yu > > --- > > Changes since v1: > > - Updated the commit message > > > > > > arch/x86/kernel/cpu/resctrl/rdtgroup.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c > > index 2e3b06d6bbc6..a0c279c7f4b9 100644 > > --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c > > +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c > > @@ -1748,8 +1748,10 @@ static int set_cache_qos_cfg(int level, bool enable) > > update = l3_qos_cfg_update; > > else if (level == RDT_RESOURCE_L2) > > update = l2_qos_cfg_update; > > - else > > + else { > > + free_cpumask_var(cpu_mask); > > return -EINVAL; > > + } > > And why can't the level check happen first and the allocation second, > thus needing to allocate the cpu mask only when the level is valid? > We definitely can. Will send the v3 patch. Shakeel