Received: by 10.223.185.116 with SMTP id b49csp2229216wrg; Sun, 4 Mar 2018 22:07:12 -0800 (PST) X-Google-Smtp-Source: AG47ELuGrLXVN+P2DgoSFWHrAhYO6DNcqJSPEgu/WCr02MHl0Z0AAMD0QdKvJHHghHEQEZ9pM+78 X-Received: by 2002:a17:902:5a1:: with SMTP id f30-v6mr5547774plf.124.1520230032850; Sun, 04 Mar 2018 22:07:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520230032; cv=none; d=google.com; s=arc-20160816; b=nlOwtALMeduh2x8UDCwT6bVAdpz66HNs/d8t5MVTNubOYM23Mk0Jgq4QlV+kn42cA6 NCQl82cre6QBHdslnQOYtaTMXPlfbRj076hs9u7OXqpB6yYkIpl7WaIX/R86sGSnBIgL WsPayzrkSMquq6tfbyAwIwE/cBoMXpdIb6k4VpQivZnvLqHgmLEuFqTuccvXCRU6rFF1 0xQ1McJNrVxWeLzOtf+JJcnm5dcyuXaio2Nrz3q+dwEeJ/iMc1fUp37lF+mID702ltwp Ae8iIUaxCCrxQBpwhfwFy2WExybgSkbLpP1lEnrT3hdIsFonMbbfeHZbWD77xKy8f/q3 AFZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=/G9+DuEeQYZ+iDd5h0aKRlNKy8QMp9xIKt/Lhlxm6kU=; b=mE4W5SRiwua3TYgVoa493nlm3ALSs26ZhsqS9OywicVxAg6hj/Sda9GsPginXu+ER7 2qQICqar53uTvVXszDUeN1/XwpQFwVn7W9tQy8NbeDBI35oqBEtaL1fASfu9q0bkxy67 hP0FDyzfToILH2+FDv+2X5YC+0FKllkzFacCFoUrjyPCX5pvDRUVp5fAtjaxLgqd/Gqn J8f4OlWnpKXlgwRtwzVNi74eqA9I68198unSpPzu39V+GXilYVIjAAepiPD1sgnYK75L CMcMMxoNyn6j4bL9i41KA/uZAJZXgMj5KWPjEIAugHdGrf3ywZ3Lv/jiJfrnN/mIW93Y RILQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=UaydHNBV; 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 d37-v6si8832720plb.231.2018.03.04.22.06.56; Sun, 04 Mar 2018 22:07:12 -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=UaydHNBV; 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 S932758AbeCEF2c (ORCPT + 99 others); Mon, 5 Mar 2018 00:28:32 -0500 Received: from mail-vk0-f65.google.com ([209.85.213.65]:46648 "EHLO mail-vk0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932512AbeCEF2a (ORCPT ); Mon, 5 Mar 2018 00:28:30 -0500 Received: by mail-vk0-f65.google.com with SMTP id x125so9027601vkc.13; Sun, 04 Mar 2018 21:28:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/G9+DuEeQYZ+iDd5h0aKRlNKy8QMp9xIKt/Lhlxm6kU=; b=UaydHNBVvJxPPDJjxGMWoXB7hdS6qumO0SRIZIQVnJCZa1S/B9ZemxHndXL4ILjDIz uEs/+wq4mz2KicfB/i4kL4szB9tCmqtgHpkWuVZwToZwPGik0wF8TDX83t9my8n6IhbY QhWPvLhQLilwMDi1IhfhO0vnvQD4pIzGVWpGWFPOoQ/IiwmjGqYRCKIa8HeTbeIiyKSq nGrnldkYewaLQ2gVe7qs8fceHmd3hp8DvhDNPNRn4zc9WJfnrl6KmJSASFHlgO9GKmUM wROWzhW+4Z/cjJcGz41ABdw4VhUCFHtPYUsb4McS1Rw35Bx/PUNdPiMkbXXgGa5+iF4O KQdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/G9+DuEeQYZ+iDd5h0aKRlNKy8QMp9xIKt/Lhlxm6kU=; b=F2xoyQglY1gXPR2wZfXdD5DufyGVmpdAelacGLYqlMEHjrjxFYTW8PLVC0SQVdhsmK VClXO5t103g5q8rvxa2BDxy3y4bNqalZNecTpkCgouayOUVEeCovi42THQDmnX57zPx5 IYZm5miOM2vynQQ1wvkJ7Dvs2wXPzMJQOa2WLjc4PBofrKGZkOaqP7IREqz0WEOCMnUA AKbAAwR2xguSdwvyP+DmA3OmHOCCp88hVbZgzPz0NB4KwDrE5EYt7gGWVqQTLLqX2aar +YTdeYgLZnZEhK2KtHuzWODNugJ4r8oquZWhoueT4KPeFsj7Pu2ubpW+RqU9A5bpcLTo N3BA== X-Gm-Message-State: APf1xPANP8pOvdhwV+mw7QDlFDp+Cty5ueeh1r1WUQCvCz/saJa1FwZ/ mZlGQOBc1ndnCKrDVupr6mWPTucW0fPauA29A3I= X-Received: by 10.31.106.133 with SMTP id f127mr8910027vkc.94.1520227709043; Sun, 04 Mar 2018 21:28:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.49.66 with HTTP; Sun, 4 Mar 2018 21:27:48 -0800 (PST) In-Reply-To: <20180305032005.GA4661@dhcp-128-65.nay.redhat.com> References: <20180302160732.12691fbc@canb.auug.org.au> <20180302155454.eme5gplxdcltvwkw@pathway.suse.cz> <20180303144739.GA516@tigerII.localdomain> <20180305032005.GA4661@dhcp-128-65.nay.redhat.com> From: Greentime Hu Date: Mon, 5 Mar 2018 13:27:48 +0800 Message-ID: Subject: Re: linux-next: build failure after merge of the printk tree To: Dave Young Cc: Sergey Senozhatsky , Petr Mladek , Tejun Heo , Stephen Rothwell , Linux-Next Mailing List , Linux Kernel Mailing List , Steven Rostedt , Sergey Senozhatsky , akpm@linux-foundation.org, Andi Kleen Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2018-03-05 11:20 GMT+08:00 Dave Young : > 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! > Hi, b works in nds32. 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