LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: tip-bot for Josh Poimboeuf <tipbot@zytor.com> To: linux-tip-commits@vger.kernel.org Cc: tglx@linutronix.de, torvalds@linux-foundation.org, mingo@kernel.org, rdunlap@infradead.org, hpa@zytor.com, damian.tometzki@icloud.com, David.Laight@ACULAB.COM, arnd@arndb.de, peterz@infradead.org, linux-kernel@vger.kernel.org, jpoimboe@redhat.com, gregkh@linuxfoundation.org Subject: [tip:core/urgent] objtool: Fix "noreturn" detection for recursive sibling calls Date: Mon, 14 May 2018 05:37:19 -0700 [thread overview] Message-ID: <tip-0afd0d9e0e7879d666c1df2fa1bea4d8716909fe@git.kernel.org> (raw) In-Reply-To: <7cc156408c5781a1f62085d352ced1fe39fe2f91.1525923412.git.jpoimboe@redhat.com> Commit-ID: 0afd0d9e0e7879d666c1df2fa1bea4d8716909fe Gitweb: https://git.kernel.org/tip/0afd0d9e0e7879d666c1df2fa1bea4d8716909fe Author: Josh Poimboeuf <jpoimboe@redhat.com> AuthorDate: Wed, 9 May 2018 22:39:14 -0500 Committer: Ingo Molnar <mingo@kernel.org> CommitDate: Mon, 14 May 2018 10:20:53 +0200 objtool: Fix "noreturn" detection for recursive sibling calls Objtool has some crude logic for detecting static "noreturn" functions (aka "dead ends"). This is necessary for being able to correctly follow GCC code flow when such functions are called. It's remotely possible for two functions to call each other via sibling calls. If they don't have RET instructions, objtool's noreturn detection logic goes into a recursive loop: drivers/char/ipmi/ipmi_ssif.o: warning: objtool: return_hosed_msg()+0x0: infinite recursion (objtool bug!) drivers/char/ipmi/ipmi_ssif.o: warning: objtool: deliver_recv_msg()+0x0: infinite recursion (objtool bug!) Instead of reporting an error in this case, consider the functions to be non-dead-ends. Reported-and-tested-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: David Laight <David.Laight@ACULAB.COM> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: damian <damian.tometzki@icloud.com> Link: http://lkml.kernel.org/r/7cc156408c5781a1f62085d352ced1fe39fe2f91.1525923412.git.jpoimboe@redhat.com Signed-off-by: Ingo Molnar <mingo@kernel.org> --- tools/objtool/check.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/tools/objtool/check.c b/tools/objtool/check.c index 5409f6f6c48d..264522d4e4af 100644 --- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -190,9 +190,13 @@ static int __dead_end_function(struct objtool_file *file, struct symbol *func, continue; if (recursion == 5) { - WARN_FUNC("infinite recursion (objtool bug!)", - dest->sec, dest->offset); - return -1; + /* + * Infinite recursion: two functions + * have sibling calls to each other. + * This is a very rare case. It means + * they aren't dead ends. + */ + return 0; } return __dead_end_function(file, dest_func,
next prev parent reply other threads:[~2018-05-14 12:37 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-05-10 3:39 [PATCH 0/3] objtool: GCC 8 support Josh Poimboeuf 2018-05-10 3:39 ` [PATCH 1/3] objtool: Fix "noreturn" detection for recursive sibling calls Josh Poimboeuf 2018-05-14 12:37 ` tip-bot for Josh Poimboeuf [this message] 2018-05-10 3:39 ` [PATCH 2/3] objtool: Support GCC 8 cold subfunctions Josh Poimboeuf 2018-05-14 12:37 ` [tip:core/urgent] objtool: Support GCC 8's " tip-bot for Josh Poimboeuf 2018-05-10 3:39 ` [PATCH 3/3] objtool: Support GCC 8 switch tables Josh Poimboeuf 2018-05-10 8:41 ` Peter Zijlstra 2018-05-10 12:44 ` [PATCH v1.1 " Josh Poimboeuf 2018-05-10 14:07 ` Peter Zijlstra 2018-05-10 22:45 ` [PATCH v1.2 " Josh Poimboeuf 2018-05-10 22:48 ` [PATCH v1.3 " Josh Poimboeuf 2018-05-14 12:38 ` [tip:core/urgent] " tip-bot for Josh Poimboeuf
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=tip-0afd0d9e0e7879d666c1df2fa1bea4d8716909fe@git.kernel.org \ --to=tipbot@zytor.com \ --cc=David.Laight@ACULAB.COM \ --cc=arnd@arndb.de \ --cc=damian.tometzki@icloud.com \ --cc=gregkh@linuxfoundation.org \ --cc=hpa@zytor.com \ --cc=jpoimboe@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-tip-commits@vger.kernel.org \ --cc=mingo@kernel.org \ --cc=peterz@infradead.org \ --cc=rdunlap@infradead.org \ --cc=tglx@linutronix.de \ --cc=torvalds@linux-foundation.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).