mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Sebastian Frias <sf84@laposte.net>
Cc: Marc Zyngier <marc.zyngier@arm.com>,
	Jason Cooper <jason@lakedaemon.net>,
	LKML <linux-kernel@vger.kernel.org>, Mason <slash.tmp@free.fr>
Subject: Re: [PATCH] genirq: Generic chip: verify irqs_per_chip <= 32
Date: Fri, 2 Sep 2016 17:53:04 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.20.1609021749570.5647@nanos> (raw)
In-Reply-To: <57B31D94.5040701@laposte.net>

On Tue, 16 Aug 2016, Sebastian Frias wrote:
> Most (if not all) code here implicitly assumes that the maximum number of
> IRQs per chip will be 32, and thus uses 'u32' or 'unsigned long' for many
> tasks (for example "struct irq_data" declares its 'mask' field as 'u32',
> and "struct irq_chip_generic" declares its 'installed' field as 'unsigned
> long')
> 
> However, there is no check to verify that irqs_per_chip is <= 32.
> Hence, calling irq_alloc_domain_generic_chips() with a bigger value would
> result in unexpected results depending on how the 'mask' is accessed later
> on.
> For example, if set_bit() is used on the 'installed' field of "struct
> irq_chip_generic", it would result in the next field (in this case
> the 'unused' field) being overwritten, because set_bit() is designed to
> treat its parameter as a field of bits of arbitrary size organised as
> "unsigned long" words.

We really do not need examples for the potential wreckage. Your explanation
that the code has implict assumptions about the maximum number of
interrupts per chip is sufficient. We all know what out of bound access can
cause.

> This patch renames irq_alloc_domain_generic_chips() to
> __irq_alloc_domain_generic_chips() and creates a macro to replace it.
> The macro uses MAYBE_BUILD_BUG_ON to check the irqs_per_chip parameter to
> stop compilation (if the compiler can resolve the parameter to a constant
> at compile time) or to warn during run-time, if the parameter given is
> bigger than 32.

There is no point in explaining the implementation in the changelog. It's
obvious from the patch itself.

I'll fix that up as well.

Thanks,

	tglx

  reply	other threads:[~2016-09-02 15:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-16 14:05 Sebastian Frias
2016-09-02 15:53 ` Thomas Gleixner [this message]
2016-09-02 16:15 ` [tip:irq/core] genirq/generic_chip: Verify " tip-bot for Sebastian Frias
2016-09-02 18:25 ` tip-bot for Sebastian Frias
2016-08-19 16:35 [PATCH] genirq: Generic chip: verify " Sebastian Frias

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=alpine.DEB.2.20.1609021749570.5647@nanos \
    --to=tglx@linutronix.de \
    --cc=jason@lakedaemon.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=sf84@laposte.net \
    --cc=slash.tmp@free.fr \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®