Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp3513868pxb; Mon, 4 Apr 2022 19:27:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxNr1Mbvffom3Tg9+OedqI0kFbSqabppS0fFqZmU7cXagqDi9cJhZm5dTxt3olz3M5+eQqg X-Received: by 2002:a63:9711:0:b0:398:5cf2:20bc with SMTP id n17-20020a639711000000b003985cf220bcmr984337pge.480.1649125652380; Mon, 04 Apr 2022 19:27:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649125652; cv=none; d=google.com; s=arc-20160816; b=Vv71yz2xhNSnoznwCqfY75l3+oOaKepskAwsa5WzUtW3oD+HFHGykcOe6wycvkFAjP pk7VIpaTonY2qSITiQbF+uUdzX9VxSsvUJOWU0+40Mmx9TOCmuRhYGyy1tV/950HnXF6 EsRnNbKXNTZTncAdeUuXEMHySv5Tmwea1PlPwuDYgwfHSiPWCUVWf3FxxXh9Mui36ZOl QxS/MK5mVB8BDAbCmwBAIJPWTbd4a2m00vSb7EiSxwN+lqPLWx5OrMf8U8pwq54SXsyE X16xs1xwsK4VCksFluutT/cefHfNauDhT6r8EJCMwtfmyUn9225oQOO+k0/BSscbDp9R jplQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=0FYO/QymqAO+y1Q05iYfClrPZn9DYCQj8o18qRL5/l0=; b=sgzeY63eIErAAtbfhCjhfEArLCL277oK5sOF1xRl2Xa9sZVWDZdL6To/Oq5baQtQV7 kUrMi442c0oZt/5VOePkYW6HdBCuvyBsyz/oohs2q4LUhomSq9erouLMGDGVJVKTwVge ATuGkzfgUxk8gasUInrtho6s00ONq0xUwAzmpZshSD+Y/XgDvYzinHsCxzevytdSw2fq /yD7bkIGSYDLh/AEFmrVXy8Bd70bbwhcvBQY+c/fnum1M3kfqANkt9KC2q0vzybQYfAN IhGsSiUnpDOOJVpmDIsPAFzGdvV6lKY0F9LrOI/mwKi3HKsJYE/3g7vnWVX4hemMt0HX VgBA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=igMsj+7i; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=F6Pm90ni; 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=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id pf7-20020a17090b1d8700b001c6cf2d1b0csi701931pjb.126.2022.04.04.19.27.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Apr 2022 19:27:32 -0700 (PDT) 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=@linutronix.de header.s=2020 header.b=igMsj+7i; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=F6Pm90ni; 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=QUARANTINE dis=NONE) header.from=linutronix.de Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id ECA9B42F340; Mon, 4 Apr 2022 17:50:06 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359588AbiDCRF4 (ORCPT + 99 others); Sun, 3 Apr 2022 13:05:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33988 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234629AbiDCRFz (ORCPT ); Sun, 3 Apr 2022 13:05:55 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 802B3167CB; Sun, 3 Apr 2022 10:04:00 -0700 (PDT) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1649005439; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0FYO/QymqAO+y1Q05iYfClrPZn9DYCQj8o18qRL5/l0=; b=igMsj+7iOclnRmjo3ROBNua2ZGLjOf6Pjbn5hKLYQ58wUynP3GlxuqyweBgD3LUEIz2OhZ 9Eos4AEHYZ90RIFx35yojdQ1FI6uJgLAKTGV+dmRf1SaELxBvFxBtS5byFookMR0vkOgYy +qRkq/bVh5DEBl6iU6lEprV29BmafFjlXbwEPsGz6huZHSi7SACfj1nL6dwiSoy6En9umR bN0BHSUA/EBrFRb4/YeQJncg/WMV4NWCp3yp6kGv60ejsnZBmKLaPegILWobi6nVhbSIYl goyRb3pJFB1HL86fswDLBjiTXrU8o1upq9RGA8AWM+eHnm6WDheIbzsQ7yUhlA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1649005439; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0FYO/QymqAO+y1Q05iYfClrPZn9DYCQj8o18qRL5/l0=; b=F6Pm90niQA6fSu2wZ0hj2XwU90qnDpNGMPk+Aql+I7+r1KkstPG46logbBEtyxHDDMp8jd gEIgJit+1EJrFwBA== To: Ammar Faizi , Borislav Petkov Cc: Ammar Faizi , Alviro Iskandar Setiawan , Dave Hansen , "H. Peter Anvin" , Ingo Molnar , Tony Luck , Yazen Ghannam , Linux Edac Mailing List , Linux Kernel Mailing List , Stable Kernel , GNU/Weeb Mailing List , x86 Mailing List Subject: Re: [PATCH v6 2/2] x86/MCE/AMD: Fix memory leak when `threshold_create_bank()` fails In-Reply-To: <20220329104705.65256-3-ammarfaizi2@gnuweeb.org> References: <20220329104705.65256-1-ammarfaizi2@gnuweeb.org> <20220329104705.65256-3-ammarfaizi2@gnuweeb.org> Date: Sun, 03 Apr 2022 19:03:58 +0200 Message-ID: <87wng6ksjl.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain 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,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 Tue, Mar 29 2022 at 17:47, Ammar Faizi wrote: > In mce_threshold_create_device(), if threshold_create_bank() fails, the > @bp will be leaked, because the call to mce_threshold_remove_device() > will not free the @bp. mce_threshold_remove_device() frees > @threshold_banks. At that point, the @bp has not been written to > @threshold_banks, @threshold_banks is NULL, so the call is just a nop. > > Fix this by extracting the cleanup part into a new static function > __threshold_remove_device(), then call it from create/remove device > functions. The way simpler fix is to move > } > this_cpu_write(threshold_banks, bp); before the loop. That's safe because the banks cannot yet be reached via an MCE as the vector is not yet enabled: > if (thresholding_irq_en) > mce_threshold_vector = amd_threshold_interrupt; Thanks, tglx