From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932295AbcANTCP (ORCPT ); Thu, 14 Jan 2016 14:02:15 -0500 Received: from hqemgate16.nvidia.com ([216.228.121.65]:4168 "EHLO hqemgate16.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932252AbcANTCM (ORCPT ); Thu, 14 Jan 2016 14:02:12 -0500 X-PGP-Universal: processed; by hqnvupgp08.nvidia.com on Thu, 14 Jan 2016 11:03:33 -0800 Subject: Re: [PATCH V4 05/16] soc: tegra: pmc: Avoid extra remapping of PMC registers To: Thierry Reding References: <1449241037-22193-1-git-send-email-jonathanh@nvidia.com> <1449241037-22193-6-git-send-email-jonathanh@nvidia.com> <20160114134526.GA23082@ulmo> <5697CE50.2050004@nvidia.com> <20160114172459.GA32767@ulmo> CC: Philipp Zabel , Stephen Warren , Alexandre Courbot , Rafael Wysocki , Kevin Hilman , Ulf Hansson , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Vince Hsu , , , , From: Jon Hunter Message-ID: <5697F0AD.9080601@nvidia.com> Date: Thu, 14 Jan 2016 19:02:05 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20160114172459.GA32767@ulmo> X-Originating-IP: [10.21.132.159] X-ClientProxiedBy: UKMAIL102.nvidia.com (10.26.138.15) To UKMAIL101.nvidia.com (10.26.138.13) Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 14/01/16 17:24, Thierry Reding wrote: > * PGP Signed by an unknown key > > On Thu, Jan 14, 2016 at 04:35:28PM +0000, Jon Hunter wrote: >> >> On 14/01/16 13:45, Thierry Reding wrote: >>>> Old Signed by an unknown key >>> >>> On Fri, Dec 04, 2015 at 02:57:06PM +0000, Jon Hunter wrote: >>>> During early initialisation, the PMC registers are mapped and the PMC SoC >>>> data is populated in the PMC data structure. This allows other drivers >>>> access the PMC register space, via the public tegra PMC APIs, prior to >>>> probing the PMC device. >>>> >>>> When the PMC device is probed, the PMC registers are mapped again and if >>>> successful the initial mapping is freed. If the probing of the PMC device >>>> fails after the registers are remapped, then the registers will be >>>> unmapped and hence the pointer to the PMC registers will be invalid. This >>>> could lead to a potential crash, because once the PMC SoC data pointer is >>>> populated, the driver assumes that the PMC register mapping is also valid >>>> and a user calling any of the public tegra PMC APIs could trigger an >>>> exception because these APIs don't check that the mapping is still valid. >>>> >>>> Rather than adding a test to see if the PMC register mapping is valid, >>>> fix this by removing the second mapping of the PMC registers and reserve >>>> the memory region for the PMC registers during early initialisation where >>>> the initial mapping is created. During the probing of the PMC simply check >>>> that the PMC registers have been mapped. >>>> >>>> Signed-off-by: Jon Hunter >>>> --- >>>> drivers/soc/tegra/pmc.c | 19 +++++++++---------- >>>> 1 file changed, 9 insertions(+), 10 deletions(-) [snip] > Ah yes, of course. You could still do it with just the two pointers if > you keep the code as-is and revert back to the backed up value in case > of errors. Along this line: > > base = pmc->base; > > pmc->base = devm_ioremap_resource(&pdev->dev, res); > > /* on success */ > iounmap(base); > > /* on error */ > pmc->base = base; > > These pointer assignments should be atomic, so no potential for races > there. I've attached a patch which should do the trick, though I have > not tested it. Right, but I am concerned about someone calling tegra_powergate_set() (which with patch 6 of this series) will poll for the state to change. I am not sure we can guarantee the pointer does not change while this is happening. >> Even so, I was not sure if there could be a race here. >> Ideally, you would lock, but then you need to lock everywhere that you >> use base. Given that my patch still provides a /proc/iomem entry with a >> valid name, it seems best to me. > > The primary reason for the "takeover" is that except for the extra > iounmap() and pointer swapping the tegra_pmc_probe() function is really > a standard driver implementation. The idea behind this had always been > that it should be possible to easily convert this to a proper driver if > either we ended up with PSCI exclusively for SMP or defer SMP setup > until the PMC driver had been probed, so that we could get rid of the > early_initcall(). I agree it is cleaner, however, I am still concerned there could still be a race. Jon