Received-SPF: pass (google.com: domain of linux-kernel+bounces-158980-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Thu, 25 Apr 2024 10:47:32 -0700
From: Nathan Chancellor <nathan@kernel.org>
To: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Cc: Christian Brauner <brauner@kernel.org>, amir73il@gmail.com,
	hu1.chen@intel.com, miklos@szeredi.hu, malini.bhandaru@intel.com,
	tim.c.chen@intel.com, mikko.ylinen@intel.com, lizhen.you@intel.com,
	linux-unionfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, llvm@lists.linux.dev
Subject: Re: [PATCH v1 0/3] overlayfs: Optimize override/revert creds
Message-ID: <20240425174732.GA270911@dev-arch.thelio-3990X>
References: <20240403021808.309900-1-vinicius.gomes@intel.com>
 <20240424-befund-unantastbar-9b0154bec6e7@brauner>
 <87a5liy3le.fsf@intel.com>
 <20240425-nullnummer-pastinaken-c8cf2f7c41f3@brauner>
 <87y191wem5.fsf@intel.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87y191wem5.fsf@intel.com>

On Thu, Apr 25, 2024 at 10:12:34AM -0700, Vinicius Costa Gomes wrote:
> Christian Brauner <brauner@kernel.org> writes:
> 
> > On Wed, Apr 24, 2024 at 12:15:25PM -0700, Vinicius Costa Gomes wrote:
> >> I believe the crash and clang 17 compilation error point to the same
> >> problem, that in ovl_rename() some 'goto' skips the declaration of the
> >> (implicit) variable that the guard() macro generates. And it ends up
> >> doing a revert_creds_light() on garbage memory when ovl_rename()
> >> returns.
> >
> > If this is a compiler bug this warrants at least a comment in the commit
> > message because right now people will be wondering why that place
> > doesn't use a guard. Ideally we can just use guards everywhere though
> > and report this as a bug against clang, I think.
> >
> 
> I am seeing this like a bug/mising feature in gcc (at least in the
> version I was using), as clang (correctly) refuses to compile the buggy
> code (I agree with the error).

Indeed, your description of the issue and the fact clang refuses to
compile the problematic code makes me think that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91951 is the relevant GCC
issue.

As an aside, just in case it comes up in the future, there is a
potential issue in clang's scope checking where it would attempt to
validate all labels in a function as potential destinations of 'asm
goto()' instances in that same function, rather than just the labels
that the 'asm goto()' could jump to, which can lead to false positive
errors about jumping past the initialization of a variable declared with
cleanup.

https://github.com/ClangBuiltLinux/linux/issues/1886
https://github.com/ClangBuiltLinux/linux/issues/2003

Cheers,
Nathan