Message ID | cb5dab6038dfe5156f5d68424cf372f7eed1b934.1680912057.git.jpoimboe@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp597013vqo; Fri, 7 Apr 2023 17:23:37 -0700 (PDT) X-Google-Smtp-Source: AKy350bbstliVxkusIMdwjKqO93d42Rs3JeFRfKBGdDfRIrlChBYbhhiEvka2zcUbIwxa2LsqDtb X-Received: by 2002:aa7:9a48:0:b0:623:c117:f20e with SMTP id x8-20020aa79a48000000b00623c117f20emr3903828pfj.19.1680913416810; Fri, 07 Apr 2023 17:23:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680913416; cv=none; d=google.com; s=arc-20160816; b=o/aaDDvD800fjvdvZ4gjKcf+YLgPwx59WQkbFv4DmJRooL6x1vTd8tCPw4xVVVwUqy 0er6OxtLPsJbWK1a43mwrwUxstVATxCGxlXD6Nt73NZGzn5z+jOZ2bb7KLfC+XK1xPU0 xoTHZPCCxDBuWCoWzDB0h04uv9uWXg1uLs68ESeuXeY/VHu/evAdrDDuLV9yRL0Cm/kf UXDW7f/MB3YNSwC+CzcHnOeHvF0h9Rh/LrqPsDCHMkwTyU4046sx7EbDgJ+8E++U6Bvx 7rmhymuBLr2ya/FnzTL5L5gysdgPAfjG9ZWhubowFd0sxcabMZu9Derh3bj6YvJqy8Kv j32w== 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 :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=jWBaAD0CA4D1UVZU9FAJXlLOsGCDAnNZE/etecq3qOM=; b=X28Nh0E1zkSAApaG2JtM/rJ2aofDjqxw/LLpqPuKGcTkSXjCcUk6h74y17FkNoDdig fDqOMnDGFggU3N44iTZlvsNF1pUlxtofREWjIigSf216hWtLFBWVwAggoLV6RoTmPFTB 5BxpcOU12yQFMzhMWcH7dspORRIju9XZy1lSY4DJrAGzHqLV+jv6FpK+bm/ywUcBQ1gt /GbzFssXH2iT6EfuPCMyqAjG0bQFxciwe1XxaniZl6N6tzij602OkMI2CM2Q2YiY3wfp pCyWEvUcIxQ+m4WX1sqbdNhI/wKa07Isezqd4Dt0+wnqIZxSUgUCq6b4yTbz1tEYOQMa 0NBw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=FdWdkv0H; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h13-20020a056a00000d00b0062dd27d7c36si4792343pfk.132.2023.04.07.17.23.24; Fri, 07 Apr 2023 17:23:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=FdWdkv0H; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230116AbjDHAK1 (ORCPT <rfc822;a1648639935@gmail.com> + 99 others); Fri, 7 Apr 2023 20:10:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60024 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229665AbjDHAKU (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 7 Apr 2023 20:10:20 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CD2271206D; Fri, 7 Apr 2023 17:10:19 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 5C50F654D0; Sat, 8 Apr 2023 00:10:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 55A3BC433EF; Sat, 8 Apr 2023 00:10:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1680912618; bh=fL3vAWc8aFXEM7bh/5Oz9xwxKse3WRA1+kRJbl4ypFI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FdWdkv0H/8KsW4Q4vTQq9Ak2p8LHjLTEeVWOmVAitqZmBAn3oZHk1jn5FA6zYYQYT 9z/RSqugv05WyKppeQNTONIlyFQXp5fM7uw/ivKhJBZgO+sNWdDgQ5kw/6qNwVk0IV 9iBYiuejuI8nW6PCikzTTtIq8ytq7F2to4idl//bFYM1PpeFBw/VCXDjcahEiQTK6Y DEHViKpq4ND5K7s+XrE/H8ZK79vWPY8Yc6VIp+lHVV0EvSDytXwe7kGNppQ9xAJTJM RmSmmPD4YHsTtc5d7KsA85Zx9LaieVkS40BT0CqJ7XcH+bEsEq9RCIdpb5k4thvZNq 0UN/474VUuXQQ== From: Josh Poimboeuf <jpoimboe@kernel.org> To: x86@kernel.org Cc: linux-kernel@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>, Miroslav Benes <mbenes@suse.cz>, linux-btrfs@vger.kernel.org, Mark Rutland <mark.rutland@arm.com>, linux-scsi@vger.kernel.org, linux-hyperv@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>, "Guilherme G . Piccoli" <gpiccoli@igalia.com>, Michael Kelley <mikelley@microsoft.com>, kernel test robot <lkp@intel.com> Subject: [PATCH 02/11] init: Mark start_kernel() __noreturn Date: Fri, 7 Apr 2023 17:09:55 -0700 Message-Id: <cb5dab6038dfe5156f5d68424cf372f7eed1b934.1680912057.git.jpoimboe@kernel.org> X-Mailer: git-send-email 2.39.2 In-Reply-To: <cover.1680912057.git.jpoimboe@kernel.org> References: <cover.1680912057.git.jpoimboe@kernel.org> MIME-Version: 1.0 Content-type: text/plain Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI,SPF_HELO_NONE, SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1762565467197344352?= X-GMAIL-MSGID: =?utf-8?q?1762565467197344352?= |
Series |
Sprinkle more __noreturn
|
|
Commit Message
Josh Poimboeuf
April 8, 2023, 12:09 a.m. UTC
Fixes the following warning:
vmlinux.o: warning: objtool: x86_64_start_reservations+0x28: unreachable instruction
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/202302161142.K3ziREaj-lkp@intel.com/
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
include/linux/start_kernel.h | 2 +-
init/main.c | 2 +-
tools/objtool/check.c | 1 +
3 files changed, 3 insertions(+), 2 deletions(-)
Comments
On Fri, Apr 07, 2023 at 05:09:55PM -0700, Josh Poimboeuf wrote: > Fixes the following warning: > > vmlinux.o: warning: objtool: x86_64_start_reservations+0x28: unreachable instruction > > Reported-by: kernel test robot <lkp@intel.com> > Link: https://lore.kernel.org/r/202302161142.K3ziREaj-lkp@intel.com/ > Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Ah, I just realized that my series will conflict with this. https://lore.kernel.org/llvm/20230412-no_stackp-v1-1-46a69b507a4b@google.com/ Perhaps if my series gets positive feedback; I can rebase it on top of this and it can become part of your series? For this patch, Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Though I'm curious, it does look like it's necessary because of 01/11 in the series? Any idea how the 0day bot report happened before 1/11 existed? (Surely gcc isn't assuming a weak function is implicitly noreturn and make optimizations based on that (that's one hazard I'm worried about)?) It looks like perhaps the link to https://lore.kernel.org/all/202302161142.K3ziREaj-lkp@intel.com/ on 2/11 was 0day testing the arch-cpu-idle-dead-noreturn branch of your kernel tree https://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git/log/?h=arch-cpu-idle-dead-noreturn , which had 1/11 in it, IIUC? Perhaps this link should go on 1/11 rather than 2/11? Looking back at 1/11, 3/11, 8/11 I noticed not all patches have links to 0day reports. Are you able to flesh out more info how/what/when such objtool warnings are observed? Are the warnings ever results of patches earlier in the series?
On Wed, Apr 12, 2023 at 01:29:49PM -0700, Nick Desaulniers wrote: > On Fri, Apr 07, 2023 at 05:09:55PM -0700, Josh Poimboeuf wrote: > > Fixes the following warning: > > > > vmlinux.o: warning: objtool: x86_64_start_reservations+0x28: unreachable instruction > > > > Reported-by: kernel test robot <lkp@intel.com> > > Link: https://lore.kernel.org/r/202302161142.K3ziREaj-lkp@intel.com/ > > Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> > > Ah, I just realized that my series will conflict with this. > https://lore.kernel.org/llvm/20230412-no_stackp-v1-1-46a69b507a4b@google.com/ > Perhaps if my series gets positive feedback; I can rebase it on top of > this and it can become part of your series? Sure, I can take these on top. > For this patch, > Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Thanks! > Though I'm curious, it does look like it's necessary because of 01/11 in > the series? Any idea how the 0day bot report happened before 1/11 > existed? > > > (Surely gcc isn't assuming a weak function is implicitly noreturn and > make optimizations based on that (that's one hazard I'm worried about)?) As far as I can tell, GCC has been doing the right thing here, and it's instead been objtool getting confused by weak noreturns. That gets fixed later in patch 9. > It looks like perhaps the link to > https://lore.kernel.org/all/202302161142.K3ziREaj-lkp@intel.com/ > on 2/11 was 0day testing the arch-cpu-idle-dead-noreturn branch of your > kernel tree > https://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git/log/?h=arch-cpu-idle-dead-noreturn > , which had 1/11 in it, IIUC? Perhaps this link should go on 1/11 > rather than 2/11? Good catch, patch 1 does introduce the warning. I think I'll just squash patches 1 and 2 so as not to break bisection. > Looking back at 1/11, 3/11, 8/11 I noticed not all patches have links to 0day > reports. Are you able to flesh out more info how/what/when such objtool > warnings are observed? Are the warnings ever results of patches earlier > in the series? Hopefully not, it's best to not introduce warnings even temporarily. I was doing a lot of build testing at the time with various branches, so it's possible. I'll see if I can figure out how I triggered those warnings and document that in the commit logs if possible.
On Wed, Apr 12, 2023 at 02:57:57PM -0700, Josh Poimboeuf wrote: > > It looks like perhaps the link to > > https://lore.kernel.org/all/202302161142.K3ziREaj-lkp@intel.com/ > > on 2/11 was 0day testing the arch-cpu-idle-dead-noreturn branch of your > > kernel tree > > https://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git/log/?h=arch-cpu-idle-dead-noreturn > > , which had 1/11 in it, IIUC? Perhaps this link should go on 1/11 > > rather than 2/11? > > Good catch, patch 1 does introduce the warning. I think I'll just > squash patches 1 and 2 so as not to break bisection. > > > Looking back at 1/11, 3/11, 8/11 I noticed not all patches have links to 0day > > reports. Are you able to flesh out more info how/what/when such objtool > > warnings are observed? Are the warnings ever results of patches earlier > > in the series? > > Hopefully not, it's best to not introduce warnings even temporarily. I > was doing a lot of build testing at the time with various branches, so > it's possible. I'll see if I can figure out how I triggered those > warnings and document that in the commit logs if possible. On second thought I won't squash, keeping them separate is useful for both patches 1 & 2 and patches 5-7. The patch order goes up the call stack, i.e. fix callees before callers. The opposite order would trigger actual compiler warnings rather than measly objtool warnings :-) I agree some of the commit logs are indeed confusing and sometimes even wrong. I'll clarify the justifications, and remove references to build bot warnings if they apply to previous patches in the set.
diff --git a/include/linux/start_kernel.h b/include/linux/start_kernel.h index 864921e54c92..a9806a44a605 100644 --- a/include/linux/start_kernel.h +++ b/include/linux/start_kernel.h @@ -8,7 +8,7 @@ /* Define the prototype for start_kernel here, rather than cluttering up something else. */ -extern asmlinkage void __init start_kernel(void); +extern asmlinkage void __init __noreturn start_kernel(void); extern void __init __noreturn arch_call_rest_init(void); extern void __ref __noreturn rest_init(void); diff --git a/init/main.c b/init/main.c index 161ed956d738..65aab4e9bb49 100644 --- a/init/main.c +++ b/init/main.c @@ -937,7 +937,7 @@ static void __init print_unknown_bootoptions(void) memblock_free(unknown_options, len); } -asmlinkage __visible void __init __no_sanitize_address start_kernel(void) +asmlinkage __visible void __init __no_sanitize_address __noreturn start_kernel(void) { char *command_line; char *after_dashes; diff --git a/tools/objtool/check.c b/tools/objtool/check.c index e7442e7ad676..a6f9a4aeb77b 100644 --- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -222,6 +222,7 @@ static bool __dead_end_function(struct objtool_file *file, struct symbol *func, "rewind_stack_and_make_dead", "sev_es_terminate", "snp_abort", + "start_kernel", "stop_this_cpu", "usercopy_abort", "xen_cpu_bringup_again",