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 2054ECA100A for ; Fri, 30 Aug 2024 23:08:54 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id A299510E5C0; Fri, 30 Aug 2024 23:08:53 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="G7GQLhLw"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.19]) by gabe.freedesktop.org (Postfix) with ESMTPS id 3D92B10E5C0 for ; Fri, 30 Aug 2024 23:08:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1725059332; x=1756595332; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=iXodf0bEadT5ubmQBqDzEhReH0QKnfJbEd1f7ANee+A=; b=G7GQLhLwh2wpqj/N+zO+5qqQytz/1dnogxdOYrlviWMWJzAS9YxsxBRQ OPCqZyhW+wuMzruSWr4uAZ03BbtrgJWhg4g7ypCVCtb1qOdLVngoipbfD gJZouOLZQfwEqVmcePlrd1yjkCZirShS/3qNj6THTksQlJ1Lald2M9HjW IONN0FtLvj9dS1roG6R4jLIR0z83e9UoNfd0nyLdcHnM3enCmbpwPH4pX MbSAP1xZSWdWoEsjuPYG1BIrrInGtIHMkoaV+ZpuOf4OrpbRR5KNLfUUz d6qiQ43HdpTSMb2h1n4d2MkxWAk2cw2UaYGXk3FdqvvzOzjiP3QVra68t w==; X-CSE-ConnectionGUID: PKsBYloESmSLwPn4CITkHg== X-CSE-MsgGUID: VJZ3UbsaTvuNzFrIgy+sig== X-IronPort-AV: E=McAfee;i="6700,10204,11180"; a="23291371" X-IronPort-AV: E=Sophos;i="6.10,190,1719903600"; d="scan'208";a="23291371" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Aug 2024 16:08:52 -0700 X-CSE-ConnectionGUID: 7KN/fUOzRrmXLy8We5Fj6A== X-CSE-MsgGUID: nmoI71U+SeqJO0Wno6+ruA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,190,1719903600"; d="scan'208";a="87272389" Received: from bholling-mobl.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.124.22.42]) by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Aug 2024 16:08:52 -0700 Date: Fri, 30 Aug 2024 15:58:59 -0700 Message-ID: <87cylphb2k.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Matthew Brost Cc: intel-xe@lists.freedesktop.org Subject: Re: [PATCH 4/7] drm/xe/oa: Signal output fences In-Reply-To: References: <20240830221618.2103948-1-ashutosh.dixit@intel.com> <20240830221618.2103948-5-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.4 (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, 30 Aug 2024 15:45:17 -0700, Matthew Brost wrote: > > On Fri, Aug 30, 2024 at 03:16:15PM -0700, Ashutosh Dixit wrote: > > Introduce 'struct xe_oa_fence' which includes the dma_fence used to signal > > output fences in the xe_sync array. The fences are signaled > > asynchronously. When there are no output fences to signal, the OA > > configuration wait is synchronously re-introduced into the ioctl. > > > > v2: Don't wait in the work, use callback + delayed work (Matt B) > > Use a single, not a per-fence spinlock (Matt Brost) > > v3: Move ofence alloc before job submission (Matt) > > Assert, don't fail, from dma_fence_add_callback (Matt) > > Additional dma_fence_get for dma_fence_wait (Matt) > > Change dma_fence_wait to non-interruptible (Matt) > > v4: Introduce last_fence to prevent uaf if stream is closed with > > pending OA config jobs > > The usage looks correct, so RB holds. > > One suggestion which can be done in a follow up. I had to check the > locking to make this this was correct (i.e. a mutex at the outer > layer was held to make this serial) and didn't notice any lockdep > annotations in your code. Lockdep is good catching problems but also > self documenting which helps to review / maintain code. If possible > maybe sprilke in lockdep annotation in the OA code. Thanks Matt, yep, will try to figure out and do this as follow up. Thanks. -- Ashutosh