Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp8492947ybi; Thu, 6 Jun 2019 13:19:52 -0700 (PDT) X-Google-Smtp-Source: APXvYqzgWDCXUVjbLna50sA3Op0MF2XscaOEc945p16axblecV6duvIiIsGqU8AGanlz9t3HdJqg X-Received: by 2002:a17:90a:8415:: with SMTP id j21mr1656205pjn.21.1559852392874; Thu, 06 Jun 2019 13:19:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559852392; cv=none; d=google.com; s=arc-20160816; b=TA5juUJnBPRdhqwDupLjd67ZUsdurnEt/zwTPSr82cwHaIqW6NiX8X6+7buKzTEqp/ TvAYU4YXF9vhlUkC1dx0/AXyuG682fgIASBAOL48/PPWrQVfY+OImxyvxk2uZsnrKjl6 /C2YYPKWAJ8dm6OWQSWV4kfkRFjNSJryR9hwwJC+KTolzrpyteTPWlg1xv0uv5s/dX40 5JDaHi3g4XGCdzCixVVjQZrtPMxtAcfhhQovHTAgcGvCsLMSPWrxDcmqYVrR7yT+06nD nZYVzQoPPXQyaAJdR9tYJWezE5o31Zcd+9AHZ0glndrC4THXbnqXOvfUYac5iB50RHH7 hMzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:to:from:cc:in-reply-to:subject:date:dkim-signature; bh=iq2ZMOKhxG40k3ZjkkAfD8/mhEY6iwy4v663CmYVX5Q=; b=C23Dm4KdyyfYkQeXnzCRCqi0KWG13yERyiYsBf1vhcMxUwSZuzzwQIAh/c0ZdGhauQ KQLyxh7vZGiSxOf1M84OAWccdOSLBXdwT80UqJi6f6IyV0Axwt9XnTrQwSl+1rB2Yocy OCB23nUeGTaTRyjQjcdscZ8XJFzCXZh4dl8yjOTfycz5eSGf8YJlAO5Tf2RQBhpZRbqA Nqj/Osjinpe2/wxSVyVfhlHeaKDuk6bgbRDMEcuzrwWK6uByVuUV9QuE7Xwnc8nR5bLI U4ALHD77UR4Tdfmz92OmTXo+EPABcriiVNqIte+x+1tgceYTcrmE9McgArcoloLtUnQd qnRA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sifive.com header.s=google header.b=enaoKJ57; 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 m5si39245pgj.451.2019.06.06.13.19.29; Thu, 06 Jun 2019 13:19:52 -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; dkim=pass header.i=@sifive.com header.s=google header.b=enaoKJ57; 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 S1728821AbfFFTKd (ORCPT + 99 others); Thu, 6 Jun 2019 15:10:33 -0400 Received: from mail-pf1-f195.google.com ([209.85.210.195]:46974 "EHLO mail-pf1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728690AbfFFTKd (ORCPT ); Thu, 6 Jun 2019 15:10:33 -0400 Received: by mail-pf1-f195.google.com with SMTP id 81so829617pfy.13 for ; Thu, 06 Jun 2019 12:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=date:subject:in-reply-to:cc:from:to:message-id:mime-version :content-transfer-encoding; bh=iq2ZMOKhxG40k3ZjkkAfD8/mhEY6iwy4v663CmYVX5Q=; b=enaoKJ57+AWkQ/VcvXkyxXhGlqXFGFOA4xotHL8PViRCGoywuFOLat/NWbwVKMJRsv /6zQrNaJ/cDsC6+AIUtQfT7+hSekvAbQRzbG+qaghYV1vBxnYVc15Dubhn5p/wGgF9C0 qYorLZzRxLxQgeQRYQWkc09mR1WoWRq8CbOmrM88g/lRcS5jm0LYcxiabWtbQHrvNkaM dIxA9UpmM+zdTDic/w9UuUE7kWVNHRKuf0BRjNIM+PHVO3d+u2FGXZ3twojCUvuWkrvx Rk5DdAzQV1rEkUg4pyUMZ3jneiFRWmLJcal3R4IGVvVE8z/g47u+QICQFjAskvWhaAKk mZgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=iq2ZMOKhxG40k3ZjkkAfD8/mhEY6iwy4v663CmYVX5Q=; b=FsL49qRuuCbpXrij7fyS5zKY5yUmGTsFtdCl3PeL78T+R+n4D1IpVmmkelkY04s1qT dE5AcLGrbWAYeHI7BxAkq+pR6WkswUM9N7APvx3uBrPWytUPTxd9K0fkZ5vFF1FCQkaU f4Vxi+Ps9/EB4vkIRDsQN9azLstRBRpG1vLowZ5N2ORWllytbh61r3GJFyMApeNxmpAO L6xuG+OQGJHnaUffmsR7aKsHGsEgvCqV+8avmPdqwUIqKP8kUx/Y9hFQsdZ7m+nS5+yG UNkhz4bMlNHqKkC2oKEcqQxlaVH0u22lMkRL2/+hdAVx11ic6tsbkDmr/3A39Y9G1STg i3dg== X-Gm-Message-State: APjAAAV+0Kt6Am1oAO8MNEnkfCZctZivMUxomq+U6uPhckLI9SViYlWZ gWFfr64etN8jutOP9BvR83YGHw== X-Received: by 2002:a62:750c:: with SMTP id q12mr33795301pfc.59.1559848232489; Thu, 06 Jun 2019 12:10:32 -0700 (PDT) Received: from localhost ([12.206.222.5]) by smtp.gmail.com with ESMTPSA id z15sm2307084pge.40.2019.06.06.12.10.30 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 06 Jun 2019 12:10:31 -0700 (PDT) Date: Thu, 06 Jun 2019 12:10:31 -0700 (PDT) X-Google-Original-Date: Thu, 06 Jun 2019 12:09:29 PDT (-0700) Subject: Re: [PATCH] RISC-V: Break load reservations during switch_to In-Reply-To: <20190606090518.GB1369@infradead.org> CC: linux-riscv@lists.infradead.org, Paul Walmsley , marco@decred.org, me@carlosedp.com, joel@sing.id.au, linux-kernel@vger.kernel.org From: Palmer Dabbelt To: Christoph Hellwig Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 06 Jun 2019 02:05:18 PDT (-0700), Christoph Hellwig wrote: > On Wed, Jun 05, 2019 at 04:17:35PM -0700, Palmer Dabbelt wrote: >> REG_S ra, TASK_THREAD_RA_RA(a3) >> + /* >> + * The Linux ABI allows programs to depend on load reservations being >> + * broken on context switches, but the ISA doesn't require that the >> + * hardware ever breaks a load reservation. The only way to break a >> + * load reservation is with a store conditional, so we emit one here. >> + * Since nothing ever takes a load reservation on TASK_THREAD_RA_RA we >> + * know this will always fail, but just to be on the safe side this >> + * writes the same value that was unconditionally written by the >> + * previous instruction. >> + */ >> +#if (TASK_THREAD_RA_RA != 0) > > I don't think this check works as intended. TASK_THREAD_RA_RA is a > parameterized macro, thus the above would never evaluate to 0. The > error message also is rather odd while we're at it. OK, I didn't try it. The resulting number can never be non-zero, which is why I couldn't come up with an error message that made sense. I'm not opposed to dropping the check. >> +#if (__riscv_xlen == 64) >> + sc.d x0, ra, 0(a3) >> +#else >> + sc.w x0, ra, 0(a3) >> +#endif > > I'd rather add an macro ala REG_S to asm.h and distinguish between the > xlen variants there: > > #define REG_SC __REG_SEL(sc.d, sc.w) Ya, I guess I was just being lazy. I'll put that in a v2.