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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 7E304D711C3 for ; Thu, 18 Dec 2025 21:08:26 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 3C07710E2E4; Thu, 18 Dec 2025 21:08:26 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="FDTB5mK4"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) by gabe.freedesktop.org (Postfix) with ESMTPS id 45F9D10E2E4 for ; Thu, 18 Dec 2025 21:08:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1766092104; x=1797628104; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=D6YuTwaymB+t7wqx49M6IXwwGQtZmfgbqHicKdk1KN8=; b=FDTB5mK4+vdmsYL2Mss3OcSykuvdVhfYJn8cM/yJTyW7wZwYYAAM2hu+ yOF5JcU+KUmT3E5yteqOuNZfMZKDL4cH3SqTwVz2lLjMbD3bBgqqfQaoV csg1cBoj72tSa12Fuvim9ICJTpyDdb1TayovppAMUCqG9UKDE9Vh01VpP hpA+0WulY7JwBVJSoMNQ5iw0s3rGPREGFSyuqIKX/bPV2XjMQeRw7ODel 1htL+K0GE8aJLNqxQkwsfMDIVb45LS67X3tWnt0Egk4aAWItc9cSBY3Tz aW61NobYsK8xHIPgXD6MvVwRPqNTu1FluHl1zClVXtZib9di5WwNDtuDY Q==; X-CSE-ConnectionGUID: cUesqsgqQ3+2ZE3tMrs88Q== X-CSE-MsgGUID: /xeocMncTwmqreRs6tBQeQ== X-IronPort-AV: E=McAfee;i="6800,10657,11646"; a="68210615" X-IronPort-AV: E=Sophos;i="6.21,159,1763452800"; d="scan'208";a="68210615" Received: from orviesa010.jf.intel.com ([10.64.159.150]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Dec 2025 13:08:24 -0800 X-CSE-ConnectionGUID: 4n+sc0t6QDqJxK07zCtvXg== X-CSE-MsgGUID: IE+A2Yl4RZ+sPPDjP0YSFw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,159,1763452800"; d="scan'208";a="197944253" Received: from unknown (HELO adixit-MOBL3.intel.com) ([10.57.131.238]) by orviesa010-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Dec 2025 13:08:24 -0800 Date: Thu, 18 Dec 2025 13:08:23 -0800 Message-ID: <87345733co.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Jonathan Cavitt Cc: intel-xe@lists.freedesktop.org, saurabhg.gupta@intel.com, alex.zuo@intel.com, matthew.brost@intel.com, daniele.ceraolospurio@intel.com, rodrigo.vivi@intel.com, michal.wajdeczko@intel.com Subject: Re: [PATCH 1/6] drm/xe/xe_guc_ct: WRITE_ONCE g2h_fence done in g2h_fence_cancel In-Reply-To: <20251218153527.6436-9-jonathan.cavitt@intel.com> References: <20251218153527.6436-8-jonathan.cavitt@intel.com> <20251218153527.6436-9-jonathan.cavitt@intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-BeenThere: intel-xe@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Xe graphics driver List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-xe-bounces@lists.freedesktop.org Sender: "Intel-xe" On Thu, 18 Dec 2025 07:35:29 -0800, Jonathan Cavitt wrote: > > Use WRITE_ONCE when operating on g2h_fence->done in g2h_fence_cancel to > prevent the compiler from ignoring this operation. > > Fixes: 94de94d24ea8 ("drm/xe/guc: Cancel ongoing H2G requests when stopping CT") > Suggested-by: Matthew Brost > Signed-off-by: Jonathan Cavitt > Cc: Michal Wajdeczko > --- > drivers/gpu/drm/xe/xe_guc_ct.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/xe/xe_guc_ct.c b/drivers/gpu/drm/xe/xe_guc_ct.c > index c3df9b3f1b4d..d177df166d2a 100644 > --- a/drivers/gpu/drm/xe/xe_guc_ct.c > +++ b/drivers/gpu/drm/xe/xe_guc_ct.c > @@ -206,7 +206,9 @@ static void g2h_fence_cancel(struct g2h_fence *g2h_fence) > { > g2h_fence->cancel = true; > g2h_fence->fail = true; > - g2h_fence->done = true; > + > + /* WRITE_ONCE pairs with wait_event_timeout in guc_ct_send_recv */ > + WRITE_ONCE(g2h_fence->done, true); > } So the compiler just optimizes ->done? It doesn't optimize ->cancel and ->fail, e.g.? Generally ok to do this, but sometimes they are also unnecessary. Have we seen evidence of the compiler optimizing this out? Also in other places where we are doing this in other patches? > > static bool g2h_fence_needs_alloc(struct g2h_fence *g2h_fence) > -- > 2.43.0 >