From patchwork Mon Oct 24 11:31:27 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 10151 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp639050wru; Mon, 24 Oct 2022 13:29:05 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7FtoFJCCYazKfgWX66SDomBZg6mJ3aG0LI8EEQ7FQmEtfi7fvOylnk3pLku84Xd1l0Ogpt X-Received: by 2002:a17:907:168e:b0:7a1:6786:f16 with SMTP id hc14-20020a170907168e00b007a167860f16mr11460309ejc.590.1666643345617; Mon, 24 Oct 2022 13:29:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666643345; cv=none; d=google.com; s=arc-20160816; b=YeFsUVfABY84TJ2zDhsBp+2KInjBk1A/m8enG87ylWIsf6/G7IeCT0iIkDo/zZ5m+o NycP/QVOpIcAejX+fo0IRii3/SwQBsMGB0iBDgbuam+B7S8qyw62H6/C4qn5Wj3MsBoN Br8RQOBGaersRFd1buAEQlpBYe2K89yd1+98jhxJh9Mh0/nH0EZuOGTlNYFtfT/O4esD uGVBTrRGrUjIqqJAjkRMy5zGcGxYtXSvJxI8XAWnNNiJCv6K8zDky11jEI4jYC/ZkcVW 56CqcxELrgufHHExoeZN65QwSTXdia/NK9tYSF68+NtK6GHrvn5SbJRcfvzmazkMiA50 XHqA== 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 :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=pU52KNfrFWQRkPxkmINKTMrbjamUVsH76BFBDb12iQU=; b=ySq38mmTXHirjDWtSVazsCKlgt/EkTXnsDVmhggRFJSSy8A3oR77Y22x0RpGi3F/mv 5JLchxv0eCKXmxsdzHiaxjSpJCNSUcNxHaqhttmg2WEAnNFVGJQ6VRBuZBH6r81n6ITu Q9Vk3uQPPRgzR59xTmhjEKmjm6JN90mWsyUK9zNGxd13/fmKXuDX/bbYOHgSDoRbzNyz aGZ3QY3rkAB0HDz1AmnSmg+h0ns57GcBCeZEz1Q5yeZK1Cjmx0YhZhjSLAQ7CL/Ndy0B YQShtKf3jS+gpk9F+cFwnRPSR+HDuI15OVEenpGANwzgtiqbA0TwnoUrBr+A+sNltT// yuqA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=RB7qKZAA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y9-20020a056402358900b00458d1c48708si816576edc.303.2022.10.24.13.28.41; Mon, 24 Oct 2022 13:29:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=RB7qKZAA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234020AbiJXUQh (ORCPT + 99 others); Mon, 24 Oct 2022 16:16:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40964 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234122AbiJXUQG (ORCPT ); Mon, 24 Oct 2022 16:16:06 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8C0BCB65; Mon, 24 Oct 2022 11:33:34 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id EA3E4B815AC; Mon, 24 Oct 2022 12:29:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4E5F6C433D7; Mon, 24 Oct 2022 12:29:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666614591; bh=qdJdH1Ww3YeKPIgjETV1ThfvN509TAE5iFLPR3eu1+Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RB7qKZAAruMHFPFNb/aU7VcrtqaPOZh4ZdWDiEl2mlg9VHqyjyQIWSZ2c/ot7Jf5m PVZTH5TGfiPqRn8GjsBw9UnyNfzbczYqdsdeP1rdZ14McSHi/WxFzIZNbybzoCthY1 9Q8QKoyEC7fZb+cuXsXnFTnpJT42C1UFxCFDGzMg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Shuai Xue , Tony Luck , "Rafael J. Wysocki" , Sasha Levin Subject: [PATCH 5.10 290/390] ACPI: APEI: do not add task_work to kernel thread to avoid memory leak Date: Mon, 24 Oct 2022 13:31:27 +0200 Message-Id: <20221024113035.325362340@linuxfoundation.org> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20221024113022.510008560@linuxfoundation.org> References: <20221024113022.510008560@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham 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 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747602212831667130?= X-GMAIL-MSGID: =?utf-8?q?1747602212831667130?= From: Shuai Xue [ Upstream commit 415fed694fe11395df56e05022d6e7cee1d39dd3 ] If an error is detected as a result of user-space process accessing a corrupt memory location, the CPU may take an abort. Then the platform firmware reports kernel via NMI like notifications, e.g. NOTIFY_SEA, NOTIFY_SOFTWARE_DELEGATED, etc. For NMI like notifications, commit 7f17b4a121d0 ("ACPI: APEI: Kick the memory_failure() queue for synchronous errors") keep track of whether memory_failure() work was queued, and make task_work pending to flush out the queue so that the work is processed before return to user-space. The code use init_mm to check whether the error occurs in user space: if (current->mm != &init_mm) The condition is always true, becase _nobody_ ever has "init_mm" as a real VM any more. In addition to abort, errors can also be signaled as asynchronous exceptions, such as interrupt and SError. In such case, the interrupted current process could be any kind of thread. When a kernel thread is interrupted, the work ghes_kick_task_work deferred to task_work will never be processed because entry_handler returns to call ret_to_kernel() instead of ret_to_user(). Consequently, the estatus_node alloced from ghes_estatus_pool in ghes_in_nmi_queue_one_entry() will not be freed. After around 200 allocations in our platform, the ghes_estatus_pool will run of memory and ghes_in_nmi_queue_one_entry() returns ENOMEM. As a result, the event failed to be processed. sdei: event 805 on CPU 113 failed with error: -2 Finally, a lot of unhandled events may cause platform firmware to exceed some threshold and reboot. The condition should generally just do if (current->mm) as described in active_mm.rst documentation. Then if an asynchronous error is detected when a kernel thread is running, (e.g. when detected by a background scrubber), do not add task_work to it as the original patch intends to do. Fixes: 7f17b4a121d0 ("ACPI: APEI: Kick the memory_failure() queue for synchronous errors") Signed-off-by: Shuai Xue Reviewed-by: Tony Luck Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin --- drivers/acpi/apei/ghes.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index 0c8330ed1ffd..5206fd3b7867 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -985,7 +985,7 @@ static void ghes_proc_in_irq(struct irq_work *irq_work) ghes_estatus_cache_add(generic, estatus); } - if (task_work_pending && current->mm != &init_mm) { + if (task_work_pending && current->mm) { estatus_node->task_work.func = ghes_kick_task_work; estatus_node->task_work_cpu = smp_processor_id(); ret = task_work_add(current, &estatus_node->task_work,