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 E4992C2BD09 for ; Fri, 28 Jun 2024 17:36:46 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id B569010ECE8; Fri, 28 Jun 2024 17:36:46 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="AhWKwEPk"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.19]) by gabe.freedesktop.org (Postfix) with ESMTPS id 8B4B310E094 for ; Fri, 28 Jun 2024 17:36:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1719596205; x=1751132205; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=dMQFLKfEFVCZXzh3I4jsHJlCjlYMuqQ9ANQEeQJOtIw=; b=AhWKwEPkCTklMTgqcjHpMvJ2w2FYUndPilb0gkvGbKdX1My6ACY+Xj9C mP/sTrOTcRBG7ryH6VzY7cmjzwpMpEuTBSve38mi4iL53OmsOkzp7AvI0 8VTmiXj+vfhZdS3d1XBN/lC19z9pNS6CJaPdimPs3WMxtH69G2yU4hcLT qVamWatlk+lYVk9a67tw+Jpz6hzRpm8sD6N7tDrSLxUAy3VKNc98MP6x3 TN/yjAwVRRyplNzg3Y+U2o9lp/ey86qMRxMdtFOtGWICixM6EPa1v3UxJ P8emV/w3AWjj+3i/77XSkjvxLYiWVWd3r2vJ3RzbA74DTpXlYpKlAxy3n Q==; X-CSE-ConnectionGUID: D/iKuk/RSG6OeufH19onhQ== X-CSE-MsgGUID: In1vU5FdSyOamsDV9nGcAg== X-IronPort-AV: E=McAfee;i="6700,10204,11117"; a="16526084" X-IronPort-AV: E=Sophos;i="6.09,169,1716274800"; d="scan'208";a="16526084" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jun 2024 10:36:44 -0700 X-CSE-ConnectionGUID: m4mEzPaZSsyulXFQh6k2OA== X-CSE-MsgGUID: /ecOmjl3TfODCaBvPv7WQg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.09,169,1716274800"; d="scan'208";a="44918416" Received: from award-mobl1.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.125.48.221]) by orviesa009-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jun 2024 10:36:44 -0700 Date: Fri, 28 Jun 2024 10:31:36 -0700 Message-ID: <87msn5x9c7.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Umesh Nerlige Ramappa Cc: intel-xe@lists.freedesktop.org, Michal Wajdeczko Subject: Re: [PATCH] drm/xe/oa: Destroy the stream_lock mutex In-Reply-To: References: <20240628052125.1847989-1-ashutosh.dixit@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/29.3 (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 Fri, 28 Jun 2024 09:58:57 -0700, Umesh Nerlige Ramappa wrote: > > On Thu, Jun 27, 2024 at 10:21:25PM -0700, Ashutosh Dixit wrote: > > The mutex allocated in xe_oa_stream_init() was never previously > > destroyed. Do so now. > > > > Fixes: e936f885f1e9 ("drm/xe/oa/uapi: Expose OA stream fd") > > Cc: Michal Wajdeczko > > Signed-off-by: Ashutosh Dixit > > Reviewed-by: Umesh Nerlige Ramappa > > Since we are holding a drm reference, what is the logic behind using > drmm_mutex_init() for some mutexes and just a mutex_init for this one? I was sort of expecting this question :) So drmm_mutex_init() is being used for mutexes which are allocated in device probe, so they will be automatically freed in device unbind/remove. The mutex here is not a per device mutex, it's a per stream mutex. So better IMO to free it when the stream closes, so that's why an explicit mutex_destroy() during xe_oa_stream_destroy() here (since multiple OA streams can be opened/closed between probe and remove). (Though, considering that mutex_destroy() is a nop unless CONFIG_DEBUG_MUTEXES is set (see include/linux/mutex.h), drmm_mutex_init() will not be the end of the world either). But I thought just take the safe way out. Thanks. -- Ashutosh > > --- > > drivers/gpu/drm/xe/xe_oa.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/gpu/drm/xe/xe_oa.c b/drivers/gpu/drm/xe/xe_oa.c > > index 6cc3f0217341..4188516a7816 100644 > > --- a/drivers/gpu/drm/xe/xe_oa.c > > +++ b/drivers/gpu/drm/xe/xe_oa.c > > @@ -824,6 +824,8 @@ static void xe_oa_stream_destroy(struct xe_oa_stream *stream) > > > > WRITE_ONCE(u->exclusive_stream, NULL); > > > > + mutex_destroy(&stream->stream_lock); > > + > > xe_oa_disable_metric_set(stream); > > xe_exec_queue_put(stream->k_exec_q); > > > > -- > > 2.41.0 > >