Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp5658387pxb; Mon, 28 Mar 2022 15:37:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyNSmDvDWY9iSTXy0wdoaOLUvl3cIoVtKJtIpYLpm1vcDQgs7LVYH8OlWKqYy81eHzhuUdB X-Received: by 2002:a63:f452:0:b0:382:7af1:6ad6 with SMTP id p18-20020a63f452000000b003827af16ad6mr11492115pgk.500.1648507026503; Mon, 28 Mar 2022 15:37:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648507026; cv=none; d=google.com; s=arc-20160816; b=Op3ijHi05N69JJUvNOvsuwpCBlSCNfIRNCI5WrodhZXoI7smseWf5dv7ycTs0OGxld sfpovnrVZwXWZLCe/5AOd8gcmZ2d36yLG5QUb7M4pX5tq8F4+rKR3zZcjXUgtALIs+3r u/qNouzbZEDzqawV1uCFe7IP1Cw5IANmDzI1Ynhd9kkb8N+n4G3GLE7yL/UvxKJ1rDv6 6BD/rSnKUaKozaYDcXPqqGVwevO1kqDXIlRyPM7wnEiYx4FPNOPRhRfQOFNFMZV2a2Dw IRGluS18mKWEiVj7nNonxr0JdCmRz1c+3CBamxkqCOiYe3cQ0HcCqh4R0PrahlhuwiWq oUSA== 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 :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=0dHgcYzbWIkTWrrsdhZyyB/eFZvf/h00myBufYWcRbQ=; b=1JNsCNiU4AeIoMhilO98ieS6cIpeeDy2aEQWEVydDQgSBV8pTlJSvmKpHVIKeoY4ix BeHkl+qvnuQmFFNzTniXaFBC3zLQBukG1HObJtguK//PvfGeW33uGpjF9n7PUU+4/Vlu LPqSswIuCjg7iSqOCox40Igh/cbuBndeX2+zEDWlLwH1jxNcXvYg274xRaVbkgX/ozU7 bXH1bSJQb4GLxgTYt5LrOyYGrxU5trJuOuxTNHadSmvClKCFQHbMnTKaXt/xinQ0/kV1 Uk4MKTF3OB9E5NMlGKy+cpyNpfEciYjUIB0iUzrDIC700KxsnCa0vEnpGrhBzjIlRWoe 18bw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ERCjnZRn; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id f76-20020a62384f000000b004fa9560ad6bsi14436662pfa.106.2022.03.28.15.37.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Mar 2022 15:37:06 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ERCjnZRn; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 6C38B3EB90; Mon, 28 Mar 2022 14:45:07 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240862AbiC1LYd (ORCPT + 99 others); Mon, 28 Mar 2022 07:24:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54712 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240955AbiC1LXA (ORCPT ); Mon, 28 Mar 2022 07:23:00 -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 5C6FC55BEA; Mon, 28 Mar 2022 04:19:53 -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 04DECB81055; Mon, 28 Mar 2022 11:19:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D37BEC340EC; Mon, 28 Mar 2022 11:19:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1648466390; bh=dXFoBao1mnO+CxBybDVWep7qs/QLa3ksJJVYsnYonhc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ERCjnZRna2znaXntCbtvYQmwUUThsr5N8xJeP8at2m4Qoc9bXB5Bxp5bTUmWX3SB6 UunUy9L7vDzH4mV8zpDwueB4KwadIB5Q35G7S5bZdg7jx+9JCYNAp8z/v1H7W00vzw +JGkMl9yxD0MXURd+nkV+ZMdqWYqzrLNXucdFGe6hGm6Sw6XXeTHSO7ZAzkTSufpHj izIy6l6F6zkBnMgCKCUFg2lCu5WZaxA7BJ3Q1ClOzBcskm6KH0uWL5W2bb1Gb2VZwq jtPkSf65xgaFGxr/dqT4PRyjYqf0HRivGAtmXRU/BQStqLNtn3kXoGtvLKAyyJeVz0 WfyOZIlDKvJYg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Darren Hart , "Rafael J . Wysocki" , Sasha Levin , rafael@kernel.org, rdunlap@infradead.org, ying.huang@intel.com, linux-acpi@vger.kernel.org Subject: [PATCH AUTOSEL 5.17 36/43] ACPI/APEI: Limit printable size of BERT table data Date: Mon, 28 Mar 2022 07:18:20 -0400 Message-Id: <20220328111828.1554086-36-sashal@kernel.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220328111828.1554086-1-sashal@kernel.org> References: <20220328111828.1554086-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 19e50fcbf4d6..ad8ab3f12cf3 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