From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C09AA1FBC81 for ; Fri, 17 Jan 2025 10:35:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737110155; cv=none; b=aFTJMsWvwO6XTe6q3Pka+4AKYEaDn4RYkHGXN8mD30fndCqnyKVbtxqxiJtMZV0iiQsFIKF7iXs4t8H4YGU5nfeCWxDyHph2vC1elGh509cd7vAG+ZYuJKY+YaWq2SHnAqO2McvXHZN+KnbG2VNFMCxQLUykjGGzGtU5AbeN2I4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737110155; c=relaxed/simple; bh=8GDR1OfctaMtBt/noUdVRZPLAPkEG3Xl7ShcHClPNGc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=h0ipIxfYgZcHXa9kt047QL5/mDlZiBeWasAvTz0Bz1w7uONRa1KgW5b0jXe0tGgnTC2CMVQlN8XDPYDCi3zpWIYPpzJdFrChxstiRaESuDh6rQQBgEx6qnd5CJ9KNbkoXLWcvM80O+s01fz/BpZieiOwVeBKMABJo3vgHEdF5zo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=1ufwZp+M; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=H/k683fb; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="1ufwZp+M"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="H/k683fb" From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1737110151; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kJ2kv/1rlnnXeEw5Xrh2XCElzdIj6/ZqbMeXkDt/4sE=; b=1ufwZp+MdggMD1gfYxrxBv5RrtmNfABJtcVSxXENkw7ofHq1hNwdimO1I8RWvPhVLFi6pJ BbcZ84hriEpEJcB4hCR3Pl0FE17k1jaIRdkNuStD4NNUN27WAXXIGNAsuBdco8Egz0TZtK FtWKb8zS0+KLGiKhdvh0o80Lxu7N/nyLQKw79MQu3l3X87+3Hpl6JIiJ0vVEuyA6BmKeR3 ZXXdNHOodgexoQmHFNGPxXfs5olVV4o++OKYGAQlWgJShG+3ii/9EbA8p5OWFuAMQfTP6h BIdYStwvEXtD1zHjhOl3Izjx8LlFGmPdl96IYCkCETz5Wf/kjKvDONNV5919dA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1737110151; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kJ2kv/1rlnnXeEw5Xrh2XCElzdIj6/ZqbMeXkDt/4sE=; b=H/k683fbRi1hdZKWI7aHHNFZY7076K+lLa7jz8AcCkMrM44Fd/RnkBqAEGuFC+YA7xxw6Q y+OP+6x8JJiFPLBg== To: Charlie Jenkins , Xu Lu Cc: anup@brainfault.org, paul.walmsley@sifive.com, palmer@dabbelt.com, lihangjing@bytedance.com, xieyongji@bytedance.com, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] irqchip: riscv: Order normal writes and IPI writes In-Reply-To: References: <20250116120710.51673-1-luxu.kernel@bytedance.com> Date: Fri, 17 Jan 2025 11:35:51 +0100 Message-ID: <87ldv9afso.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain Charlie! On Thu, Jan 16 2025 at 13:09, Charlie Jenkins wrote: > On Thu, Jan 16, 2025 at 08:07:10PM +0800, Xu Lu wrote: >> Replace writel_relaxed() with writel() when issuing IPI to ensure all >> previous write operations made by current CPU are visible to other CPUs. > > Did you experience an ordering issue from this? That's not the right question. CPU 0 CPU 1 store A // data store B // IPI IPI handler load A The real question is whether the RISC-V memory model guarantees under all circumstances that A is globally visible before the IPI handler load. If so, then the writel_relaxed() is fine. If not, the fence is required. That's not a question of observation. It's a question of facts defined by the architecture. People have wasted months to analyze such fails which tend to happen once every blue moon with no other trace than "something went wrong" .... > - Charlie Please trim your replies... Thanks, tglx