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 A2065CDD552 for ; Wed, 18 Sep 2024 19:59:50 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 6C4B010E1B5; Wed, 18 Sep 2024 19:59:50 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="JXckiuVc"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.18]) by gabe.freedesktop.org (Postfix) with ESMTPS id AE6DD10E1B5 for ; Wed, 18 Sep 2024 19:59:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1726689590; x=1758225590; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=J6pk2D90o8ahUhAVzXlLP2lnMnGcaEkoqA2l1iaXJf8=; b=JXckiuVcbR2/B4GjzKzT0nh7CTHHVs+ahYdkiX7g7GS+oBRZZS61qJYw xO/sGoC+5gnHbVxZ1/IslPOisGVUeJpR5ZJp9AkkrbzKhRUSSqmx7v9Xa qlTE+eq/vfV+kj8y9C/6ietTC+F0J0o+KaX3wh6dl3ihlfE+YliJoih08 6roOqIo+Jx8hyyuPKpYjcjf7Lp6obJd86crV0Bkk6syej36FSXsJi8Nbd oXUgpWEzFrbdtWYl8/V0pblUaTjqmh/FszqxnbekdpFM6D06DTiOyUFVw /lH7+T9qYfFXP91ANjC3pmnLvU1YNZxa4B6YiCibDam5at0kQ/PZot16s g==; X-CSE-ConnectionGUID: 0NC0aK8gRNW4sHdn3xRhGg== X-CSE-MsgGUID: 2xHfu1ePQD+xt7/rYtQZCg== X-IronPort-AV: E=McAfee;i="6700,10204,11199"; a="25746061" X-IronPort-AV: E=Sophos;i="6.10,239,1719903600"; d="scan'208";a="25746061" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Sep 2024 12:59:50 -0700 X-CSE-ConnectionGUID: MI89YF+NT/Cb3KokCX3akA== X-CSE-MsgGUID: Ur8qzphFRVuDPywgduX2sw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,239,1719903600"; d="scan'208";a="92987039" Received: from orsosgc001.jf.intel.com (HELO orsosgc001.intel.com) ([10.165.21.138]) by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Sep 2024 12:59:49 -0700 Date: Wed, 18 Sep 2024 12:59:48 -0700 Message-ID: <85bk0k7mx7.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> <85ed5h7wmc.wl-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/28.2 (x86_64-redhat-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 Tue, 17 Sep 2024 16:38:43 -0700, Matthew Brost wrote: > > > > + dma_fence_init(&ofence->base, &xe_oa_fence_ops, &stream->oa_fence_lock, 0, 0); > > > > About stream->oa_fence_lock. This was added in response to this comment > > from you in v1 of this patch: > > > > /* No per fence spin lock, global OA one for user_signal */ > > > > here: > > https://patchwork.freedesktop.org/patch/607602/?series=137058&rev=1#comment_1104327 > > > > However, I just realized that, the way it is implemented, there is a uaf > > here: lock memory can be freed before the lock is accessed in > > dma_fence_signal() in xe_oa_fence_work_fn() (when the oa stream is > > destroyed). > > > > Of course we can implement some reference counting etc. to solve the uaf, > > but the simplest way to solve it seems to be to go back to the per-fence > > lock, unless doing so is incorrect? Looking at dma_fence_init calls, I do > > see per fence locks being used occasionally (xe_preempt_fence, vgem_fence > > etc.). > > > > So just want to check with you if it's ok to go back to the per fence lock, > > or we should solve it some other way. > > > > Yea my bad on that suggestion. That is an issue, just move the lock back > to the fence. No problem, thanks, I've moved the lock back into the fence in the latest version. Ashutosh