All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
To: linux-kernel@vger.kernel.org
Cc: tglx@linutronix.de, lars@metafoo.de
Subject: [RFC] genirq: prevent allocated_irqs from being smaller than NR_IRQS
Date: Thu, 2 Apr 2020 12:08:20 -0300	[thread overview]
Message-ID: <20200402150820.GB5886@smtp.gmail.com> (raw)

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?

By the way, is there any mailing list for IRQ related discussions?
I couldn't find one at vger.kernel.org.


Thanks,

Marcelo

             reply	other threads:[~2020-04-02 15:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-02 15:08 Marcelo Schmitt [this message]
2020-04-02 15:16 ` [RFC] genirq: prevent allocated_irqs from being smaller than NR_IRQS Lars-Peter Clausen
2020-04-02 17:25   ` Marcelo Schmitt
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=20200402150820.GB5886@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.