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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 20 Sep 2019 16:52:37 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     "Sverdlin, Alexander (Nokia - DE/Ulm)" <alexander.sverdlin@...ia.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Grant Likely <grant.likely@...retlab.ca>
Cc:     Mark Brown <broonie@...nsource.wolfsonmicro.com>,
        Jon Hunter <jonathanh@...dia.com>,
        "Glavinic-Pecotic, Matija (EXT - DE/Ulm)" 
        <matija.glavinic-pecotic.ext@...ia.com>,
        "Adamski, Krzysztof (Nokia - PL/Wroclaw)" 
        <krzysztof.adamski@...ia.com>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [PATCH 2/3] genirq/irqdomain: Re-check mapping after associate in
 irq_create_mapping()

On 12/09/2019 10:44, Sverdlin, Alexander (Nokia - DE/Ulm) wrote:
> From: Alexander Sverdlin <alexander.sverdlin@...ia.com>
> 
> If two irq_create_mapping() calls perform a mapping of the same hwirq on
> two CPU cores in parallel they both will get 0 from irq_find_mapping(),
> both will allocate unique virq using irq_domain_alloc_descs() and both
> will finally irq_domain_associate() it. Giving different virq numbers
> to their callers.
> 
> In practice the first caller is usually an interrupt controller driver and
> the seconds is some device requesting the interrupt providede by the above
> interrupt controller.

I disagree with this "In practice". An irqchip controller should *very
rarely* call irq_create_mapping on its own. It usually indicates some
level of brokenness, unless the mapped interrupt is exposed by the
irqchip itself (the GIC maintenance interrupt, for example).

> In this case either the interrupt controller driver configures virq which
> is not the one being "associated" with hwirq, or the "slave" device
> requests the virq which is never being triggered.

Why should the interrupt controller configure that interrupt? On any
sane platform, the mapping should be created by the user of the
interrupt, and not by the provider.

This doesn't mean we shouldn't fix the irqdomain races, but I tend to
disagree with the analysis here.

> 
> Cc: stable@...r.kernel.org
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@...ia.com>
> ---
>  kernel/irq/irqdomain.c | 13 +++++--------
>  1 file changed, 5 insertions(+), 8 deletions(-)
> 
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index 7bc07b6..176f2cc 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -675,13 +675,6 @@ unsigned int irq_create_mapping(struct irq_domain *domain,
>  
>  	of_node = irq_domain_get_of_node(domain);
>  
> -	/* Check if mapping already exists */
> -	virq = irq_find_mapping(domain, hwirq);
> -	if (virq) {
> -		pr_debug("-> existing mapping on virq %d\n", virq);
> -		return virq;
> -	}
> -
>  	/* Allocate a virtual interrupt number */
>  	virq = irq_domain_alloc_descs(-1, 1, hwirq, of_node_to_nid(of_node), NULL);
>  	if (virq <= 0) {
> @@ -691,7 +684,11 @@ unsigned int irq_create_mapping(struct irq_domain *domain,
>  
>  	if (irq_domain_associate(domain, virq, hwirq)) {
>  		irq_free_desc(virq);
> -		return 0;
> +
> +		virq = irq_find_mapping(domain, hwirq);
> +		if (virq)
> +			pr_debug("-> existing mapping on virq %d\n", virq);

I'd rather you limit this second irq_find_mapping() to cases where we're
sure we've found a duplicate:

	ret = irq_domain_associate(domain, virq, hwirq);
	if (ret) {
		irq_free_desc(virq);
		if (ret == -EEXIST)
			return irq_find_mapping(domain, hwirq);

		return 0;
	}

> +		return virq;
>  	}
>  
>  	pr_debug("irq %lu on domain %s mapped to virtual irq %u\n",
> 

Thanks,

	M.
-- 
Jazz is not dead, it just smells funny...

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ