From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id AA0F3C4332F for ; Wed, 2 Nov 2022 20:56:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231347AbiKBU4i (ORCPT ); Wed, 2 Nov 2022 16:56:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45168 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229880AbiKBU4h (ORCPT ); Wed, 2 Nov 2022 16:56:37 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5B76C9FFD for ; Wed, 2 Nov 2022 13:56:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=RuYJBwdniC0fUIA8iPYvmqqtIFeCrOoE56vBbxBIa1w=; b=wUJiR5mE13DDjTMOHdu4oOUwsD nTNhOS567uNhR/8LADRz1JqAymbZ3PEvKiajRgviBOreNLS/+YzRt8u4qHlLoIsKdNxEBdG9Bb7n4 EoiCEXUn4U3yOlh6MFTvO35Oy5aUWKuHkCMag8yuWZ/NKYRuXkbrfb1cPhzHuOPtABB8wkKEr9OzW KnlymCRkXRVJcIV45NN3j4iCq4RwaevxfJxdEuIKwrhARSQbaVOzhmLKjcsZTZcAYHEGlnmi26bga 6Fhsyw0o82Yyc+tMXi9TlQjAQ//QnazVTLjJoP+/V1tPOARtETfQNpfOxxxUaqE6pDE3hXyrMjpr3 f04U2sJA==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1oqKmT-005ptZ-Iq; Wed, 02 Nov 2022 20:56:13 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 73F8A30031B; Wed, 2 Nov 2022 21:56:07 +0100 (CET) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 5B8272078A2A9; Wed, 2 Nov 2022 21:56:07 +0100 (CET) Date: Wed, 2 Nov 2022 21:56:07 +0100 From: Peter Zijlstra To: Paolo Bonzini Cc: Sean Christopherson , Gaosheng Cui , tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, kvm@vger.kernel.org Subject: Re: [PATCH] KVM: x86: fix undefined behavior in bit shift for __feature_bit Message-ID: References: <20221031113638.4182263-1-cuigaosheng1@huawei.com> <47ae788b-c19d-3a1f-8ac2-b6674770e79f@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47ae788b-c19d-3a1f-8ac2-b6674770e79f@redhat.com> Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Wed, Nov 02, 2022 at 06:54:22PM +0100, Paolo Bonzini wrote: > On 10/31/22 21:54, Peter Zijlstra wrote: > > > PeterZ is contending that this isn't actually undefined behavior given how the > > > kernel is compiled[*]. That said, I would be in favor of replacing the open-coded > > > shift with BIT() to make the code a bit more self-documenting, and that would > > > naturally fix this maybe-undefined-behavior issue. > > > > > > [*]https://lore.kernel.org/all/Y1%2FAaJOcgIc%2FINtv@hirez.programming.kicks-ass.net > > I'm definitely in favour of updating this code; both your suggestion and > > hpa's suggestion look like sane changes. But I do feel that whatever > > UBSAN thing generated this warning needs to be fixed too. > > > > I'm fine with the compiler warning about this code -- but it must not > > claim undefined behaviour given the compiler flags we use. > > Yes, the compiler is buggy here (see old bug report for GCC, now fixed, at > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68418). > > I cannot even reproduce the problem with the simple userspace testcase > > #include > int main(int argc) { > int i = argc << 31; > exit(i < 0); > } > > on either GCC 12 or clang 15. Perhaps we should have the UBSAN splat include the compiler-version used... because clearly someone is using ancient crap here.