All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Chancellor <nathan@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	Ingo Molnar <mingo@kernel.org>, Kees Cook <kees@kernel.org>,
	kernel test robot <lkp@intel.com>
Subject: Re: [tip:x86/core 1/1] vmlinux.o: warning: objtool: rcar_pcie_probe+0x13e: no-cfi indirect call!
Date: Mon, 13 Oct 2025 11:30:59 -0700	[thread overview]
Message-ID: <20251013183059.GA690226@ax162> (raw)
In-Reply-To: <20251013082629.GH4067720@noisy.programming.kicks-ass.net>

On Mon, Oct 13, 2025 at 10:26:29AM +0200, Peter Zijlstra wrote:
> On Fri, Oct 10, 2025 at 03:30:12PM -0700, Nathan Chancellor wrote:
> > which does somewhat make sense because what's the point of setting up
> > the CFI call if you know nothing can actually make use of it since we
> > will crash when trying to indirectly call a NULL pointer?
> 
> As Sami says, it would be really nice if clang would at least WARN about
> emitting an unconditional NULL call like that. I mean, it *knows* its
> going to crash and burn at that point, right?

Yeah, I agree. It would have to happen after optimizations and the
infrastructure for reporting those instances back up to the frontend
is... not great IIRC but I will see if I can file something upstream.

Is there any way for objtool to detect these instances and emit a
slightly differently worded message? Figured it was worth asking ;)

> > Something like this would avoid this issue then.
> 
> Yes, this seems reasonable -- even if the driver should perhaps
> mandate/depend on CONFIG_OF, making sure to behave when NULL does get
> returned is definitely a good thing!.
> 
> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>

Thanks, I have sent this for review with your tag and Kees's:

https://lore.kernel.org/20251013-rcar_pcie_probe-avoid-nocfi-objtool-warning-v1-1-552876b94f04@kernel.org/

Cheers,
Nathan

  reply	other threads:[~2025-10-13 18:31 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-09 13:07 [tip:x86/core 1/1] vmlinux.o: warning: objtool: rcar_pcie_probe+0x13e: no-cfi indirect call! kernel test robot
2025-10-10  3:20 ` Nathan Chancellor
2025-10-10  7:10   ` Peter Zijlstra
2025-10-10  7:44     ` Peter Zijlstra
2025-10-10 22:30       ` Nathan Chancellor
2025-10-10 22:53         ` Kees Cook
2025-10-13  8:26         ` Peter Zijlstra
2025-10-13 18:30           ` Nathan Chancellor [this message]
2025-10-13 18:50             ` Peter Zijlstra
2025-10-13 20:08               ` Peter Zijlstra

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=20251013183059.GA690226@ax162 \
    --to=nathan@kernel.org \
    --cc=kees@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=llvm@lists.linux.dev \
    --cc=mingo@kernel.org \
    --cc=oe-kbuild-all@lists.linux.dev \
    --cc=peterz@infradead.org \
    --cc=x86@kernel.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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.