From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (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 518A03A0E8E for ; Mon, 24 Aug 2026 07:54:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787558085; cv=none; b=eQImAZ1N2Yrhmx8/T9IAE8+F/2RWhn2bI1sCShFwRnc5zssNHA0aDIiRn32dTqi5LzDKYveVbyYSC42W6Ro/gRbWF70E1Accpr+EA22aPxjrgZhG8K6n426SWZYdsLANueY2DBGTbJdLmEmsjyPygPwcPlFoSjPI/jrhEKb6IbQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787558085; c=relaxed/simple; bh=oWAQb9cEuPErH543ngx2n2rVFJYJcJ9yLaplp7vKq74=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ccNUiOVhuyaURCaYFJ91P5NN0V5swZI1OI0M9ALdWTnHZVX1D3KGl33JUN7aWMQz5EhJb21djCW0lqNDf6kqnsMPWzms5mvOwp0AHqYIW91TL2L/Q8N6dgA2wwfdMTJzg9GUIS0u2gYGkfnDCrbCV+5sUqLPD3UJRg0TwiQFZHM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=E2yHCKXa; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="E2yHCKXa" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1787558082; bh=oWAQb9cEuPErH543ngx2n2rVFJYJcJ9yLaplp7vKq74=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=E2yHCKXaZ/0s9MZQ2lAS3NsQF5AtAP5AYbO+9MP4uyyvdQfGju6MmGoWE+UxnnImm h+8VneoSy904nJAonTPwwZW/gcZqxuU29Kudn1Z4KZVRM2Vvf2WIi38ibv149DjGFQ ErzD8jWxbkvLpz4OE+ppvfBfycpgyviRLJnm3VXiTV4mVI/AC5DMwKcGxnTPUvSxmf tz7toV3VIMz3hjVV3nwECKdtXpVzHb07GH2KK66beak4PdbSIZK0IVNcwxZudsHz9r Kvr4/X4et8tSNpCp0eMZTxUg7R+/fzFXa1vcarvgDZtirVY3uNpOpFXPy8B6RPRlLO gw76tU452FGQA== Received: from fedora-21.home (unknown [100.64.0.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange secp256r1 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bbrezillon) by bali.collaboradmins.com (Postfix) with ESMTPSA id 1C75517E00E9; Mon, 24 Aug 2026 09:54:42 +0200 (CEST) Date: Mon, 24 Aug 2026 09:54:37 +0200 From: Boris Brezillon To: Steven Price Cc: Liviu Dudau , Chia-I Wu , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v6 5/9] drm/panthor: Get rid of panthor_group::fatal_lock Message-ID: <20260824095437.268a849e@fedora-21.home> In-Reply-To: <44deb321-aa09-44f1-beb9-86a4d7eea1f4@arm.com> References: <20260811-panthor-signal-from-irq-v6-0-12f2ab53d735@collabora.com> <20260811-panthor-signal-from-irq-v6-5-12f2ab53d735@collabora.com> <44deb321-aa09-44f1-beb9-86a4d7eea1f4@arm.com> Organization: Collabora X-Mailer: Claws Mail 4.4.0 (GTK 3.24.52; x86_64-redhat-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 17 Aug 2026 16:12:22 +0100 Steven Price wrote: > On 11/08/2026 12:23, Boris Brezillon wrote: > > This lock is never used, and we're about to make fatal_queues an > > atomic to cope with concurrent updates. > > > > Signed-off-by: Boris Brezillon > > Reviewed-by: Steven Price > > Although it does make me wonder if there's a fix that needs backporting... I've audited all places where this field is accessed, and I think we're covered by the panthor_scheduler::lock. The only place where this is not the case is group_term_post_processing(), and I believe the fatal_queues value is frozen at this point (can't be updated by IRQ logic because the group has left its CSG slot).