From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 CA5F044A725 for ; Tue, 16 Jun 2026 15:29:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781623768; cv=none; b=pjR5ZBSMOFbby1DRzQRlbpN4uGSLkUcKejpFX+Cr6WcrHmhv4Sc4EIBaoJ4aoOs5I78grGor+glK/ODkYf7HA7bu6OlvdmCCDJrCw/1DwcDUsjtuZgMCUldVdpmABVP6FcjK/MXNR3IjcgU/tiC2YbvihHheOo9SjxD1c+66WfA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781623768; c=relaxed/simple; bh=sxzPhX3pkJ8STn/s9leDYKjWUXMzWDQoG8ir5CIn3CY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=kRPexKNCradmGCIFw8F1mb6RquAPIXJHPDC6Fa20SlFrK1PzziIZEehJUHLA/TCJqsabA1gXhwZTG0iChR54/bBAJ5a/YoFhaCvEyVQJLLb+4Zkgerfz0PGTHHxNPOhPMP6geBU15WZXfbHl++WjXqCSD3jtOXoGbm63Rdow++4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YI+KDXyX; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="YI+KDXyX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D148A1F00A3A; Tue, 16 Jun 2026 15:29:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781623766; bh=eFxrHPeVMv35WCYKKiWqiAydCveSL3x1ksY5DFkpIek=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=YI+KDXyX74hxLCPBRICJUnLXcVK6U7+/IXX03LoZZ/0QI9PQNrxUDDXOWMAIIrwNb zWNIvC5/bfBgRsaENem9N9gyjYTZvH+lrD0nPrYLtWwJPS8o+9Lj72/hPW1SkXZOJi o2k4q5pijVvGlojOoye+sOdzfux505vkKBmQuVnuWHxag6PyjYaVHqnfTG6CTUaEhR /7lKURDV4csDVS9KgEaOvnfXTOs9j1aD8dsZvbGYZvN42HiJ8fJVBIEymjKRY6w2V0 SQqmN3LDXsBwfqpAtvh6JSrlVy+TCh957inBPh81A4si2ocaX7+u0ffaTNYYAvPtBD hR13/cZ7/h3Ww== Date: Tue, 16 Jun 2026 16:29:22 +0100 From: Conor Dooley To: Pengpeng Hou Cc: Jonathan Cameron , Paul Walmsley , Samuel Holland , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] cache: sifive_ccache: remove debugfs on driver register failure Message-ID: <20260616-fossil-labored-ea8b8b08c856@spud> References: <20260616151314.87102-1-pengpeng@iscas.ac.cn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DJ26ZYpqGmXav2NH" Content-Disposition: inline In-Reply-To: <20260616151314.87102-1-pengpeng@iscas.ac.cn> --DJ26ZYpqGmXav2NH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 16, 2026 at 11:13:14PM +0800, Pengpeng Hou wrote: > sifive_ccache_init() creates the debugfs injection file before > registering the platform driver. If platform_driver_register() fails, the > error path unmaps ccache_base while the debugfs file remains and its > write callback still uses that global mapping. >=20 > Remove the debugfs tree before unmapping the cache controller registers > on the registration failure path. >=20 > Signed-off-by: Pengpeng Hou > --- > drivers/cache/sifive_ccache.c | 12 +++++++++++- > 1 file changed, 11 insertions(+), 1 deletion(-) >=20 > diff --git a/drivers/cache/sifive_ccache.c b/drivers/cache/sifive_ccache.c > index a86800b123b9..cf7877d8e3e5 100644 > --- a/drivers/cache/sifive_ccache.c > +++ b/drivers/cache/sifive_ccache.c > @@ -100,6 +100,12 @@ static void setup_sifive_debug(void) > debugfs_create_file("sifive_debug_inject_error", 0200, > sifive_test, NULL, &ccache_fops); > } > + > +static void remove_sifive_debug(void) > +{ > + debugfs_remove_recursive(sifive_test); > + sifive_test =3D NULL; Firstly, do we really need a function for this? Secondly, is there any reason to actually explicitly NULL this after we're done removing? The driver has failed to probe so it's not as if something is going to refer to this dentry pointer anyway? Am I missing something? Cheers, Conor. > +} > #endif > =20 > static void ccache_config_read(void) > @@ -336,12 +342,16 @@ static int __init sifive_ccache_init(void) > =20 > rc =3D platform_driver_register(&sifive_ccache_driver); > if (rc) > - goto err_unmap; > + goto err_remove_debug; > =20 > of_node_put(np); > =20 > return 0; > =20 > +err_remove_debug: > +#ifdef CONFIG_DEBUG_FS > + remove_sifive_debug(); > +#endif > err_unmap: > iounmap(ccache_base); > err_node_put: > --=20 > 2.43.0 >=20 --DJ26ZYpqGmXav2NH Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCajFrzwAKCRB4tDGHoIJi 0mSqAPoCMsVmRRUk4H9aIzfxB3cXd/R8bMloIGhVGiSAk5wUjQD8DLBvxG4dZL6J 1bHtOxa2mtWPVGV0kTQJtwYe1D8DdgU= =T7EI -----END PGP SIGNATURE----- --DJ26ZYpqGmXav2NH--