linux-kernel - Re: [PATCH 02/14] ARM: ARMv7M: Enlarge vector table to 256 entries

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]

Message-ID: <CAL_Jsq+WPbUE7mqmyfi2kUreis0cXM2EC8dJLTD3HOBXsFAzuA@mail.gmail.com>
Date:	Thu, 19 Feb 2015 10:35:49 -0600
From:	Rob Herring <robherring2@...il.com>
To:	Maxime Coquelin <mcoquelin.stm32@...il.com>
Cc:	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Jonathan Corbet <corbet@....net>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Philipp Zabel <p.zabel@...gutronix.de>,
	Russell King <linux@....linux.org.uk>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Walleij <linus.walleij@...aro.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Slaby <jslaby@...e.cz>, Arnd Bergmann <arnd@...db.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"David S. Miller" <davem@...emloft.net>,
	Mauro Carvalho Chehab <mchehab@....samsung.com>,
	Joe Perches <joe@...ches.com>, Antti Palosaari <crope@....fi>,
	Tejun Heo <tj@...nel.org>, Will Deacon <will.deacon@....com>,
	Nikolay Borisov <Nikolay.Borisov@....com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Kees Cook <keescook@...omium.org>,
	Michal Marek <mmarek@...e.cz>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	"linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
	Linux-Arch <linux-arch@...r.kernel.org>,
	"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>
Subject: Re: [PATCH 02/14] ARM: ARMv7M: Enlarge vector table to 256 entries

On Thu, Feb 19, 2015 at 10:13 AM, Maxime Coquelin
<mcoquelin.stm32@...il.com> wrote:
> Hi Rob,
>
> 2015-02-15 23:42 GMT+01:00 Rob Herring <robherring2@...il.com>:
>> On Fri, Feb 13, 2015 at 2:42 AM, Maxime Coquelin
>> <mcoquelin.stm32@...il.com> wrote:
>>> Hi Geert,
>>>
>>> 2015-02-12 21:34 GMT+01:00 Geert Uytterhoeven <geert@...ux-m68k.org>:
>>>> On Thu, Feb 12, 2015 at 6:45 PM, Maxime Coquelin
>>>> <mcoquelin.stm32@...il.com> wrote:
>>>>> From Cortex-M4 and M7 reference manuals, the nvic supports up to 240
>>>>> interrupts. So the number of entries in vectors table is 256.
>>>>>
>>>>> This patch adds the missing entries, and change the alignement, so that
>>>>> vector_table remains naturally aligned.
>>>>
>>>> Shouldn't this depend on ARCH_STM32, or some other M4 or M7 specific
>>>> Kconfig option, to avoid wasting the space on other CPUs?
>>>
>>> Actually, the STM32F429 has 90 interrupts, so it would need 106
>>> entries in the vector table.
>>> The maximum of supported interrupts is not only for Cortex-M4 and M7,
>>> this is also true for Cortex-M3.
>>>
>>> I see two possibilities:
>>>  1 - We declare the vector table for the maximum supported number of
>>> IRQs, as this patch does.
>>>         - Pro: it will be functionnal with all Cortex-M MCUs
>>>         - Con: Waste of less than 1KB for memory
>>
>> The waste depends on the alignment size as well and could be up to
>> almost 2KB worst case. It varies depending on the padding. We should
>> try to place it so it always aligned and the wasted space is
>> minimized.
>
> Sorry, I just notice I didn't replied to all. That was my question:
>
> Do you mean by forcing its location in the arch/arm/kernel/vmlinux.lds.S file?

Yes, that is one way. Or we might be able to just be smarter about how
we arrange the code. The first thing to do is figure out how much
space we waste and what comes before it.

Rob

>
> Regards,
> Maxime
>
>>
>> Rob
>>
>>>  2 - We introduce a config flag that provides the number of interrupts
>>>         - Pro: No more memory waste
>>>         - Con: Need to declare a per MCU model config flag.
>>>
>>> Then, regarding the natural alignment, is there a way to ensure it
>>> depending on the value of a config flag?
>>> Or we should keep it at the maximum value possible?
>>>
>>> Any feedback will be appreciated, especially from Uwe who maintains
>>> the efm32 machine.
>>>
>>> Kind regards,
>>> Maxime
--
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/