Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp922509pxb; Wed, 6 Apr 2022 04:22:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy3LIL1S4VBNrm1SO8MsZTi6+rE4d5w8htQjrrpmrjoetaJ0k2NW0/oGqDUTENAGjJpxNUM X-Received: by 2002:a65:418b:0:b0:382:250b:4dda with SMTP id a11-20020a65418b000000b00382250b4ddamr6896950pgq.428.1649244171945; Wed, 06 Apr 2022 04:22:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649244171; cv=none; d=google.com; s=arc-20160816; b=PsInC0f0Qldr9Eqlk8sAPfVdl4tXNg3dHvEV1JACUUAvjwvRKuNcW1EqScslnXfFFW hEqZPnb4CUC2A4ZIV0M/vZnANheTPcvAV3GmXXl//L5PvaRDshh9+SQGv04AAXauB5p8 jXfQRu8q3GbJOnQU01aFxzyHi2Orr+JQXrpHDhRfZ2RUT4vUBaOQ+nOcISng5JpITaBe Qt5tIzC8dSjPlL5h0ZXuObmHVOq2o/Wv8CsN4Ul+eDMc31DvtlwjUUz9H9lzgd58xZNc KpE0lBInf8CKjytJCucm5ejjp2X3DtXlrWenaXk8ylc3lT29Vi4jr7qJgKUVXXLyFJPv /cLQ== 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=lcuoiOP5EJv9cxG+tQmt7VNSP7XEvnlmSkum++zAka8=; b=Ek+jVyzwBGlrjIGe+eshAn+z8Rk5SWJdsnhVeCpkhSTgF7R10oiZUe/PfvhHIdZJxI YYITqbUwHg+qSkBKb7Lh1X7fGzD2JRRBA1mwArc+AMTaybv1TaxtJ5qYAqbu4S6ja8Mc 0DRzbFR5p+udbJtXzLKeFuEjJs52cSGlzo5yyaSET0LErdZ50kxMx/u+QeRT9kBgvyht Aj1K+sbBJhv1c8iwePs2P/ghgOn99Sn+roazsRlQq+4Tiebs88hFBxsv4rDSfdHRsHwU 5Kb1/xZXUDwZIZLLlopal7yXvYKGyS6k1e6u6rwHWBllfGbaXxyJmjAy4Ooz7tREtI0V DxyA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=OQdMDUoC; 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=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id a1-20020a656401000000b003816043ee32si15575650pgv.39.2022.04.06.04.22.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Apr 2022 04:22:51 -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=@linuxfoundation.org header.s=korg header.b=OQdMDUoC; 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=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id D08C646C6B8; Wed, 6 Apr 2022 02:44:46 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1391832AbiDEWIo (ORCPT + 99 others); Tue, 5 Apr 2022 18:08:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39468 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243489AbiDEKhC (ORCPT ); Tue, 5 Apr 2022 06:37:02 -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 537B053E35; Tue, 5 Apr 2022 03:22:04 -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 0920AB81B96; Tue, 5 Apr 2022 10:22:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 54A2BC385A0; Tue, 5 Apr 2022 10:22:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1649154121; bh=xm9x/FZCEUK/x/FQ/b38Amq5e9rRH5/BKJxWdvbog6E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OQdMDUoCf7gNdNW2+bABiVG02LhiTQR9FgwgO0/PPb/4DeVVxhAMI4eRQKuOd7pzY 27z+OgbqyenRjiYQICXuqqDQ9buvi1e9bqJgxHjzKgqCGPlSVlVj8V2N4WxEctrqqa tqmiYTmphPpJtlxNO03Crp8xlS79sl075XydikFc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Darren Hart , "Rafael J. Wysocki" , Sasha Levin Subject: [PATCH 5.10 465/599] ACPI/APEI: Limit printable size of BERT table data Date: Tue, 5 Apr 2022 09:32:39 +0200 Message-Id: <20220405070312.665406784@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220405070258.802373272@linuxfoundation.org> References: <20220405070258.802373272@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, 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 From: Darren Hart [ Upstream commit 3f8dec116210ca649163574ed5f8df1e3b837d07 ] Platforms with large BERT table data can trigger soft lockup errors while attempting to print the entire BERT table data to the console at boot: watchdog: BUG: soft lockup - CPU#160 stuck for 23s! [swapper/0:1] Observed on Ampere Altra systems with a single BERT record of ~250KB. The original bert driver appears to have assumed relatively small table data. Since it is impractical to reassemble large table data from interwoven console messages, and the table data is available in /sys/firmware/acpi/tables/data/BERT limit the size for tables printed to the console to 1024 (for no reason other than it seemed like a good place to kick off the discussion, would appreciate feedback from existing users in terms of what size would maintain their current usage model). Alternatively, we could make printing a CONFIG option, use the bert_disable boot arg (or something similar), or use a debug log level. However, all those solutions require extra steps or change the existing behavior for small table data. Limiting the size preserves existing behavior on existing platforms with small table data, and eliminates the soft lockups for platforms with large table data, while still making it available. Signed-off-by: Darren Hart Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin --- drivers/acpi/apei/bert.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/acpi/apei/bert.c b/drivers/acpi/apei/bert.c index 86211422f4ee..598fd19b65fa 100644 --- a/drivers/acpi/apei/bert.c +++ b/drivers/acpi/apei/bert.c @@ -29,6 +29,7 @@ #undef pr_fmt #define pr_fmt(fmt) "BERT: " fmt +#define ACPI_BERT_PRINT_MAX_LEN 1024 static int bert_disable; @@ -58,8 +59,11 @@ static void __init bert_print_all(struct acpi_bert_region *region, } pr_info_once("Error records from previous boot:\n"); - - cper_estatus_print(KERN_INFO HW_ERR, estatus); + if (region_len < ACPI_BERT_PRINT_MAX_LEN) + cper_estatus_print(KERN_INFO HW_ERR, estatus); + else + pr_info_once("Max print length exceeded, table data is available at:\n" + "/sys/firmware/acpi/tables/data/BERT"); /* * Because the boot error source is "one-time polled" type, -- 2.34.1