Received: by 2002:a05:7412:8d10:b0:f3:1519:9f41 with SMTP id bj16csp6705127rdb; Fri, 15 Dec 2023 06:19:47 -0800 (PST) X-Google-Smtp-Source: AGHT+IEdmUQcY4wHYYC/9rTSpYUBhriFVKg2J1zOMTHL+CKR8af/KzXsoAbMprgY5SqBLCGc0GRA X-Received: by 2002:a2e:9944:0:b0:2cc:4c50:8984 with SMTP id r4-20020a2e9944000000b002cc4c508984mr624508ljj.95.1702649987319; Fri, 15 Dec 2023 06:19:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702649987; cv=none; d=google.com; s=arc-20160816; b=XbQdN5B1GKucpEIrxzAQchRh+WGaGRsD5F4pBXtDN36h1VeeCmUrs/hAECLYX0hUob 0X/vLEBtQGrZLi29+dAodDlj0e+1BCtgSakAZrSmU0rasZTvAmk4GxBldiat+l/OlIr2 GjcegNPmkVGsZq/sjzfXVN0wMW7Ind/UWGpeCRBI19UYPusOKWugrNicLonn7Zu4ZMlY fALSA7i9fOCeU1gIpY78gzWAMODVBTlxJMvvnKW46sdlP4ZCVvQVLYHtvfLgIkjAnqjR L4mQJX2LJwwtqtlOeZja/ytSjdfn/7Z58YdmUp6nNMNn43teVktU5XBGsrVeG0iZFERE 16QQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:list-unsubscribe:list-subscribe:list-id:precedence :message-id:date:references:in-reply-to:subject:cc:to:dkim-signature :dkim-signature:from; bh=s+ur53cIUdj33ok3eBL+Esj2uZivDHkdKlUPrUz0hIA=; fh=y03Rc/FXe2YwXKDae9F67eSD1fi3XkmGVvxGLz8nxyk=; b=d80gnzY7Ah1NRJ/to35/vgh5QLhxoY7FygQXa4rHxLlWK0SP6ekQr2xrEO2CeWDgrq tb2/kq6v55zcJEHV3m5XOicg+4Emd9wmGuRRF2kihOZ/X9L9qzijTWGvgvZpyuC676wt jZwobUIFyGN036nhHpwwJpNTv8KbuZvg2KXN28jYp3Pv5wNbCDCX5VEXvD4fm/sQ+mLj JjekIc1KNyBR06H36wtOE2bELQ2jXEMwTW6FYMD49OAFEI+fMWo3qkQbAxyXS/Tjq8Fq aAYxgp2W20DzHBnIlUR44yUHt2YniWAWCsga5iefqBIop31IcJJWWz3XGeHUIuEkNhZq 3opQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=Ofh53ErB; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel+bounces-1098-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-1098-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id h26-20020a50cdda000000b00551e381f910si2823767edj.228.2023.12.15.06.19.47 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Dec 2023 06:19:47 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-1098-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=Ofh53ErB; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel+bounces-1098-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-1098-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 144C61F26AA1 for ; Fri, 15 Dec 2023 14:19:47 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 53F4C30CF0; Fri, 15 Dec 2023 14:19:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="Ofh53ErB"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="38+mkE00" X-Original-To: linux-kernel@vger.kernel.org Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 08F322E65C; Fri, 15 Dec 2023 14:19:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1702649973; 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=s+ur53cIUdj33ok3eBL+Esj2uZivDHkdKlUPrUz0hIA=; b=Ofh53ErBL17sEf0hiRZv9yXnchYe2Spj4pmB6hfISduS6dhb+CSrrrnKQJkM1Ne++UXOaW SUUOENQLXQgkFy89HZ4DTEJZFdkeAVkvm9xwD+ZVv1yy4xRUnMs0H85YVhiftwF4UV4VKZ 3OtuDhC85EtERbAqdwAT4FJlOogUB0VRqOi6YMv2vHwBFBfbjNT8PYcySnJsGhFLKltjGm uqNhUkGbXSlt7QIzHP9Ry5D1zEalVBJwjO7yNjPS7nnhHg95QcCblXTXpoA68eWTY9Sm4N fuyU5rVqNOtyxSD9yfIccenA3gcebJNrjVibBwZq4vi8mBNHKCLQ2XcfAxX0uA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1702649973; 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=s+ur53cIUdj33ok3eBL+Esj2uZivDHkdKlUPrUz0hIA=; b=38+mkE00xZtcq4NGXsFNW0cII7dp6Qgxd09zOo2CsTyeh9NZkjcbF7CO00zjkCEHBdhVZv rJ26/eWdmwPnIaCg== To: "Zhang, Rui" , "jsperbeck@google.com" , "tip-bot2@linutronix.de" Cc: "peterz@infradead.org" , "linux-kernel@vger.kernel.org" , "linux-tip-commits@vger.kernel.org" , "x86@kernel.org" , Andres Freund Subject: [PATCH] x86/acpi: Handle bogus MADT APIC tables gracefully In-Reply-To: <87ttonpbnr.ffs@tglx> References: <87ttonpbnr.ffs@tglx> Date: Fri, 15 Dec 2023 15:19:32 +0100 Message-ID: <8734w3o8ej.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain The recent fix to ignore invalid x2APIC entries inadvertently broke systems with creative MADT APIC tables. The affected systems have APIC MADT tables where all entries have invalid APIC IDs (0xFF), which means they register exactly zero CPUs. But the condition to ignore the entries of APIC IDs < 255 in the X2APIC MADT table is solely based on the count of MADT APIC table entries. As a consequence the affected machines enumerate no secondary CPUs at all because the APIC table has entries and therefore the X2APIC table entries with APIC IDs < 255 are ignored. Change the condition so that the APIC table preference for APIC IDs < 255 only becomes effective when the APIC table has valid APIC ID entries. IOW a APIC table full of invalid APIC IDs is considered to be empty which in consequence enables the X2APIC table entries with a APIC ID < 255 and restores the expected behaviour. Fixes: ec9aedb2aa1a ("x86/acpi: Ignore invalid x2APIC entries") Reported-by: John Sperbeck Reported-by: Andres Freund Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org --- arch/x86/kernel/acpi/boot.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -293,6 +293,7 @@ acpi_parse_lapic(union acpi_subtable_hea processor->processor_id, /* ACPI ID */ processor->lapic_flags & ACPI_MADT_ENABLED); + has_lapic_cpus = true; return 0; } @@ -1134,7 +1135,6 @@ static int __init acpi_parse_madt_lapic_ if (!count) { count = acpi_table_parse_madt(ACPI_MADT_TYPE_LOCAL_APIC, acpi_parse_lapic, MAX_LOCAL_APIC); - has_lapic_cpus = count > 0; x2count = acpi_table_parse_madt(ACPI_MADT_TYPE_LOCAL_X2APIC, acpi_parse_x2apic, MAX_LOCAL_APIC); }