From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [80.241.56.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E63F8210E9 for ; Sat, 14 Sep 2024 14:44:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.241.56.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1726325081; cv=none; b=cVJRGsc3T1gFgX0AJwGZ3YjrrRqOWqcmSLZ8oA8kj4R8HdQHBo8ACnKIO2Vd0pgrrPtP7rJ+rlLWEmYlmeqxvyI8M5ccXf9skVU8iW1Rqr5SDR0F+cZXPuxRH74O/h19EMIcAZC/qqIybPIjSZXTnORxO0xD3weGxnDTV4Sbnlg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1726325081; c=relaxed/simple; bh=eDmbSYr/29LOECwYoLWHr95f/FGhTJ9MDkRBYjODs/Y=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=WkaeDC0SXbiGNcwiJRiY+0R24eTdQLu2GNf/39hFZm7hiG2M+I2STRrCIFmHBGpS7claumXzyKdiat4rQcJFRPqhKEOXakm0+PLCvoi95fztH8OoqkH1Wn2tjX4RRPNDV+h//0T0wJlMmPfrThhXXgtDpTCmeKXAM8n6TshmC1s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=mailbox.org; spf=pass smtp.mailfrom=mailbox.org; dkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org header.b=EqFXdrlx; arc=none smtp.client-ip=80.241.56.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=mailbox.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mailbox.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org header.b="EqFXdrlx" Received: from smtp1.mailbox.org (smtp1.mailbox.org [10.196.197.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4X5Yq56Prkz9tDK; Sat, 14 Sep 2024 16:44:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1726325073; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ihSJ9eF4ScrNd9BOfaQDzUXZj/8RZhBWCPJuGCfS0ZQ=; b=EqFXdrlxdQ6rsT3KnO5yBD4xwPzuUalpJb2o2+7Ub8HK+QTu9k3ROi0oU3OxCBT8vH+By7 xZgW2B1Z9gGQie0vzhLjixm6mbk6ZBy/Dykl9EvhUQfOzFXziUQfITgkaakZ9NtDEoyQ2Q fIBTx0RIirLVRKW2MMMQoE/scsQ9+cDJx020mqDrcBfR7UdL2+xbH/UHFD8Hif3Q8F5WKZ 47HKnU+wfNSQh2yT9sXna8CSAJ1zRk/fTWdsEjsS8eTyFFzGyQFJ9bfdMVKZCiHL3g48ia 4RaNa5lo83TzhCP4tvgJERDEbSqLgWC85jPGvhEJN/hpIHTcpVdq+9qeHiwa8A== Message-ID: Date: Sat, 14 Sep 2024 16:44:29 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH] drm/sched: Fix dynamic job-flow control race To: Rob Clark Cc: dri-devel@lists.freedesktop.org, Rob Clark , Asahi Lina , Luben Tuikov , Matthew Brost , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , Danilo Krummrich , open list References: <20240913165326.8856-1-robdclark@gmail.com> From: =?UTF-8?Q?Michel_D=C3=A4nzer?= Content-Language: en-CA In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MBO-RS-META: y15k1xc6apq5unq74trq3f3cycbg7zzq X-MBO-RS-ID: ee693a0b81cceefaf31 On 2024-09-13 19:28, Rob Clark wrote: > On Fri, Sep 13, 2024 at 10:03 AM Michel Dänzer > wrote: >> >> On 2024-09-13 18:53, Rob Clark wrote: >>> From: Rob Clark >>> >>> Fixes a race condition reported here: https://github.com/AsahiLinux/linux/issues/309#issuecomment-2238968609 >>> >>> The whole premise of lockless access to a single-producer-single- >>> consumer queue is that there is just a single producer and single >>> consumer. That means we can't call drm_sched_can_queue() (which is >>> about queueing more work to the hw, not to the spsc queue) from >>> anywhere other than the consumer (wq). >>> >>> This call in the producer is just an optimization to avoid scheduling >>> the consuming worker if it cannot yet queue more work to the hw. It >>> is safe to drop this optimization to avoid the race condition. >>> >>> Suggested-by: Asahi Lina >>> Fixes: a78422e9dff3 ("drm/sched: implement dynamic job-flow control") >>> Signed-off-by: Rob Clark >>> --- >>> drivers/gpu/drm/scheduler/sched_main.c | 3 +-- >>> 1 file changed, 1 insertion(+), 2 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c >>> index ab53ab486fe6..1af1dbe757d5 100644 >>> --- a/drivers/gpu/drm/scheduler/sched_main.c >>> +++ b/drivers/gpu/drm/scheduler/sched_main.c >>> @@ -1020,8 +1020,7 @@ EXPORT_SYMBOL(drm_sched_job_cleanup); >>> void drm_sched_wakeup(struct drm_gpu_scheduler *sched, >>> struct drm_sched_entity *entity) >>> { >>> - if (drm_sched_can_queue(sched, entity)) >>> - drm_sched_run_job_queue(sched); >>> + drm_sched_run_job_queue(sched); >>> } >>> >>> /** >> >> The entity parameter is unused now. > > Right.. and we probably should collapse drm_sched_wakeup() and > drm_sched_run_job_queue().. I looked into that as well, seems fine to leave them separate for now though. > But this fix needs to be cherry picked back to a bunch of release > branches, so I intentionally avoided refactoring as part of the fix. Fixing up the drm_sched_wakeup caller(s) when backporting doesn't seem like a big deal. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast