[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20251014222524.GA3575477@ax162>
Date: Tue, 14 Oct 2025 15:25:24 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: Peter Zijlstra <peterz@...radead.org>,
Bjorn Helgaas <helgaas@...nel.org>
Cc: Marek Vasut <marek.vasut+renesas@...il.com>,
Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
Lorenzo Pieralisi <lpieralisi@...nel.org>,
Krzysztof Wilczy??ski <kwilczynski@...nel.org>,
Manivannan Sadhasivam <mani@...nel.org>,
Rob Herring <robh@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>,
Geert Uytterhoeven <geert+renesas@...der.be>,
Magnus Damm <magnus.damm@...il.com>, Kees Cook <kees@...nel.org>,
linux-pci@...r.kernel.org, linux-renesas-soc@...r.kernel.org,
linux-kernel@...r.kernel.org, llvm@...ts.linux.dev,
kernel test robot <lkp@...el.com>
Subject: Re: [PATCH v2] PCI: rcar-host: Add OF Kconfig dependency to avoid
objtool no-cfi warning
On Tue, Oct 14, 2025 at 09:47:28PM +0200, Peter Zijlstra wrote:
> On Tue, Oct 14, 2025 at 02:13:30PM -0500, Bjorn Helgaas wrote:
>
> > Ugh. This might be the best solution, but it's a bit problematic
> > without a hint about why "depends on OF" is here. Theoretically there
> > are stubs for everything to make COMPILE_TEST work, so I think we're
> > about to drop all the dependencies on OF.
>
> Its those stubs are exactly the problem.
Yeah and I had thought about changing of_device_get_match_data() to use
something like ERR_PTR() in the !OF case but that does not fix the issue
since the call destination is still going to be invalid. To me, this is
just one of the sharp edges of compile testing: you give up some code or
configuration cleanliness/expectations for the flexibility of build
testing.
> > This dependency to avoid a no-cfi warning looks like the kind of thing
> > that could someday go away if the tools get smarter. Maybe we can add
> > a Kconfig comment here, but I don't really know enough to write one.
> > Something like this?
>
> Its not a CFI warning per-se, the compiler is hitting known UB
> (unconditional NULL deref) and is currently emitting a NULL pointer
> indirect call, but given how aggressive clang has been on encountering
> UB it might just stop code-gen entirely and generate fall-through
> warnings (been there done that).
>
> Smarter compiler here is only going to make this worse.
Yeah, we are lucky that this is all LLVM does with this code.
For what it's worth, there is plenty of "depends on OF" that appears
across the tree and I see exactly one instance that has a comment above
it (none with the comment on the same line). Perhaps these are all
historical if there was a point where stubs were not provided for !OF. I
do not mind adding a comment if really so desired but this driver does
not do anything without CONFIG_OF so it feels like the dependency is
natural anyways.
Cheers,
Nathan
Powered by blists - more mailing lists