From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E1D92C2D0DB for ; Thu, 30 Jan 2020 18:50:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B4F8C2082E for ; Thu, 30 Jan 2020 18:50:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1580410254; bh=2BhG2UfRcRv4KkAOEGoXmpxxPK5f9ImHCleRROl0MyA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=1DQgV6945/KlYQQkveguAni8RcZyLQV71b27XrhRQu4qxBNgNHbLo+7p0Nwy38w7E iY73JY0sTHXs5yFUPTz1iWZYdjNaRbYSav6nJNppyMR5RyGVKys0z15Q4JWEuj3PRJ zQv/z/DWChbeAFbAk2mZz1tiiqaGlDizc+H5kVAs= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731566AbgA3Sux (ORCPT ); Thu, 30 Jan 2020 13:50:53 -0500 Received: from mail.kernel.org ([198.145.29.99]:56244 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731177AbgA3SqT (ORCPT ); Thu, 30 Jan 2020 13:46:19 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0D31A20CC7; Thu, 30 Jan 2020 18:46:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1580409978; bh=2BhG2UfRcRv4KkAOEGoXmpxxPK5f9ImHCleRROl0MyA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tY4T7k1vAEHIX4qG7rDbuuTYetdKpbIkSPx5h32PnF7iojjpV9fNu86uKkqoeEO5w zeK3+Y1IB34nWr181pqekqMBFdQEcJ7dmSNUlgtLhyziDwqERgAkdfBJVTtXBP2ZUQ AsuZ5CNGN+f5buN+jFRf3tl/q+2dYaE62ob2uNDY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Anton Ivanov , Johannes Berg , Anton Ivanov , Richard Weinberger Subject: [PATCH 5.4 109/110] Revert "um: Enable CONFIG_CONSTRUCTORS" Date: Thu, 30 Jan 2020 19:39:25 +0100 Message-Id: <20200130183626.212910444@linuxfoundation.org> X-Mailer: git-send-email 2.25.0 In-Reply-To: <20200130183613.810054545@linuxfoundation.org> References: <20200130183613.810054545@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Johannes Berg commit 87c9366e17259040a9118e06b6dc8de986e5d3d1 upstream. This reverts commit 786b2384bf1c ("um: Enable CONFIG_CONSTRUCTORS"). There are two issues with this commit, uncovered by Anton in tests on some (Debian) systems: 1) I completely forgot to call any constructors if CONFIG_CONSTRUCTORS isn't set. Don't recall now if it just wasn't needed on my system, or if I never tested this case. 2) With that fixed, it works - with CONFIG_CONSTRUCTORS *unset*. If I set CONFIG_CONSTRUCTORS, it fails again, which isn't totally unexpected since whatever wanted to run is likely to have to run before the kernel init etc. that calls the constructors in this case. Basically, some constructors that gcc emits (libc has?) need to run very early during init; the failure mode otherwise was that the ptrace fork test already failed: ---------------------- $ ./linux mem=512M Core dump limits : soft - 0 hard - NONE Checking that ptrace can change system call numbers...check_ptrace : child exited with exitcode 6, while expecting 0; status 0x67f Aborted ---------------------- Thinking more about this, it's clear that we simply cannot support CONFIG_CONSTRUCTORS in UML. All the cases we need now (gcov, kasan) involve not use of the __attribute__((constructor)), but instead some constructor code/entry generated by gcc. Therefore, we cannot distinguish between kernel constructors and system constructors. Thus, revert this commit. Cc: stable@vger.kernel.org [5.4+] Fixes: 786b2384bf1c ("um: Enable CONFIG_CONSTRUCTORS") Reported-by: Anton Ivanov Signed-off-by: Johannes Berg Acked-by: Anton Ivanov Signed-off-by: Greg Kroah-Hartman Signed-off-by: Richard Weinberger --- arch/um/include/asm/common.lds.S | 2 +- arch/um/kernel/dyn.lds.S | 1 + init/Kconfig | 1 + kernel/gcov/Kconfig | 2 +- 4 files changed, 4 insertions(+), 2 deletions(-) --- a/arch/um/include/asm/common.lds.S +++ b/arch/um/include/asm/common.lds.S @@ -83,8 +83,8 @@ __preinit_array_end = .; } .init_array : { - /* dummy - we call this ourselves */ __init_array_start = .; + *(.init_array) __init_array_end = .; } .fini_array : { --- a/arch/um/kernel/dyn.lds.S +++ b/arch/um/kernel/dyn.lds.S @@ -103,6 +103,7 @@ SECTIONS be empty, which isn't pretty. */ . = ALIGN(32 / 8); .preinit_array : { *(.preinit_array) } + .init_array : { *(.init_array) } .fini_array : { *(.fini_array) } .data : { INIT_TASK_DATA(KERNEL_STACK_SIZE) --- a/init/Kconfig +++ b/init/Kconfig @@ -54,6 +54,7 @@ config CC_DISABLE_WARN_MAYBE_UNINITIALIZ config CONSTRUCTORS bool + depends on !UML config IRQ_WORK bool --- a/kernel/gcov/Kconfig +++ b/kernel/gcov/Kconfig @@ -4,7 +4,7 @@ menu "GCOV-based kernel profiling" config GCOV_KERNEL bool "Enable gcov-based kernel profiling" depends on DEBUG_FS - select CONSTRUCTORS + select CONSTRUCTORS if !UML default n ---help--- This option enables gcov-based code profiling (e.g. for code coverage