All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
To: Lars-Peter Clausen <lars@metafoo.de>
Cc: linux-kernel@vger.kernel.org, tglx@linutronix.de
Subject: Re: [RFC] genirq: prevent allocated_irqs from being smaller than NR_IRQS
Date: Thu, 2 Apr 2020 14:25:10 -0300	[thread overview]
Message-ID: <20200402172510.GA8242@smtp.gmail.com> (raw)
In-Reply-To: <66fabdd6-7815-1ede-9a45-45fdb2b6d5b2@metafoo.de>

On 04/02, Lars-Peter Clausen wrote:
> On 4/2/20 5:08 PM, Marcelo Schmitt wrote:
> > Hi,
> > 
> > I was trying to understand IRQ initialization when suddenly got
> > intrigued about the declaration of the "allocated_irqs" bitmap at
> > kernel/irq/irqdesc.c. The size of allocated_irqs is defined by
> > IRQ_BITMAP_BITS, which in turn is passed to BITS_TO_LONGS to calculate
> > the actual number of IRQs the system may have. If I got it right, there
> > should be one entry at allocated_irqs for each possible IRQ line. At
> > kernel/irq/internals.h, IRQ_BITMAP_BITS is defined to be NR_IRQS (or
> > NR_IRQS plus a high constant in the case of sparse IRQs), which most
> > architectures seem to define as being the actual number of IRQs a board
> > has.
> > 
> > #ifdef CONFIG_SPARSE_IRQ
> > # define IRQ_BITMAP_BITS (NR_IRQS + 8196)
> > #else
> > # define IRQ_BITMAP_BITS NR_IRQS
> > #endif
> > 
> > The thing I'm troubled about is that BITS_TO_LONGS divides
> > IRQ_BITMAP_BITS by sizeof(long) * 8, which makes it possible for the
> > size of allocated_irqs to be smaller than NR_IRQS.
> > 
> > For instance, if !CONFIG_SPARSE_IRQ, sizeof(long) == 8, and NR_IRQS is
> > defined as 16, then IRQ_BITMAP_BITS would be equal to
> > (16 + 64 - 1)/64 = 1. Even if CONFIG_SPARSE_IRQ is defined, a device
> > with a large number of IRQ lines would end up with a small bitmap for
> > allocated_irqs.
> > 
> > I thought NR_IRQS would be multiplied by the number of bits it uses.
> > Something like:
> > 
> > #ifdef CONFIG_SPARSE_IRQ
> > # define IRQ_BITMAP_BITS (NR_IRQS * BITS_PER_TYPE(long) + 8196)
> > #else
> > # define IRQ_BITMAP_BITS (NR_IRQS * BITS_PER_TYPE(long))
> > #endif
> > 
> > Anyhow, IRQ_BITMAP_BITS is also used to limit the maximum number of IRQs
> > at irqdesc.c. If my understanding of nr_irqs is correct, it would make
> > sense to change some sanity checks at early_irq_init() too.
> > 
> > Does anyone mind giving me some advice on how allocated_irqs is
> > initialized with a suitable size to support the number of interrupt
> > lines a board may have?
> 
> Maybe I'm missing something, but allocated_irqs is a bitmap. This means each
> bit corresponds to one IRQ. if sizeof(long) is 8 and allocated_irqs is sized
> to be one long that means it is large enough for 64 IRQs.

Probably that's what I was missing about the allocated_irqs use.
This explains a lot.

Many thanks,

Marcelo

> 
> - Lars
> 

  reply	other threads:[~2020-04-02 17:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-02 15:08 [RFC] genirq: prevent allocated_irqs from being smaller than NR_IRQS Marcelo Schmitt
2020-04-02 15:16 ` Lars-Peter Clausen
2020-04-02 17:25   ` Marcelo Schmitt [this message]
2020-04-02 19:17 ` Thomas Gleixner
2020-04-02 23:23   ` Marcelo Schmitt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200402172510.GA8242@smtp.gmail.com \
    --to=marcelo.schmitt1@gmail.com \
    --cc=lars@metafoo.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.