All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Carroll <dcarroll@astekcorp.com>
To: "'Milton Miller'" <miltonm@bga.com>
Cc: Paul Mackerras <paulus@samba.org>,
	LPPC <linuxppc-dev@lists.ozlabs.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: RE: [PATCH v3] powerpc: Force page alignment for initrd reserved memory
Date: Sun, 22 May 2011 19:29:42 -0600	[thread overview]
Message-ID: <522F24EF533FC546962ECFA2054FF777373072AB74@MAILSERVER2.cos.astekcorp.com> (raw)
In-Reply-To: <initrd-reserve-reply2@mdm.bga.com>

>On Sun, 22 May 2011 about 15:17, Milton Miller wrote:
>>On Sat, 21 May 2011 about 11:05:27 -0600, Dave Carroll wrote:>
>> When using 64K pages with a separate cpio rootfs, U-Boot will align
>> the rootfs on a 4K page boundary. When the memory is reserved, and
>> subsequent early memblock_alloc is called, it will allocate memory
>> between the 64K page alignment and reserved memory. When the reserved
>> memory is subsequently freed, it is done so by pages, causing the
>> early memblock_alloc requests to be re-used, which in my case, caused
>> the device-tree to be clobbered.
>>
>> This patch forces the reserved memory for initrd to be kernel page
>> aligned, and adds the same range extension when freeing initrd.
>
>Getting better, but
>
>>
>>
>> Signed-off-by: Dave Carroll <dcarroll@astekcorp.com>
>> ---
>>  arch/powerpc/kernel/prom.c |    4 +++-
>>  arch/powerpc/mm/init_32.c  |    3 +++
>>  arch/powerpc/mm/init_64.c  |    3 +++
>>  3 files changed, 9 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
>> index 48aeb55..397d4a0 100644
>> --- a/arch/powerpc/kernel/prom.c
>> +++ b/arch/powerpc/kernel/prom.c
>> @@ -555,7 +555,9 @@ static void __init early_reserve_mem(void)
>>  #ifdef CONFIG_BLK_DEV_INITRD
>>         /* then reserve the initrd, if any */
>>         if (initrd_start && (initrd_end > initrd_start))
>
>Here you test the unaligned values
>
>>  void free_initrd_mem(unsigned long start, unsigned long end)
>>  {
>> +       start = _ALIGN_DOWN(start, PAGE_SIZE);
>> +       end = _ALIGN_UP(end, PAGE_SIZE);
>> +
>>         if (start < end)
>>                 printk ("Freeing initrd memory: %ldk freed\n", (end - start) >> 10);
>
>But here you test the aligned values.  And they are aligned with
>opposite bias.  Which means that if start == end (or is less than,
>but within the same page), a page that wasn't reserved (same
>32 and 64 bit) gets freed.
>

Agreed ... I'll have the but shortly ...

>I thought "what happens if we are within a page of end, could we
>free the last page of bss?", but then I checked vmlinux.lds and we
>align end to page size.  I thought other allocations should be safe,
>but then remembered:
>
>The flattened device tree (of which we continue to use the string
>table after boot) could be a problem.
>

I had previouly looked at free_initrd_mem, and thought the same conditions
should be used to handle the memory release, but as for the explicit alignment
of the release areas, that seemed to be handled by the fact that all of the
releases are specifically page aligned. The remainder of the free_initrd_mem
routine:

        for (; start < end; start += PAGE_SIZE) {
                ClearPageReserved(virt_to_page(start));
                init_page_count(virt_to_page(start));
                free_page(start);
                totalram_pages++;
        }

implicitly aligns down start to a page boundary, and also would implicitly align
up the end address. While I would be a proponent of something like;

        if (start && (start < end)) do { remainder of free_initrd_mem }

I'm not sure of the goal in explicitly attempting to align the addresses in the
routine as you proposed.

As for the FDT, if the FDT is packed contiguous with initrd, and the alignment is on
4K page boundaries, it would have been released before this patch. In my case (U-Boot),
they are not near each other.

Thanks,
-Dave
>
>milton


WARNING: multiple messages have this Message-ID (diff)
From: Dave Carroll <dcarroll@astekcorp.com>
To: 'Milton Miller' <miltonm@bga.com>
Cc: LPPC <linuxppc-dev@lists.ozlabs.org>,
	Paul Mackerras <paulus@samba.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v3] powerpc: Force page alignment for initrd reserved memory
Date: Sun, 22 May 2011 19:29:42 -0600	[thread overview]
Message-ID: <522F24EF533FC546962ECFA2054FF777373072AB74@MAILSERVER2.cos.astekcorp.com> (raw)
In-Reply-To: <initrd-reserve-reply2@mdm.bga.com>

>On Sun, 22 May 2011 about 15:17, Milton Miller wrote:
>>On Sat, 21 May 2011 about 11:05:27 -0600, Dave Carroll wrote:>
>> When using 64K pages with a separate cpio rootfs, U-Boot will align
>> the rootfs on a 4K page boundary. When the memory is reserved, and
>> subsequent early memblock_alloc is called, it will allocate memory
>> between the 64K page alignment and reserved memory. When the reserved
>> memory is subsequently freed, it is done so by pages, causing the
>> early memblock_alloc requests to be re-used, which in my case, caused
>> the device-tree to be clobbered.
>>
>> This patch forces the reserved memory for initrd to be kernel page
>> aligned, and adds the same range extension when freeing initrd.
>
>Getting better, but
>
>>
>>
>> Signed-off-by: Dave Carroll <dcarroll@astekcorp.com>
>> ---
>>  arch/powerpc/kernel/prom.c |    4 +++-
>>  arch/powerpc/mm/init_32.c  |    3 +++
>>  arch/powerpc/mm/init_64.c  |    3 +++
>>  3 files changed, 9 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
>> index 48aeb55..397d4a0 100644
>> --- a/arch/powerpc/kernel/prom.c
>> +++ b/arch/powerpc/kernel/prom.c
>> @@ -555,7 +555,9 @@ static void __init early_reserve_mem(void)
>>  #ifdef CONFIG_BLK_DEV_INITRD
>>         /* then reserve the initrd, if any */
>>         if (initrd_start && (initrd_end > initrd_start))
>
>Here you test the unaligned values
>
>>  void free_initrd_mem(unsigned long start, unsigned long end)
>>  {
>> +       start =3D _ALIGN_DOWN(start, PAGE_SIZE);
>> +       end =3D _ALIGN_UP(end, PAGE_SIZE);
>> +
>>         if (start < end)
>>                 printk ("Freeing initrd memory: %ldk freed\n", (end - st=
art) >> 10);
>
>But here you test the aligned values.  And they are aligned with
>opposite bias.  Which means that if start =3D=3D end (or is less than,
>but within the same page), a page that wasn't reserved (same
>32 and 64 bit) gets freed.
>

Agreed ... I'll have the but shortly ...

>I thought "what happens if we are within a page of end, could we
>free the last page of bss?", but then I checked vmlinux.lds and we
>align end to page size.  I thought other allocations should be safe,
>but then remembered:
>
>The flattened device tree (of which we continue to use the string
>table after boot) could be a problem.
>

I had previouly looked at free_initrd_mem, and thought the same conditions
should be used to handle the memory release, but as for the explicit alignm=
ent
of the release areas, that seemed to be handled by the fact that all of the
releases are specifically page aligned. The remainder of the free_initrd_me=
m
routine:

        for (; start < end; start +=3D PAGE_SIZE) {
                ClearPageReserved(virt_to_page(start));
                init_page_count(virt_to_page(start));
                free_page(start);
                totalram_pages++;
        }

implicitly aligns down start to a page boundary, and also would implicitly =
align
up the end address. While I would be a proponent of something like;

        if (start && (start < end)) do { remainder of free_initrd_mem }

I'm not sure of the goal in explicitly attempting to align the addresses in=
 the
routine as you proposed.

As for the FDT, if the FDT is packed contiguous with initrd, and the alignm=
ent is on
4K page boundaries, it would have been released before this patch. In my ca=
se (U-Boot),
they are not near each other.

Thanks,
-Dave
>
>milton

  reply	other threads:[~2011-05-23  1:30 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-20 21:26 [PATCH]powerpc: Force page alignment for early reserved memory Dave Carroll
2011-05-20 21:26 ` Dave Carroll
2011-05-20 22:27 ` Benjamin Herrenschmidt
2011-05-20 22:27   ` Benjamin Herrenschmidt
2011-05-20 23:23   ` [PATCH v2]powerpc: Force page alignment for initrd Dave Carroll
2011-05-20 23:23     ` Dave Carroll
2011-05-21 10:36     ` [v2] powerpc: " Milton Miller
2011-05-21 10:36       ` Milton Miller
2011-05-21 17:05       ` [PATCH v3] powerpc: Force page alignment for initrd reserved memory Dave Carroll
2011-05-21 17:05         ` Dave Carroll
2011-05-22 21:17         ` [PATCH v3] powerpc: Force page alignment for initrd reserved memory, " 'Milton Miller'
2011-05-22 21:17           ` 'Milton Miller'
2011-05-23  1:29           ` Dave Carroll [this message]
2011-05-23  1:29             ` Dave Carroll
2011-05-23  2:31           ` [PATCH v4] " Dave Carroll
2011-05-23  2:31             ` Dave Carroll
2011-05-23 16:50             ` [ " Dave Carroll
2011-05-23 16:50               ` Dave Carroll
2011-05-23 17:39               ` Milton Miller
2011-05-23 17:39                 ` Milton Miller
2011-05-23 22:54                 ` [PATCH v5] " Dave Carroll
2011-05-23 22:54                   ` Dave Carroll
2011-05-25  9:28                   ` [v5] " Milton Miller
2011-05-25  9:28                     ` Milton Miller
2011-05-26  2:00                     ` [PATCH v6] " Dave Carroll
2011-05-26  2:00                       ` Dave Carroll
2011-05-26  2:32                     ` [PATCH v7] " Dave Carroll
2011-05-26  2:32                       ` Dave Carroll
2011-05-26 11:18                       ` Milton Miller
2011-05-26 11:18                         ` Milton Miller
2011-05-26 16:53                         ` [PATCH v8] " Dave Carroll
2011-05-26 16:53                           ` Dave Carroll
2011-06-11  1:38                     ` [PATCH 1/2] powerpc: Move free_initmem to common code Dave Carroll
2011-06-11  1:38                       ` Dave Carroll
2011-06-11  1:38                       ` [PATCH 2/2] powerpc: Add printk companion for ppc_md.progress Dave Carroll
2011-06-11  1:38                         ` Dave Carroll

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=522F24EF533FC546962ECFA2054FF777373072AB74@MAILSERVER2.cos.astekcorp.com \
    --to=dcarroll@astekcorp.com \
    --cc=benh@kernel.crashing.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=miltonm@bga.com \
    --cc=paulus@samba.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.