All of lore.kernel.org
 help / color / mirror / Atom feed
From: sboyd@codeaurora.org (Stephen Boyd)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv2] arm: mm: Poison freed init memory
Date: Thu, 07 Jul 2011 10:44:34 -0700	[thread overview]
Message-ID: <4E15F082.7080604@codeaurora.org> (raw)
In-Reply-To: <20110707173645.GD20403@n2100.arm.linux.org.uk>

On 07/07/2011 10:36 AM, Russell King - ARM Linux wrote:
> On Thu, Jul 07, 2011 at 09:47:27AM -0700, Stephen Boyd wrote:
>> Poisoning __init marked memory can be useful when tracking down
>> obscure memory corruption bugs. Therefore, poison init memory
>> with 0xe7fddef0 to catch bugs earlier. The poison value is an
>> undefined instruction in ARM mode and branch to an undefined
>> instruction in Thumb mode.
>>
>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>> ---
>>
>> On 7/6/2011 2:01 PM, Russell King - ARM Linux wrote:
>>> On Wed, Jul 06, 2011 at 01:55:54PM -0700, Stephen Boyd wrote:
>>>> Should it include the initrd too? At least x86 poisons that memory but I
>>>> don't know who would be using that incorrectly.
>>> It could do - I don't see any harm in not doing so.  The only issue
>>> is that people may want to disable this stuff if they're after
>>> squeezing every last ms out of the boot time.
>> I haven't done this. I hope a follow up patch will suffice.
>>
>>>> How about a free_init_area() function which calls free_area() after
>>>> poisoning the memory?
>>> I need to go back and look at the Integrator etc situation with regard
>>> to reorganizing the vmlinux layout - it may be that the omission of
>>> freeing .init memory can now be removed (it was there to stop the
>>> memory being used as the first K of memory wasn't DMA-able.)
>>>
>>> Assuming it has to stay though, we still should arrange for the initrd
>>> memory to be poisoned even if it isn't freed.
>> Is this is patch what you're saying? I would have liked to do a
>> free_init_area() wrapper, but until the Integrator situation can be
>> sorted it doesn't look worthwhile.
> Yes, thanks.  This looks fine for the time being.  Have you been able
> to test it?  If yes, then please put it in the patch system and I'll
> see about giving it a test too.

Yes it's been tested (which is why there is a PAGE_ALIGN on initrd).

6996/1

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Boyd <sboyd@codeaurora.org>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Nicolas Pitre <nico@fluxnic.net>
Subject: Re: [PATCHv2] arm: mm: Poison freed init memory
Date: Thu, 07 Jul 2011 10:44:34 -0700	[thread overview]
Message-ID: <4E15F082.7080604@codeaurora.org> (raw)
In-Reply-To: <20110707173645.GD20403@n2100.arm.linux.org.uk>

On 07/07/2011 10:36 AM, Russell King - ARM Linux wrote:
> On Thu, Jul 07, 2011 at 09:47:27AM -0700, Stephen Boyd wrote:
>> Poisoning __init marked memory can be useful when tracking down
>> obscure memory corruption bugs. Therefore, poison init memory
>> with 0xe7fddef0 to catch bugs earlier. The poison value is an
>> undefined instruction in ARM mode and branch to an undefined
>> instruction in Thumb mode.
>>
>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>> ---
>>
>> On 7/6/2011 2:01 PM, Russell King - ARM Linux wrote:
>>> On Wed, Jul 06, 2011 at 01:55:54PM -0700, Stephen Boyd wrote:
>>>> Should it include the initrd too? At least x86 poisons that memory but I
>>>> don't know who would be using that incorrectly.
>>> It could do - I don't see any harm in not doing so.  The only issue
>>> is that people may want to disable this stuff if they're after
>>> squeezing every last ms out of the boot time.
>> I haven't done this. I hope a follow up patch will suffice.
>>
>>>> How about a free_init_area() function which calls free_area() after
>>>> poisoning the memory?
>>> I need to go back and look at the Integrator etc situation with regard
>>> to reorganizing the vmlinux layout - it may be that the omission of
>>> freeing .init memory can now be removed (it was there to stop the
>>> memory being used as the first K of memory wasn't DMA-able.)
>>>
>>> Assuming it has to stay though, we still should arrange for the initrd
>>> memory to be poisoned even if it isn't freed.
>> Is this is patch what you're saying? I would have liked to do a
>> free_init_area() wrapper, but until the Integrator situation can be
>> sorted it doesn't look worthwhile.
> Yes, thanks.  This looks fine for the time being.  Have you been able
> to test it?  If yes, then please put it in the patch system and I'll
> see about giving it a test too.

Yes it's been tested (which is why there is a PAGE_ALIGN on initrd).

6996/1

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.


  reply	other threads:[~2011-07-07 17:44 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-05 18:42 [PATCH] ARM: poison initmem when it is freed Russell King - ARM Linux
2011-07-05 19:17 ` Nicolas Pitre
2011-07-05 19:26   ` Russell King - ARM Linux
2011-07-05 19:48     ` Nicolas Pitre
2011-07-05 23:34       ` Stephen Boyd
2011-07-06 20:34         ` Russell King - ARM Linux
2011-07-06 20:55           ` Stephen Boyd
2011-07-06 21:01             ` Russell King - ARM Linux
2011-07-06 21:45               ` Tim Bird
2011-07-07 16:47               ` [PATCHv2] arm: mm: Poison freed init memory Stephen Boyd
2011-07-07 16:47                 ` Stephen Boyd
2011-07-07 17:36                 ` Russell King - ARM Linux
2011-07-07 17:36                   ` Russell King - ARM Linux
2011-07-07 17:44                   ` Stephen Boyd [this message]
2011-07-07 17:44                     ` Stephen Boyd
2011-07-07 17:41                 ` Nicolas Pitre
2011-07-07 17:41                   ` Nicolas Pitre
2011-07-06  9:08       ` [PATCH] ARM: poison initmem when it is freed Tixy
2011-07-06 20:35         ` Russell King - ARM Linux

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=4E15F082.7080604@codeaurora.org \
    --to=sboyd@codeaurora.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.