Received: by 2002:ac0:950c:0:0:0:0:0 with SMTP id f12csp1154099imc; Mon, 11 Mar 2019 07:35:40 -0700 (PDT) X-Google-Smtp-Source: APXvYqyaoTkOGxO2wVXiethFAO8V91JLf1frkT14YkP5LnA+/MEoE2GmwIAFK7GOmtvsEkQsB7dq X-Received: by 2002:a65:614f:: with SMTP id o15mr29987605pgv.383.1552314940262; Mon, 11 Mar 2019 07:35:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552314940; cv=none; d=google.com; s=arc-20160816; b=eBU2stQRlh2BEIeqVuwKBSi4/T/90UaU80XsXPklD0ZQVWnXbdAiNReYhRtXfW2XtE Tf5WumEEcw71Iz0XKrXcloOK7c/vzEo2xaxGetezjI5eutFcVqWc923QAklVyktFRxlz bUMZvbW/jDfb24m00IhFr12KmFHHWanoOmopgfA3f9znL0mJtBW2B9kHNhTtq1ZrKwA0 Jx5yNCrWGV054yk0/E2Og7aDeuS3jiPbvMxNmyrSImUwYb4Ye4SO0YRnuVA/LArqur8z eL09zHdmwH4gqn05mVJNzm5s76cEW4F5pDWWVxY6qSBkV9yAGNMqzHcwRGzrPZ+EE5tA QOuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=oK2+PdVKHrzl5KsU0CubhYYaSIsPJ2+otgMPFjFMvKk=; b=d2CFg3O2Fqp9nDzq/9I+XyXSftobn54rXyRtuWNKipzIan68pIiYhjTTwg8/nS2HIK 4735VrltRfLh3JW+g9QumHXbW12Dzt96+VSjJQ8lrUf/FuDGdWEQnQMASsgiWnmozUet ZinKS1VHlXNOMRjlb1a9UXRW1vg9wk7IE5Fr/Rm4eqLpHoTtCDO1LFQZfyDd+zuRb+ty Z+AwXYMbjRb6TeGVjup1Vy1odFWEZmyxgrXMIQkmoAq/zXwH0yx3b4/bxAdMAJG4vEeC m/KJkkZWzbfkJWxRczIl786Mlm5FxI4QuY2V3De0X/5Xt/YM/a7QwMnR2FwDJbKfDa5H mZwQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z18si4925363pgf.66.2019.03.11.07.35.24; Mon, 11 Mar 2019 07:35:40 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727486AbfCKOev (ORCPT + 99 others); Mon, 11 Mar 2019 10:34:51 -0400 Received: from mail-qk1-f195.google.com ([209.85.222.195]:38121 "EHLO mail-qk1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725943AbfCKOev (ORCPT ); Mon, 11 Mar 2019 10:34:51 -0400 Received: by mail-qk1-f195.google.com with SMTP id z3so2805371qkf.5 for ; Mon, 11 Mar 2019 07:34:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oK2+PdVKHrzl5KsU0CubhYYaSIsPJ2+otgMPFjFMvKk=; b=XeTCUFWpxf00EQMKJuBYoxMBYy/gipsV1C6Fea68qODzfVtJBnxhiCePZrDoddsZkN o3hL8YF83U51oMvsaUlf2dqDMH6tvXrpm4rN1PQsgWIfqBSSCITYR0ECVvPusFW74jrE gVqxb3WfAofCDeXlTQLBPXpc5zA45N2db2eOa/79AQOt5BzGnV5U9BMU3Q0pByVeO04d OSwOBPrq2TLIMYJMUsA819amDP3iOqedaW/e8wmYzQPjweKG36+o/OYB9giRIUzwkPyS lG0aAp8CbudPlct1cfqyHxhUiv/HPMFOAfhpueyF6G0U7HlN4tT867M12oVaB1DgD8TQ PRdA== X-Gm-Message-State: APjAAAUNwTQh30svTrh5qjnMsiO5Ih4nyodNFw2eumEv+/fwtIkoP0oZ SzRVdqLzheCUci1NlP+cDrFflMCR719NzK+bLYQ= X-Received: by 2002:a05:620a:158c:: with SMTP id d12mr8047772qkk.173.1552314890231; Mon, 11 Mar 2019 07:34:50 -0700 (PDT) MIME-Version: 1.0 References: <20190307091514.2489338-1-arnd@arndb.de> <20190307091514.2489338-2-arnd@arndb.de> <20190307234850.nsbpkfcit3lnmytu@shell.armlinux.org.uk> <20190308095308.hjjrzdp4fzbbtnnv@shell.armlinux.org.uk> <20190308103429.ycasmpt6tcpsoqps@shell.armlinux.org.uk> <20190308105835.tovswk5rwxusmxdu@shell.armlinux.org.uk> In-Reply-To: From: Arnd Bergmann Date: Mon, 11 Mar 2019 15:34:31 +0100 Message-ID: Subject: Re: [PATCH 2/2] ARM: futex: make futex_detect_cmpxchg more reliable To: Ard Biesheuvel Cc: Russell King - ARM Linux admin , Mikael Pettersson , Peter Zijlstra , Nick Desaulniers , LKML , Ingo Molnar , Darren Hart , Thomas Gleixner , Dave Martin , Linux ARM Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 8, 2019 at 12:56 PM Ard Biesheuvel wrote: > On Fri, 8 Mar 2019 at 11:58, Russell King - ARM Linux admin wrote: > > On Fri, Mar 08, 2019 at 11:45:21AM +0100, Ard Biesheuvel wrote: > > Perhaps. So let me summarize what I do understand. > > 1) if futex_atomic_cmpxchg_inatomic() is instantiated *and executed* > with the same compile time constant value of 0x0 for newval and uaddr, > we end up with an opcode for the STRT instruction that is CONSTRAINED > UNPREDICTABLE, but we will never execute it since the preceding load > will fault and enter the fixup handler. > 2) such occurrences of futex_atomic_cmpxchg_inatomic() are unlikely to > occur in the code, but may be instantiated by the compiler when doing > constant propagation (like in the ilog2() case I quoted), but these > instantiations will never be called > 3) both clang and gcc may map different inline asm input operands onto > the same register if the value is guaranteed to be the same (i.e., > they are both compile time constants) > > My statement about uaddr was slightly misguided, in the sense that our > invocation of STRT does use the post-index variant, but with an > increment of zero, so the value written back to the register equals > the original value. But it does explain why this opcode is CONSTRAINED > UNPREDICTABLE in the first place. > > Given 2) above, I wonder if anyone could confirm whether adding > 'BUG_ON(__builtin_constant_p(uaddr))' silences the warning as well. Like this? diff --git a/arch/arm/include/asm/futex.h b/arch/arm/include/asm/futex.h index 0a46676b4245..e6e9b403cd61 100644 --- a/arch/arm/include/asm/futex.h +++ b/arch/arm/include/asm/futex.h @@ -57,6 +57,7 @@ futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr, /* Prefetching cannot fault */ prefetchw(uaddr); __ua_flags = uaccess_save_and_enable(); + BUG_ON(__builtin_constant_p(uaddr) || !uaddr); __asm__ __volatile__("@futex_atomic_cmpxchg_inatomic\n" "1: ldrex %1, [%4]\n" " teq %1, %2\n" This had no effect here. My first attempt (before finding the original patch from Mikael Pettersson) was to change the probe to pass '1' as the value instead of '0', that worked fine. Arnd