Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754115AbbFSJtz (ORCPT ); Fri, 19 Jun 2015 05:49:55 -0400 Received: from foss.arm.com ([217.140.101.70]:44423 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753246AbbFSJtp (ORCPT ); Fri, 19 Jun 2015 05:49:45 -0400 Message-ID: <5583E5B3.7000701@arm.com> Date: Fri, 19 Jun 2015 10:49:39 +0100 From: Marc Zyngier Organization: ARM Ltd User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Hanjun Guo , Jason Cooper , Will Deacon , Catalin Marinas , "Rafael J. Wysocki" CC: Jiang Liu , Lorenzo Pieralisi , Arnd Bergmann , Tomasz Nowicki , "grant.likely@linaro.org" , Thomas Gleixner , Olof Johansson , "linux-arm-kernel@lists.infradead.org" , "linux-acpi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linaro-acpi@lists.linaro.org" Subject: Re: [PATCH 06/11] ACPI / gsi: Add gsi_mutex to synchronize acpi_register_gsi()/acpi_unregister_gsi() References: <1431953961-22706-1-git-send-email-hanjun.guo@linaro.org> <1431953961-22706-7-git-send-email-hanjun.guo@linaro.org> <55785E8D.1000909@arm.com> <55798A28.3080000@linaro.org> <5583C536.1060201@linaro.org> In-Reply-To: <5583C536.1060201@linaro.org> 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 Content-Length: 3658 Lines: 101 On 19/06/15 08:31, Hanjun Guo wrote: > On 06/11/2015 09:16 PM, Hanjun Guo wrote: >> On 06/10/2015 11:58 PM, Marc Zyngier wrote: >>> On 18/05/15 13:59, Hanjun Guo wrote: >>>> Add a mutex for acpi_register_gsi()/acpi_unregister_gsi() to avoid >>>> concurrency issues. >>>> >>>> Signed-off-by: Hanjun Guo >>>> --- >>>> drivers/acpi/gsi.c | 17 +++++++++++++---- >>>> 1 file changed, 13 insertions(+), 4 deletions(-) >>>> >>>> diff --git a/drivers/acpi/gsi.c b/drivers/acpi/gsi.c >>>> index 55b5f31..ab0dcb4 100644 >>>> --- a/drivers/acpi/gsi.c >>>> +++ b/drivers/acpi/gsi.c >>>> @@ -16,6 +16,7 @@ >>>> enum acpi_irq_model_id acpi_irq_model; >>>> /* ACPI core domian pointing to GICv2/3 core domain */ >>>> struct irq_domain *acpi_irq_domain __read_mostly; >>>> +static DEFINE_MUTEX(gsi_mutex); >>>> >>>> static unsigned int acpi_gsi_get_irq_type(int trigger, int polarity) >>>> { >>>> @@ -73,20 +74,24 @@ int acpi_register_gsi(struct device *dev, u32 >>>> gsi, int trigger, >>>> int irq; >>>> unsigned int irq_type = acpi_gsi_get_irq_type(trigger, polarity); >>>> >>>> + mutex_lock(&gsi_mutex); >>>> irq = irq_find_mapping(acpi_irq_domain, gsi); >>>> if (irq > 0) >>>> - return irq; >>>> + goto out; >>>> >>>> irq = irq_domain_alloc_irqs(acpi_irq_domain, 1, dev_to_node(dev), >>>> &gsi); >>>> if (irq <= 0) >>>> - return -EINVAL; >>>> + goto out; >>>> >>>> /* Set irq type if specified and different than the current one */ >>>> if (irq_type != IRQ_TYPE_NONE && >>>> irq_type != irq_get_trigger_type(irq)) >>>> irq_set_irq_type(irq, irq_type); >>>> - return irq; >>>> + >>>> +out: >>>> + mutex_unlock(&gsi_mutex); >>>> + return irq > 0 ? irq : -EINVAL; >>>> } >>>> EXPORT_SYMBOL_GPL(acpi_register_gsi); >>>> >>>> @@ -96,8 +101,12 @@ EXPORT_SYMBOL_GPL(acpi_register_gsi); >>>> */ >>>> void acpi_unregister_gsi(u32 gsi) >>>> { >>>> - int irq = irq_find_mapping(acpi_irq_domain, gsi); >>>> + int irq; >>>> + >>>> + mutex_lock(&gsi_mutex); >>>> + irq = irq_find_mapping(acpi_irq_domain, gsi); >>>> >>>> irq_dispose_mapping(irq); >>>> + mutex_unlock(&gsi_mutex); >>>> } >>>> EXPORT_SYMBOL_GPL(acpi_unregister_gsi); >>>> >>> >>> Can you point out why we need this locking? The rest of the kernel seems >>> to live without it pretty well. And if we really have an issue, I'd >> >> Hmm, I'm not so sure, I will look deep into that and come back later. > > Sorry for the late reply, I finally recalled that why I introduced > the lock here. > > The lock introduced here is because of I assume ACPI based container > (such as CPU socket) hotplug will be available on ARM64 in the future, > then we may online/offline a irqchip at the same time (similar way of > IOAPIC hotplug which introduced by Jiang Liu), it turns out that only > one GICD for now so it's not the case for ARM64 in the near future, Well, there can only be one GICD, or at least only one that is visible. If the HW uses multiple GICDs (one per socket?), it must make ensure that they are all synchronized transparently. That's a strong requirement from the architecture. Otherwise, we enter the FrankeinGIC realm, and ACPI has no business with it. > I will drop this patch in next version. Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/