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:	Mon, 26 Nov 2012 20:26:01 +0000
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Linus Walleij <linus.walleij@...ricsson.com>,
	linux-kernel@...r.kernel.org,
	Rob Herring <rob.herring@...xeda.com>,
	Thomas Gleixner <tglx@...utronix.de>
Cc:	Anmar Oueja <anmar.oueja@...aro.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	Paul Mundt <lethal@...ux-sh.org>,
	Russell King <linux@....linux.org.uk>,
	Lee Jones <lee.jones@...aro.org>
Subject: Re: [PATCH 2/4 v2] irqdomain: augment add_simple() to allocate descs

On Mon, 1 Oct 2012 09:35:22 +0200, Linus Walleij <linus.walleij@...ricsson.com> wrote:
> From: Linus Walleij <linus.walleij@...aro.org>
> 
> Currently we rely on all IRQ chip instances to dynamically
> allocate their IRQ descriptors unless they use the linear
> IRQ domain. So for irqdomain_add_legacy() and
> irqdomain_add_simple() the caller need to make sure that
> descriptors are allocated.
> 
> Let's slightly augment the yet unused irqdomain_add_simple()
> to also allocate descriptors as a means to simplify usage
> and avoid code duplication throughout the kernel.
> 
> We warn if descriptors cannot be allocated, e.g. if a
> platform has the bad habit of hogging descriptors at boot
> time.
> 
> Cc: Rob Herring <rob.herring@...xeda.com>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: Grant Likely <grant.likely@...retlab.ca>
> Cc: Paul Mundt <lethal@...ux-sh.org>
> Cc: Russell King <linux@....linux.org.uk>
> Cc: Lee Jones <lee.jones@...aro.org>
> Signed-off-by: Linus Walleij <linus.walleij@...aro.org>
> ---
> ChangeLog v1->v2:
> - Switch descriptor allocation on IS_ENABLED(CONFIG_SPARSE_IRQ)
>   so it won't attempt to allocate descriptors in the non-sparse
>   case.
> - Use of_node_to_nid() to make sure we work on platforms with their
>   own node concept.
> - Specify irq_alloc_descs(first_irq, first_irq ...) to emulate
>   irq_alloc_desc_at().
> ---
>  kernel/irq/irqdomain.c | 33 ++++++++++++++++++++++++++++-----
>  1 file changed, 28 insertions(+), 5 deletions(-)
> 
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index 49a7772..4e69e24 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -148,7 +148,8 @@ static unsigned int irq_domain_legacy_revmap(struct irq_domain *domain,
>   * @host_data: Controller private data pointer
>   *
>   * Allocates a legacy irq_domain if irq_base is positive or a linear
> - * domain otherwise.
> + * domain otherwise. For the legacy domain, IRQ descriptors will also
> + * be allocated.
>   *
>   * This is intended to implement the expected behaviour for most
>   * interrupt controllers which is that a linear mapping should
> @@ -162,11 +163,33 @@ struct irq_domain *irq_domain_add_simple(struct device_node *of_node,
>  					 const struct irq_domain_ops *ops,
>  					 void *host_data)
>  {
> -	if (first_irq > 0)
> -		return irq_domain_add_legacy(of_node, size, first_irq, 0,
> +	if (first_irq > 0) {
> +		int irq_base;
> +
> +		if (IS_ENABLED(CONFIG_SPARSE_IRQ)) {
> +			/*
> +			 * Set the descriptor allocator to search for a
> +			 * 1-to-1 mapping, such as irq_alloc_desc_at().
> +			 * Use of_node_to_nid() which is defined to
> +			 * numa_node_id() on platforms that have no custom
> +			 * implementation.
> +			 */
> +			irq_base = irq_alloc_descs(first_irq, first_irq, size,
> +						   of_node_to_nid(of_node));
> +			if (irq_base < 0) {
> +				WARN(1, "Cannot allocate irq_descs @ IRQ%d, assuming pre-allocated\n",
> +				     first_irq);
> +				irq_base = first_irq;

As I just commented on the previous version, WARN() is probably too
verbose (and scary). Make it an informational.

However, I see another problem. What is the requested range straddles
the boundary between reserved and non-reserved IRQs? It would be good to
give some information about which irq range was requested and maybe
report which ones were available.... or check to see if the request is
inside or partially inside the reserved region?

g.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ