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 33B85103E2F4 for ; Wed, 11 Mar 2026 23:43:23 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id BC06210E40F; Wed, 11 Mar 2026 23:43:22 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="oGHUFSK1"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.7]) by gabe.freedesktop.org (Postfix) with ESMTPS id 6F9C210E40F for ; Wed, 11 Mar 2026 23:43:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1773272601; x=1804808601; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=8TH9BmdYz8sekvth987/ESwhriN/tjj7k08IOShlqUM=; b=oGHUFSK1bDEJpa0OhZW1aJv/ObeeocdUZMuQf/DE8Tun2qCxPA8S4xDE VwE8aNHu2up3/fQ595mSM5HlltFpSJlr+rzMzo/ExYo5caldyzpR7vY0N xXOPNW7YEoStDNAu/VCTPhglald9AYjUKNR3Gp9C2xGkr2y1KMb2PvgNq tQhfNeTeL3HPONsEUsy0yNjnLYrLHpCVtx2udNpRXZ3P2MLOP9Ifrhdm2 oh9UCaopdsr1LqdhrWtvBuxcdILhRW82RfjywJw+ZhNTnVe4dcrrkAafM bc2fspaFMMbQ10Nl+cTRi2G3LA2yIixrdMZRyZmtmH3FWZg6Nz+DQRlOj g==; X-CSE-ConnectionGUID: rFp/lrUXSSuOkut3h0XGeg== X-CSE-MsgGUID: ICmJxDhVTFCo59WbPdFxmQ== X-IronPort-AV: E=McAfee;i="6800,10657,11726"; a="99821987" X-IronPort-AV: E=Sophos;i="6.23,115,1770624000"; d="scan'208";a="99821987" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Mar 2026 16:43:20 -0700 X-CSE-ConnectionGUID: fl6SXiQuQMaI2nLfqSrkMQ== X-CSE-MsgGUID: xwwFH/KqR4u+KbpM4v0Bxw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,115,1770624000"; d="scan'208";a="219756466" Received: from jwang15-mobl.amr.corp.intel.com (HELO adixit-MOBL3.intel.com) ([10.125.68.80]) by orviesa006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Mar 2026 16:43:21 -0700 Date: Wed, 11 Mar 2026 16:43:19 -0700 Message-ID: <87y0jyvso8.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Umesh Nerlige Ramappa Cc: intel-xe@lists.freedesktop.org Subject: Re: [PATCH] drm/xe/lrc: Fix uninitialized new_ts when capturing context timestamp In-Reply-To: <20260311104901.2933716-2-umesh.nerlige.ramappa@intel.com> References: <20260311104901.2933716-2-umesh.nerlige.ramappa@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 Wed, 11 Mar 2026 03:49:02 -0700, Umesh Nerlige Ramappa wrote: > > Getting engine specific CTX TIMESTAMP register can fail. In that case, > if the context is active, new_ts is uninitialized. Fix that case by > initializing new_ts to lrc_ts. > > Flagged by static analysis. > > Signed-off-by: Umesh Nerlige Ramappa > --- > drivers/gpu/drm/xe/xe_lrc.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/xe/xe_lrc.c b/drivers/gpu/drm/xe/xe_lrc.c > index aa26c71ae34f..9d766ef414ed 100644 > --- a/drivers/gpu/drm/xe/xe_lrc.c > +++ b/drivers/gpu/drm/xe/xe_lrc.c > @@ -2563,7 +2563,7 @@ static int get_ctx_timestamp(struct xe_lrc *lrc, u32 engine_id, u64 *reg_ctx_ts) > * @lrc: Pointer to the lrc. > * > * Return latest ctx timestamp. With support for active contexts, the > - * calculation may bb slightly racy, so follow a read-again logic to ensure that > + * calculation may be slightly racy, so follow a read-again logic to ensure that > * the context is still active before returning the right timestamp. > * > * Returns: New ctx timestamp value > @@ -2584,6 +2584,8 @@ u64 xe_lrc_timestamp(struct xe_lrc *lrc) > engine_id = xe_lrc_engine_id(lrc); > if (!get_ctx_timestamp(lrc, engine_id, ®_ts)) > new_ts = reg_ts; > + else > + new_ts = lrc_ts; Sorry, don't understand this too well. But looks like here 'lrc_ts == CONTEXT_ACTIVE' which is not a real timestamp value (it's value is 1). So can we return that? See also the final 'if' statement in the function. > > /* read lrc again to ensure context is still active */ > lrc_ts = xe_lrc_ctx_timestamp(lrc); > -- > 2.51.0 >