linux-kernel - Common clock framework: mutex recursion when calling clk

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <3826517.zOi8FASM36@avalon>
Date:	Mon, 07 Jan 2013 01:49:02 +0100
From:	Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-omap@...r.kernel.org
Cc:	mturquette@...com
Subject: Common clock framework: mutex recursion when calling clk_prepare from prepare handler

Hello,

I ran into a mutex recursion issue while trying to port the OMAP3 ISP driver 
(drivers/media/platform/omap3isp) over to the common clock framework.

The OMAP3 ISP generates two programmable clocks named xclka and xclkb that are 
routed out of the SoC. My goal is to expose them as common clock instances 
through the common clock framework.

The xclk[ab] clocks are children of the cam_mclk clock. They are controlled 
through ISP registers that sit in the cam_fclk clock domain. The cam_mclk and 
cam_fclk clocks sit in separate power domains.

To program the xclk clocks I need to enable the cam_fclk clock. As xclk[ab] 
are not descendants of the cam_fclk clock, this operation needs to be 
performed manually. I thus call clk_prepare_enable on the cam_fclk clock in 
the xclk[ab] prepare handler. This is where things break, as the common clock 
framework takes the prepare_lock mutex in clk_prepare, which results in a 
mutex recursion deadlock as the prepare_lock mutex isn't recursive.

What's the best way to solve this ? __clk_prepare (the unlocked version of 
clk_prepare) isn't exported to drivers, and I'm not convinced it should be. 
Turning prepare_lock into a recursive mutex might also work, but I'm not sure 
what drawbacks this would have. Advices would be appreciated.

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/