Received: by 2002:a05:6a10:a852:0:0:0:0 with SMTP id d18csp126750pxy; Tue, 4 May 2021 20:43:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyo9AANBQY8wDBjBD9VaR3+v+EO9cyNadQe3cJfX4H1RgZiECryi9jsX/JDGBmP90RasmQA X-Received: by 2002:a17:902:b68c:b029:eb:6c82:60da with SMTP id c12-20020a170902b68cb02900eb6c8260damr29657190pls.25.1620186236870; Tue, 04 May 2021 20:43:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620186236; cv=none; d=google.com; s=arc-20160816; b=J2a7GxeYy7v4DXMAs0F5CpqCB4zbwghiL8Cx5LfbmXy4sslMHmZrdDHKitNt21w8TJ pe301O903F2JAFNBeDWs5oo2bUzmAF8RrEqpb4JC3rhze1ylMta6aenObDg48Dgzy6tZ z71hjfvHHa6E6wsZoZmjtBvmlxSnotbU4deqjla59FoufGmG2HyF4b3tMCqchURNe5Mv nZrUxM8OUDc5uO40fMKOdAJtzNVY4WjPXZ7O7nWr/BFCZ9ExrNvOXp0bc5Crr/1soFT6 /AFF/UYBQ7oao/RJlxu5KYfISE9RbLiC0gAR9mjBm47YZg2L5xnV/sN9Fr1DO2hO1309 hziA== 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 :message-id:date:subject:cc:to:from:ironport-sdr:ironport-sdr; bh=6pb996iK+owVO31twBz9oqPzZ0enh4vbmBobhpp9jp8=; b=DUT7bEBKpJv2SIc2yYSFsM9BX6NpA12Qjg/hxSjQoTTTUq6botGMztB8T8Eg5htCyh q9REEYGDGQBzdimCVuM1J10wOAh9U1PbZosoOTVNnUq3WI9VCUY56jmb79rrOVGDycv+ IG3+kWqTigkPqoNVIk7AQDo5CSg7tmx7Z3XM0VXvo5g0qPceYdNbACDolsRYn2dtMfgB hbkNitULjGJmn0QTfCQ9MGli1lI5+YpaOHT0tT2f7AByhykO7CILFkQvF1KtendF8aQX T9pDLzohi0Ou7GGv6YY9cSsP6ZbcVtTxsMaqonN8nIMdxoctYkD2xhvBGgaRm6YRXjEh JWQQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r207si18951978pfr.344.2021.05.04.20.43.19; Tue, 04 May 2021 20:43:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231285AbhEEDks (ORCPT + 99 others); Tue, 4 May 2021 23:40:48 -0400 Received: from mga05.intel.com ([192.55.52.43]:63184 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231182AbhEEDks (ORCPT ); Tue, 4 May 2021 23:40:48 -0400 IronPort-SDR: /6qGUObCmQUh7Ym8pk+jcRZc2jKLjXLhj9U+pLMU/U1kxBTP3RaaEypW4Mm7N7D6M48Lo7sh5w BgXLRJYfGJgQ== X-IronPort-AV: E=McAfee;i="6200,9189,9974"; a="283543173" X-IronPort-AV: E=Sophos;i="5.82,273,1613462400"; d="scan'208";a="283543173" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 May 2021 20:39:49 -0700 IronPort-SDR: vnskNKp8kJx1esrd37lTsXOUZCgMVC09G5383Kgk3X3E8Bfgr+45mUBIgIoErym1BDD3/XpvCl h6OopRC+yTjQ== X-IronPort-AV: E=Sophos;i="5.82,273,1613462400"; d="scan'208";a="433602351" Received: from tassilo.jf.intel.com ([10.54.74.11]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 May 2021 20:39:49 -0700 From: Andi Kleen To: peterz@infradead.org Cc: linux-kernel@vger.kernel.org, Andi Kleen Subject: [PATCH] sched: Work around undefined behavior in sched class checking Date: Tue, 4 May 2021 20:39:45 -0700 Message-Id: <20210505033945.1282851-1-ak@linux.intel.com> X-Mailer: git-send-email 2.25.4 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Andi Kleen The scheduler initialization code checks that the scheduling classes are consecutive in memory by comparing the end addresses with the next address. Technically in ISO C comparing symbol addresseses outside different objects is undefined. With LTO gcc 10 tries to exploits this and creates an unconditional BUG_ON in the scheduler initialization, resulting in a boot hang. Use RELOC_HIDE to make this work. This hides the symbols from gcc, so the optimizer won't make these assumption. I also split the BUG_ONs in multiple. Signed-off-by: Andi Kleen --- kernel/sched/core.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 98191218d891..272a654f5293 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -8086,12 +8086,20 @@ void __init sched_init(void) unsigned long ptr = 0; int i; - /* Make sure the linker didn't screw up */ - BUG_ON(&idle_sched_class + 1 != &fair_sched_class || - &fair_sched_class + 1 != &rt_sched_class || - &rt_sched_class + 1 != &dl_sched_class); + /* + * Make sure the linker didn't screw up. + * We have to use RELOC_HIDE to prevent gcc from optimizing + * them to true because they're technically undefined in ISO-C. + */ + BUG_ON(RELOC_HIDE(&idle_sched_class, 0) + 1 != + RELOC_HIDE(&fair_sched_class, 0)); + BUG_ON(RELOC_HIDE(&fair_sched_class, 0) + 1 != + RELOC_HIDE(&rt_sched_class, 0)); + BUG_ON(RELOC_HIDE(&rt_sched_class, 0) + 1 != + RELOC_HIDE(&dl_sched_class, 0)); #ifdef CONFIG_SMP - BUG_ON(&dl_sched_class + 1 != &stop_sched_class); + BUG_ON(RELOC_HIDE(&dl_sched_class, 0) + 1 != + RELOC_HIDE(&stop_sched_class, 0)); #endif wait_bit_init(); -- 2.25.4