lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2025072504-easel-propose-0474@gregkh>
Date: Fri, 25 Jul 2025 19:08:03 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Nathan Chancellor <nathan@...nel.org>
Cc: Justin Stitt <justinstitt@...gle.com>, Marc Zyngier <maz@...nel.org>,
	James Morse <james.morse@....com>,
	Alexandru Elisei <alexandru.elisei@....com>,
	Suzuki K Poulose <suzuki.poulose@....com>,
	Oliver Upton <oliver.upton@...ux.dev>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>, Tom Rix <trix@...hat.com>,
	Christopher Covington <cov@...eaurora.org>,
	linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.linux.dev,
	kvmarm@...ts.cs.columbia.edu, linux-kernel@...r.kernel.org,
	llvm@...ts.linux.dev, stable@...r.kernel.org
Subject: Re: [PATCH 6.1.y] KVM: arm64: silence -Wuninitialized-const-pointer
 warning

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ