Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 31 Oct 2022 13:32:40 +0100
From:   Peter Zijlstra <peterz@infradead.org>
To:     Gaosheng Cui <cuigaosheng1@huawei.com>
Cc:     tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
        dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
        tony.luck@intel.com, pawan.kumar.gupta@linux.intel.com,
        pbonzini@redhat.com, chenyi.qiang@intel.com,
        jithu.joseph@intel.com, alexs@kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86/cpu: fix undefined behavior in bit shift for
 intel_detect_tlb
Message-ID: <Y1/AaJOcgIc/INtv@hirez.programming.kicks-ass.net>
References: <20221031114340.4185587-1-cuigaosheng1@huawei.com>
 <Y1/AAegYuyZPxH04@hirez.programming.kicks-ass.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Y1/AAegYuyZPxH04@hirez.programming.kicks-ass.net>
Precedence: bulk

On Mon, Oct 31, 2022 at 01:30:57PM +0100, Peter Zijlstra wrote:
> On Mon, Oct 31, 2022 at 07:43:40PM +0800, Gaosheng Cui wrote:
> > Shifting signed 32-bit value by 31 bits is undefined, so changing
> > significant bit to unsigned. The UBSAN warning calltrace like below:
> > 
> > UBSAN: shift-out-of-bounds in arch/x86/kernel/cpu/intel.c:948:21
> > left shift of 1 by 31 places cannot be represented in type 'int'
> 
> Is it really? Shouldn't -fstrict-overflow define this case?

-fno-strict-overflow that is, which implies -fwrapv which ensures 2s
complement, at which point shifting signed numbers is fully defined.