Received: by 10.223.185.116 with SMTP id b49csp753926wrg; Sat, 3 Mar 2018 06:49:09 -0800 (PST) X-Google-Smtp-Source: AG47ELugJB9EtsFiGNDdSJ96IgLfGYxMYypoXdIWAvp0A3TXOOFVfgqF/Lm+PJC1TDtzStzGQX6E X-Received: by 2002:a17:902:b101:: with SMTP id q1-v6mr8335022plr.287.1520088549283; Sat, 03 Mar 2018 06:49:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520088549; cv=none; d=google.com; s=arc-20160816; b=RlmAS8WWIPTrc0VseKeOTNJyy6Vet5XuxZ1jtjEk0K6wEPMg1egSQjZHnGEC27aDwK qdRx2C+WyKz6ut5R38Qcmk7l1C2pPR7g1cYIMwYeSQJ8sZGmrFi/RRL5yd2QnKl2uxgY YmdVIMGI4vXnCRVsZY+CodMAWyZg8M259wIYyVxDMlkwwYIYdhP16g4NX6OGb333w25g q/6KXC3ch7jKrNySYyCHm+aDBnWgWJxkDW1SBIPAyKpTbVwqLv8MH4ZbI4TkAgTyiy6B YZj0vZRt4qSrHpTtsL4N4buTfM9V8ryZzEzFqNNxpEHcxnzunxhwT2Fc2wj0Ubxsl7Jl SUGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=KnQGir1ktOsbBcxSDF72y6OUawAxgQr51n+GKzwQyc4=; b=tEADmrDYvCMwfNc8sveCNYYDyi92VPJueA0Z42eEEh5N1f1z6kwcwDle05JANPJ2Cq v+YURocAuZPNppjlre7tTmS1rJAde20hX16avN5RNtH2a8W+tlg6DiQnfNt3iJD1UMnI Jkphvih7q4jBriI8KsNqnxi3/BaLclZ96+esBPtiIDaLh6kUdW//cMyuIuE651bdmW6j l1G6ssso5tNO3cF1m6RwYyvcwRRAUBhMZDvbLxbIFfg7qw0Chkq4T/VH43iDiWKG1rAS 4oKmJwWMp82N9O6XvEcXNLuJFpq+Cb8FxAHka/6Te1fq29MtMzqkOSZ0Elv+JEy8BGTd n3uA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=fzS+B1of; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y16-v6si5037663plr.424.2018.03.03.06.48.40; Sat, 03 Mar 2018 06:49:09 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=fzS+B1of; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752076AbeCCOrp (ORCPT + 99 others); Sat, 3 Mar 2018 09:47:45 -0500 Received: from mail-pf0-f193.google.com ([209.85.192.193]:44238 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751885AbeCCOrn (ORCPT ); Sat, 3 Mar 2018 09:47:43 -0500 Received: by mail-pf0-f193.google.com with SMTP id 17so5266839pfw.11; Sat, 03 Mar 2018 06:47:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=KnQGir1ktOsbBcxSDF72y6OUawAxgQr51n+GKzwQyc4=; b=fzS+B1of4Crr8n9bbGwr9VGR6EIQqF6LhruQxYf6WLMxUCwRdzI80k0p6Mkp6mWys6 sefoM7GP0xJYIQC7I+Te7ZrHTjh44/IVkgG4ZZvqvUe0Hm5+riUJP+KTa1MBYkTZKLnr lsyNMFy1wNWMieuOl59mTmNf032bhTeVEAAh0k77Z82rnxRGlGLSVxLDHiadfTlO9GnJ /8CozsTI/EmlrHGmFXf6xc4EaXQJgdOsst4UkSWoC+Pr5hHZDC89Mz8h9kCrMoFaRuoe u6cOK4mmUWBbQcbUggl3Z2nFy1Tfx/OXwG8KAv6QuicljXsnCweN7qFfcd6pHnAXGvtZ /uaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=KnQGir1ktOsbBcxSDF72y6OUawAxgQr51n+GKzwQyc4=; b=k7jEsUgW/LvVbZ/iF3vZTYGEBUTohgqZcBpIcxNhRHBtnjmu4qYv3FCaFY/BXtqXhM EzTE8fAoeFHbbebOELSIrOE9F7nxCwAx1T+LdmNaf2djV6I1LkraujeTy2J2bKcZg3ZO wLD8P65uGSEc5xd0P+PxP95RufGV4bNufzL/rxUb9xLPathG8/+o9ckV5yKTJQVs8vh9 eYXFl24YWKiRxiYf95AyIJOFtoEWv9/Gnt52A9yRRdckaaA4cWDBz3Wm9iCEtNP8T/Hk kY02uSjPeRYRiSVohi7i+Si4APf8R0x6+qGlykBt9naiCBb0BRb8ZS4VIYGy9I5jWd5h oVLQ== X-Gm-Message-State: APf1xPAvt4UMoPvw0y/4mewNKEMjoU7nFjR44+8ZCzxKRVSBTp1aS5PT WZknCiBh7VYk4kTNiB9lq8I= X-Received: by 10.98.63.75 with SMTP id m72mr9377201pfa.122.1520088463090; Sat, 03 Mar 2018 06:47:43 -0800 (PST) Received: from localhost ([183.98.136.252]) by smtp.gmail.com with ESMTPSA id c18sm18553047pfd.100.2018.03.03.06.47.41 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 03 Mar 2018 06:47:41 -0800 (PST) Date: Sat, 3 Mar 2018 23:47:39 +0900 From: Sergey Senozhatsky To: Petr Mladek , Tejun Heo Cc: Stephen Rothwell , Linux-Next Mailing List , Linux Kernel Mailing List , Dave Young , Steven Rostedt , Sergey Senozhatsky , akpm@linux-foundation.org, Andi Kleen Subject: Re: linux-next: build failure after merge of the printk tree Message-ID: <20180303144739.GA516@tigerII.localdomain> References: <20180302160732.12691fbc@canb.auug.org.au> <20180302155454.eme5gplxdcltvwkw@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180302155454.eme5gplxdcltvwkw@pathway.suse.cz> User-Agent: Mutt/1.9.3 (2018-01-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Cc-ing Tejun On (03/02/18 16:54), Petr Mladek wrote: [..] > > (Though it is not immediately obvious why.) > > It is a mistery to me. The error appears when I move any of > dump_stack_print_info() or show_regs_print_info() function > definitions from kernel/printk/printk.c to lib/dump_stack.c. > All the other changes seems unrelated. > > The thing is that we basically do not touch dump_stack() definition > by that patch. Apparently dump_stack_print_info() was in lib/dump_stack.c a long time ago, but it was deliberately moved to printk.c, when kernel gained a "generic" (dummy) dump_stack() fallback. Some archs, like blackfin, define their own dump_stack() symbol and make it global via EXPORT_SYMBOL. In case of blackfin that arch-specific dump_stack() symbol invokes a global dump_stack_print_info(). If we move dump_stack_print_info() back to lib/dump_stack.c then we link both with arch/blackfin/dumpstack.o and lib/dump_stack.o, which results in multiple definitions error. If we move dump_stack_print_info() out on libdump_stack.o, then we never link with lib/dump_stack.o ... so what are we going to do with that. a) we can drop the patch and cherry pick only the kexec part b) we can try to mark dummy lib/dump_stack() as __weak EXPORT_SYMBOL and remove EXPORT_SYMBOL from arch-specific definitions. So we will end up with EXPORT_SYMBOL dump_stack() and archs may re-define it. If some arch will accidentally mark its own dump_stack() as EXPORT_SYMBOL then there should be a linkage warning - a symbol is exported twice. Something like below. Opinions? Will this work? ========= 8< ========= From: Sergey Senozhatsky Subject: [PATCH] dump_stack: mark dummy dump_stack() as weak --- arch/blackfin/kernel/dumpstack.c | 1 - arch/nds32/kernel/traps.c | 2 -- lib/dump_stack.c | 4 ++-- 3 files changed, 2 insertions(+), 5 deletions(-) diff --git a/arch/blackfin/kernel/dumpstack.c b/arch/blackfin/kernel/dumpstack.c index 3c992c1f8ef2..61af017130cd 100644 --- a/arch/blackfin/kernel/dumpstack.c +++ b/arch/blackfin/kernel/dumpstack.c @@ -174,4 +174,3 @@ void dump_stack(void) show_stack(current, &stack); trace_buffer_restore(tflags); } -EXPORT_SYMBOL(dump_stack); diff --git a/arch/nds32/kernel/traps.c b/arch/nds32/kernel/traps.c index 8828b4aeb72b..455bb0787367 100644 --- a/arch/nds32/kernel/traps.c +++ b/arch/nds32/kernel/traps.c @@ -166,8 +166,6 @@ void dump_stack(void) __dump(NULL, base_reg); } -EXPORT_SYMBOL(dump_stack); - void show_stack(struct task_struct *tsk, unsigned long *sp) { unsigned long *base_reg; diff --git a/lib/dump_stack.c b/lib/dump_stack.c index 5cff72f18c4a..9cf4465dbffa 100644 --- a/lib/dump_stack.c +++ b/lib/dump_stack.c @@ -85,7 +85,7 @@ static void __dump_stack(void) #ifdef CONFIG_SMP static atomic_t dump_lock = ATOMIC_INIT(-1); -asmlinkage __visible void dump_stack(void) +asmlinkage __weak __visible void dump_stack(void) { unsigned long flags; int was_locked; @@ -118,7 +118,7 @@ asmlinkage __visible void dump_stack(void) local_irq_restore(flags); } #else -asmlinkage __visible void dump_stack(void) +asmlinkage __weak __visible void dump_stack(void) { __dump_stack(); } -- 2.16.2