Received: by 10.223.185.116 with SMTP id b49csp2130496wrg; Sun, 4 Mar 2018 19:21:23 -0800 (PST) X-Google-Smtp-Source: AG47ELuuqKpUO83lmj2lfnnhWlb2VnsrBlXGbkIywe8E6EuCUV5tfYrHvWe2Gm3O0yFTtTXsvaan X-Received: by 10.98.249.10 with SMTP id o10mr13828485pfh.222.1520220083108; Sun, 04 Mar 2018 19:21:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520220082; cv=none; d=google.com; s=arc-20160816; b=k4u45UU7p5m0g2amVnIn2BlLix1ToQP0LA7PXgffGWuXJFjdB8Ij06Q24gDzH9nkJr 9hvWqx9BaWD0o9sUuvT7ZmIFFePFylYLBOf8EAm2TNsXay4M25267V9bXgYAKKAYUYpe o+Gc1K3ENB0GYT9/sXc4WfC5h9b5tBOFSz4pKFcX/j/oLZgf1yi3mwwfo9XXvY2vv8QB a+q9IFspW9Q+KAj3vVALPfgzvrh3m7goU4u0AzIi7ISxamjiIEVbMabrjgN1tnFqQa+6 QOKURAduGG4bV/8Z82/ETthB2aL8u4RMvc0PFIf+USG7c81q7t8lGLuruRJD8T7UgIOA OkTg== 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:arc-authentication-results; bh=2YsgmYWp+S+dFq1/DQgC4HI6NGfJPa5g0NFuZOvNssg=; b=ZGlhnha0kwQLMbNjZzmpNZzqmpPqk/oong0FWV0OkAHewfXrlp43pjeSDM2yaHBev5 ja+sOXYcGFz5yA4IfI2CegiftKESpMFd0d1YYJOacu8yOTCFFndlq7oME4CXLAJ74RpE CtFQGZFAAVsB38GkkTWzL3xcBx5/6Xme+oKmo58pJmvqLwqF78Er3t7v9wIGGYtxedSZ gIp6N7iKNehcOpg7w+CdyqfHwlCen8gmTxlzOHsh5L+kgT3ry1BZF4nWr18Dd/bi9SdC pEgN2JvK5Xq0s9nQwDL2edPQOHUNtyKdhS6Fyhi4TrA1rDCBdHMuxEH33E1DTYCLYDrp mJng== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c23-v6si2136865pli.306.2018.03.04.19.21.08; Sun, 04 Mar 2018 19:21:22 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932564AbeCEDUQ (ORCPT + 99 others); Sun, 4 Mar 2018 22:20:16 -0500 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:54200 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932318AbeCEDUO (ORCPT ); Sun, 4 Mar 2018 22:20:14 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1C40D40FB648; Mon, 5 Mar 2018 03:20:14 +0000 (UTC) Received: from dhcp-128-65.nay.redhat.com (ovpn-12-71.pek2.redhat.com [10.72.12.71]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 978452024CA9; Mon, 5 Mar 2018 03:20:09 +0000 (UTC) Date: Mon, 5 Mar 2018 11:20:05 +0800 From: Dave Young To: Sergey Senozhatsky Cc: Petr Mladek , Tejun Heo , Stephen Rothwell , Linux-Next Mailing List , Linux Kernel Mailing List , Steven Rostedt , Sergey Senozhatsky , akpm@linux-foundation.org, Andi Kleen Subject: Re: linux-next: build failure after merge of the printk tree Message-ID: <20180305032005.GA4661@dhcp-128-65.nay.redhat.com> References: <20180302160732.12691fbc@canb.auug.org.au> <20180302155454.eme5gplxdcltvwkw@pathway.suse.cz> <20180303144739.GA516@tigerII.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180303144739.GA516@tigerII.localdomain> User-Agent: Mutt/1.9.1 (2017-09-22) X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Mon, 05 Mar 2018 03:20:14 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Mon, 05 Mar 2018 03:20:14 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'dyoung@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/03/18 at 11:47pm, Sergey Senozhatsky wrote: > 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? I would think b) is better, thanks for the fix! > > > ========= 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 > Thanks Dave