From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1C5E1158A1F for ; Fri, 29 Nov 2024 13:23:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732886632; cv=none; b=hP1Q4eVD6RnIcp0Bj6jrlcq/QA5btyg6JlW/ZOGYIj4FkjEJa0C+ud+9ppi8H7OVsVRXNGr22W6ILOOXUhlBRdQt+cuPiqZ6A//2yL4UVivW3013X/7+uk7JYyq0cPymSlbqlCuwvx+62M++FONCoSItco8neY68JLJvlcflutI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732886632; c=relaxed/simple; bh=u4S2D0fEUdaOO9URa7k5oHWRKuFk0OWDWYhv6URG4eQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: In-Reply-To:Content-Type:Content-Disposition; b=rPGrBjTuiqzRZEE2wUWgtYzoaLLGEPFvbQZlVxt+dezLJiCxcCpDdavgzU5oSjz3SORXNAmGt+PJSmIwCKapEbFmX01ezpcdKfF/1DLCoJEsd+g28kry1XwFJ+a0dRn/S18h0W1lwhU5SvP8QgroIXs3J8qXBmKIWyFY7ayLSic= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=KqtxUFX6; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="KqtxUFX6" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1732886628; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fhroV1mN5TFanqr4XJNggKvaQy5w3TMiqC7FLHSw/dI=; b=KqtxUFX6MW94l4nL0q8gumjoFAf3pv4toQeTj4/Gg9PRi8FkrSTHpMzUiOuKxQnyCSupbR bSwvKCZGFTimMOqZEkajL1Gk/f9Yq9nx2CE+gbDY5KmJtRCcKkNpljt3yOblo7IkhQhZ5D QVeZSukPos3ilXPQJShOMcBGsTLeU3k= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-213-c2znM_PyNBq0iLNh6VUvPw-1; Fri, 29 Nov 2024 08:23:43 -0500 X-MC-Unique: c2znM_PyNBq0iLNh6VUvPw-1 X-Mimecast-MFC-AGG-ID: c2znM_PyNBq0iLNh6VUvPw Received: from mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id DAE62195C258; Fri, 29 Nov 2024 13:23:42 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.225.55]) by mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 4F017195605A; Fri, 29 Nov 2024 13:23:41 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 4ATDNc2e2371558 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 29 Nov 2024 14:23:39 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 4ATDNbqi2371556; Fri, 29 Nov 2024 14:23:37 +0100 Date: Fri, 29 Nov 2024 14:23:37 +0100 From: Jakub Jelinek To: Peter Zijlstra Cc: linux-toolchains@vger.kernel.org, Linus Torvalds , x86@kernel.org Subject: Re: GCC 15 -fzero-init-padding-bits= option and redzone clobber Message-ID: Reply-To: Jakub Jelinek References: <20241129125238.GI24400@noisy.programming.kicks-ass.net> Precedence: bulk X-Mailing-List: linux-toolchains@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In-Reply-To: <20241129125238.GI24400@noisy.programming.kicks-ass.net> X-Scanned-By: MIMEDefang 3.0 on 10.30.177.40 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 3gt655LjVunrx2-VOcKciJmrhP8zbHFzMlBgbd5lmFk_1732886623 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Fri, Nov 29, 2024 at 01:52:38PM +0100, Peter Zijlstra wrote: > > Note, there is also __builtin_clear_padding builtin to clear padding bits > > already since GCC 11, though it doesn't clear bits in unions unless they > > are padding bits for all possible members, as it doesn't know which union > > member is current. > > *groan* I suppose we should enable that flag when present :/ If you want to keep previous behavior, sure. That is why I'posted this FYI. > > Another new feature since today that might be relevant to kernel is > > the "redzone" inline asm clobber. > > It can/should be used on inline asm which does or could clobber memory > > below the stack pointer and so its presence must disable use of redzone > > (currently on x86_64 and powerpc*), > > At least on x86_64 we don't currently have a redzone. Ah, I see, kernel builds with -mno-red-zone, missed that being mentioned in https://gcc.gnu.org/PR117312 that led to this. > I'm assuming the > "memory" clobber still very much includes everything? No. "memory" clobber is about clobbering memory which could be clobbered e.g. by a call to a function one doesn't know anything about and which one passes the inline asm operands to. So it can certainly clobber global variables, or address taken whose address escaped to global state (or could escape), or memory referenced from the operands of the inline asm. It can't clobber random stack locations it knows nothing about, say clobbering the saved registers on the stack in the stack frame, return address, non-address taken variables which were just spilled to stack due to register allocator decisions, etc. There would be nothing the compiler could do about that. > And why was it deemed okay to change behaviour that might break existing > code? You mean for unions? It can only change behavior of invalid code (relying on undefined behavior). Most compiler optimizations change behavior of code with UB in it, otherwise the compiler couldn't optimize anything. > We have this thing: > > /* > * This output constraint should be used for any inline asm which has a "call" > * instruction. Otherwise the asm may be inserted before the frame pointer > * gets set up by the containing function. If you forget to do this, objtool > * may print a "call without frame pointer save/setup" warning. > */ > register unsigned long current_stack_pointer asm(_ASM_SP); > #define ASM_CALL_CONSTRAINT "+r" (current_stack_pointer) > > which we use a *LOT*. And wrongly so. Inline asm really can't change the stack pointer (with the meaning that rsp would be different between the entry to the inline asm and its exit(s) (multiple for asm goto). So telling the compiler it does change is wrong. In GCC 9 we've added a warning for "rsp" and similar clobbers of inline asm, warning: listing the stack pointer register ‘rsp’ in a clobber list is deprecated There is none currently for the "+r" (current_stack_pointer), but e.g. doing current_stack_pointer += 16; or current_stack_pointer = whatever; will certainly cause UB. The behavior of "+r" (current_stack_pointer) you are relying on certainly isn't guaranteed. See https://gcc.gnu.org/PR117312 for some details. There are surely other bugs that talk about that. Jakub