On Fri, Jul 25, 2025 at 09:38:51AM -0700, Nathan Chancellor wrote:
On Fri, Jul 25, 2025 at 10:58:05AM +0200, Greg KH wrote:
On Thu, Jul 24, 2025 at 06:15:28PM -0700, Justin Stitt wrote:
A new warning in Clang 22 [1] complains that @clidr passed to get_clidr_el1() is an uninitialized const pointer. get_clidr_el1() doesn't really care since it casts away the const-ness anyways.
Is clang-22 somehow now a supported kernel for the 6.1.y tree? Last I looked, Linus's tree doesn't even build properly for it, so why worry about this one just yet?
Our goal is to have tip of tree LLVM / clang be able to build any supported branch of the kernel so that whenever it branches and releases, the fixes for it are already present in released kernel versions so users can just pick them up and go. We are going to have to worry about this at some point since it is a stable-only issue so why not tackle it now?
Silence the warning by initializing the struct.
Why not fix the compiler not to do this instead? We hate doing foolish work-arounds for broken compilers.
While casting away the const from the pointer in this case is "fine" because the object it pointed to was not const, I am fairly certain it is undefined behavior to cast away the const from a pointer to a const object, see commit 12051b318bc3 ("mips: avoid explicit UB in assignment of mips_io_port_base") for an exampile, so I am not sure the warning is entirely unreasonable.
Hah, we've been doing that for _decades_ with container_of(), so if that is UB, and the compiler can't handle it, I'd declare that a broken compiler :)
Look at e78f70bad29c ("time/timecounter: Fix the lie that struct cyclecounter is const") in linux-next as one example of me trying to fix that mess up. It's going to take a bunch of work to get there, but eventually we will. We will not be backporting all of those patches though, that would be way too much work.
Anyway, as the maintainer doesn't seem to want this, I guess I'll just ignore it for now?
thanks,
greg k-h