From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dave.hansen@intel.com>
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on gnuweeb.org
X-Spam-Level: 
X-Spam-Status: No, score=-2.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,
	SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no
	version=3.4.6
Received: from mga03.intel.com (mga03.intel.com [134.134.136.65])
	by gnuweeb.org (Postfix) with ESMTPS id 16B6F7E355
	for <gwml@vger.gnuweeb.org>; Fri,  1 Apr 2022 17:42:49 +0000 (UTC)
Authentication-Results: gnuweeb.org;
	dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=JmetbBks;
	dkim-atps=neutral
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
  t=1648834969; x=1680370969;
  h=message-id:date:mime-version:subject:to:cc:references:
   from:in-reply-to:content-transfer-encoding;
  bh=l350qzJiVd8sPS5s1ZAsOW21hq4CN6KH7Zi8RQ7ouoo=;
  b=JmetbBksKfThcAInbVRWgrp1Pdsf1Z3zNHsMrHAPbp2xc+MeC58xoIJX
   OmE86Sf0H+VTuCs/gXKXFt7gi3FqjbJvlELFDFQ5BEMqYydhVqHYEKPXp
   1mo67Fi4LZomKyGIKCWI6odoVHtlRUwCd9sWCPIUXHp+MbvkYVd06T/Hi
   M963RrPON/eFjMPoVHWV4i+1Ex6rExQniXBI88L5uOhQa5yeiJ+5kYJmI
   oqbYdh/+flnj94F2Ah2mmWa0Ea82E3f0prMIfrsk2rgkb28Iwau8Yjg5P
   MDlCqOYEvFcl256jowNTqVY3e5IWWOHbS03DMJE4FHIFOakbRg9y3e0r/
   g==;
X-IronPort-AV: E=McAfee;i="6200,9189,10304"; a="260179157"
X-IronPort-AV: E=Sophos;i="5.90,228,1643702400"; 
   d="scan'208";a="260179157"
Received: from orsmga008.jf.intel.com ([10.7.209.65])
  by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Apr 2022 10:42:48 -0700
X-IronPort-AV: E=Sophos;i="5.90,228,1643702400"; 
   d="scan'208";a="567669840"
Received: from dajones-mobl.amr.corp.intel.com (HELO [10.212.134.9]) ([10.212.134.9])
  by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Apr 2022 10:42:48 -0700
Message-ID: <13463eca-03a2-da0d-c274-fb576a8a051f@intel.com>
Date: Fri, 1 Apr 2022 10:42:48 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.7.0
Subject: Re: [PATCH v6 1/2] x86/delay: Fix the wrong asm constraint in
 `delay_loop()`
Content-Language: en-US
To: Ammar Faizi <ammarfaizi2@gnuweeb.org>, Borislav Petkov <bp@alien8.de>,
 Thomas Gleixner <tglx@linutronix.de>
Cc: Alviro Iskandar Setiawan <alviro.iskandar@gnuweeb.org>,
 Dave Hansen <dave.hansen@linux.intel.com>, "H. Peter Anvin" <hpa@zytor.com>,
 Ingo Molnar <mingo@redhat.com>, Tony Luck <tony.luck@intel.com>,
 Yazen Ghannam <yazen.ghannam@amd.com>,
 Linux Edac Mailing List <linux-edac@vger.kernel.org>,
 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
 Stable Kernel <stable@vger.kernel.org>,
 GNU/Weeb Mailing List <gwml@vger.gnuweeb.org>,
 x86 Mailing List <x86@kernel.org>, David Laight <David.Laight@ACULAB.COM>,
 Jiri Hladky <hladky.jiri@googlemail.com>
References: <20220329104705.65256-1-ammarfaizi2@gnuweeb.org>
 <20220329104705.65256-2-ammarfaizi2@gnuweeb.org>
From: Dave Hansen <dave.hansen@intel.com>
In-Reply-To: <20220329104705.65256-2-ammarfaizi2@gnuweeb.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
List-Id: <gwml.vger.gnuweeb.org>

On 3/29/22 03:47, Ammar Faizi wrote:
> The asm constraint does not reflect that the asm statement can modify
> the value of @loops. But the asm statement in delay_loop() does modify
> the @loops.
> 
> Specifiying the wrong constraint may lead to undefined behavior, it may
> clobber random stuff (e.g. local variable, important temporary value in
> regs, etc.). This is especially dangerous when the compiler decides to
> inline the function and since it doesn't know that the value gets
> modified, it might decide to use it from a register directly without
> reloading it.
> 
> Fix this by changing the constraint from "a" (as an input) to "+a" (as
> an input and output).

Was this found by inspection or was it causing real-world problems?