Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1269684 > unrolled thread

[PATCH 0/4] m68k/mm: Add missing initialization of max_pfn and {min,max}_low_pfn

Started byGeert Uytterhoeven <geert@linux-m68k.org>
First post2015-11-15 12:50 +0100
Last post2015-11-17 01:20 +0100
Articles 8 — 2 participants

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/4] m68k/mm: Add missing initialization of max_pfn and {min,max}_low_pfn Geert Uytterhoeven <geert@linux-m68k.org> - 2015-11-15 12:50 +0100
    [PATCH 4/4] m68knommu: Add missing initialization of max_pfn and {min,max}_low_pfn Geert Uytterhoeven <geert@linux-m68k.org> - 2015-11-15 12:50 +0100
      Re: [PATCH 4/4] m68knommu: Add missing initialization of max_pfn and  {min,max}_low_pfn Greg Ungerer <gerg@uclinux.org> - 2015-11-16 13:20 +0100
        Re: [PATCH 4/4] m68knommu: Add missing initialization of max_pfn and {min,max}_low_pfn Geert Uytterhoeven <geert@linux-m68k.org> - 2015-11-16 14:10 +0100
          Re: [PATCH 4/4] m68knommu: Add missing initialization of max_pfn and  {min,max}_low_pfn Greg Ungerer <gerg@uclinux.org> - 2015-11-17 00:50 +0100
      Re: [PATCH 4/4] m68knommu: Add missing initialization of max_pfn and  {min,max}_low_pfn Greg Ungerer <gerg@uclinux.org> - 2015-11-17 01:00 +0100
        Re: [PATCH 4/4] m68knommu: Add missing initialization of max_pfn and {min,max}_low_pfn Geert Uytterhoeven <geert@linux-m68k.org> - 2015-11-22 11:40 +0100
    Re: [PATCH 0/4] m68k/mm: Add missing initialization of max_pfn and  {min,max}_low_pfn Greg Ungerer <gerg@uclinux.org> - 2015-11-17 01:20 +0100

#1269684 — [PATCH 0/4] m68k/mm: Add missing initialization of max_pfn and {min,max}_low_pfn

FromGeert Uytterhoeven <geert@linux-m68k.org>
Date2015-11-15 12:50 +0100
Subject[PATCH 0/4] m68k/mm: Add missing initialization of max_pfn and {min,max}_low_pfn
Message-ID<qv3YK-Sx-5@gated-at.bofh.it>
	Hi,

This patch series adds missing initialization of max_pfn, min_low_pfn,
and max_low_pfn on various m68k platforms.

This was exposed by failing selftests/vm/mlock2-tests.

Note that several other architectures lack a proper initialization of
max_pfn. On some of them it's completely missing, on others max_pfn is a
local variable, hence it hides the global max_pfn, which is thus not
initialized neither.

On platforms with MMU, this can easily be verified by reading the
following virtual files (CONFIG_PROC_PAGE_MONITOR=y):

    /proc/kpagecount
    /proc/kpageflags
    /proc/kpagecgroup (CONFIG_MEMCG=y)

If max_pfn is not initialized, all three virtual files are empty.

Besides the above, max_pfn is also used to calculate DMA masks for block
devices. An uninitialized (zero) value means all RAM is suitable for
DMA.

Absence of initialization of min_low_pfn and max_low_pfn is more subtle.
(are there any bad side-effects?).

Geert Uytterhoeven (4):
  m68k/mm: motorola - Add missing initialization of max_pfn
  m68k/mm: m54xx - Add missing initialization of max_pfn
  m68k/mm: sun3 - Add missing initialization of max_pfn and
    {min,max}_low_pfn
  m68knommu: Add missing initialization of max_pfn and {min,max}_low_pfn

 arch/m68k/coldfire/m54xx.c  | 2 +-
 arch/m68k/kernel/setup_no.c | 9 ++++++---
 arch/m68k/mm/motorola.c     | 2 +-
 arch/m68k/sun3/config.c     | 4 ++--
 4 files changed, 10 insertions(+), 7 deletions(-)

-- 
1.9.1

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1269685 — [PATCH 4/4] m68knommu: Add missing initialization of max_pfn and {min,max}_low_pfn

FromGeert Uytterhoeven <geert@linux-m68k.org>
Date2015-11-15 12:50 +0100
Subject[PATCH 4/4] m68knommu: Add missing initialization of max_pfn and {min,max}_low_pfn
Message-ID<qv3YK-Sx-21@gated-at.bofh.it>
In reply to#1269684
If max_pfn is not initialized, the block layer may use wrong DMA masks.

Replace open-coded shifts by PFN_DOWN() while we're at it.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
Compile-tested only.
---
 arch/m68k/kernel/setup_no.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c
index 88c27d94a7214c95..29b44e69f0f47375 100644
--- a/arch/m68k/kernel/setup_no.c
+++ b/arch/m68k/kernel/setup_no.c
@@ -238,11 +238,14 @@ void __init setup_arch(char **cmdline_p)
 	 * Give all the memory to the bootmap allocator, tell it to put the
 	 * boot mem_map at the start of memory.
 	 */
+	min_low_pfn = PFN_DOWN(memory_start);
+	max_pfn = max_low_pfn = PFN_DOWN(memory_end);
+
 	bootmap_size = init_bootmem_node(
 			NODE_DATA(0),
-			memory_start >> PAGE_SHIFT, /* map goes here */
-			PAGE_OFFSET >> PAGE_SHIFT,	/* 0 on coldfire */
-			memory_end >> PAGE_SHIFT);
+			min_low_pfn,		/* map goes here */
+			PFN_DOWN(PAGE_OFFSET),	/* 0 on coldfire */
+			max_pfn);
 	/*
 	 * Free the usable memory, we have to make sure we do not free
 	 * the bootmem bitmap so we then reserve it after freeing it :-)
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1270057 — Re: [PATCH 4/4] m68knommu: Add missing initialization of max_pfn and {min,max}_low_pfn

FromGreg Ungerer <gerg@uclinux.org>
Date2015-11-16 13:20 +0100
SubjectRe: [PATCH 4/4] m68knommu: Add missing initialization of max_pfn and {min,max}_low_pfn
Message-ID<qvqVk-7cN-17@gated-at.bofh.it>
In reply to#1269685
Hi Geert,

On 15/11/15 21:04, Geert Uytterhoeven wrote:
> If max_pfn is not initialized, the block layer may use wrong DMA masks.
>
> Replace open-coded shifts by PFN_DOWN() while we're at it.
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
> Compile-tested only.
> ---
>   arch/m68k/kernel/setup_no.c | 9 ++++++---
>   1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c
> index 88c27d94a7214c95..29b44e69f0f47375 100644
> --- a/arch/m68k/kernel/setup_no.c
> +++ b/arch/m68k/kernel/setup_no.c
> @@ -238,11 +238,14 @@ void __init setup_arch(char **cmdline_p)
>   	 * Give all the memory to the bootmap allocator, tell it to put the
>   	 * boot mem_map at the start of memory.
>   	 */
> +	min_low_pfn = PFN_DOWN(memory_start);
> +	max_pfn = max_low_pfn = PFN_DOWN(memory_end);
> +
>   	bootmap_size = init_bootmem_node(
>   			NODE_DATA(0),
> -			memory_start >> PAGE_SHIFT, /* map goes here */
> -			PAGE_OFFSET >> PAGE_SHIFT,	/* 0 on coldfire */
> -			memory_end >> PAGE_SHIFT);
> +			min_low_pfn,		/* map goes here */
> +			PFN_DOWN(PAGE_OFFSET),	/* 0 on coldfire */
> +			max_pfn);
>   	/*
>   	 * Free the usable memory, we have to make sure we do not free
>   	 * the bootmem bitmap so we then reserve it after freeing it :-)

Should this be changed to use init_bootmem() as per your changes
in patch 3 ("m68k/mm: sun3 - Add missing initialization of max_pfn and 
{min,max}_low_pfn")? For the same reason?

Regards
Greg


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1270103 — Re: [PATCH 4/4] m68knommu: Add missing initialization of max_pfn and {min,max}_low_pfn

FromGeert Uytterhoeven <geert@linux-m68k.org>
Date2015-11-16 14:10 +0100
SubjectRe: [PATCH 4/4] m68knommu: Add missing initialization of max_pfn and {min,max}_low_pfn
Message-ID<qvrHI-7IR-13@gated-at.bofh.it>
In reply to#1270057
Hi Greg,

On Mon, Nov 16, 2015 at 1:18 PM, Greg Ungerer <gerg@uclinux.org> wrote:
>> --- a/arch/m68k/kernel/setup_no.c
>> +++ b/arch/m68k/kernel/setup_no.c
>> @@ -238,11 +238,14 @@ void __init setup_arch(char **cmdline_p)
>>          * Give all the memory to the bootmap allocator, tell it to put
>> the
>>          * boot mem_map at the start of memory.
>>          */
>> +       min_low_pfn = PFN_DOWN(memory_start);
>> +       max_pfn = max_low_pfn = PFN_DOWN(memory_end);
>> +
>>         bootmap_size = init_bootmem_node(
>>                         NODE_DATA(0),
>> -                       memory_start >> PAGE_SHIFT, /* map goes here */
>> -                       PAGE_OFFSET >> PAGE_SHIFT,      /* 0 on coldfire
>> */
>> -                       memory_end >> PAGE_SHIFT);
>> +                       min_low_pfn,            /* map goes here */
>> +                       PFN_DOWN(PAGE_OFFSET),  /* 0 on coldfire */
>> +                       max_pfn);
>>         /*
>>          * Free the usable memory, we have to make sure we do not free
>>          * the bootmem bitmap so we then reserve it after freeing it :-)
>
> Should this be changed to use init_bootmem() as per your changes
> in patch 3 ("m68k/mm: sun3 - Add missing initialization of max_pfn and
> {min,max}_low_pfn")? For the same reason?

No. PAGE_OFFSET = PAGE_OFFSET_RAW = CONFIG_RAMBASE.
As the comment says, this is zero on coldfire, but not on all m68knommu
platforms.

Upon closer look, this isn't even true on all Coldfire boards:

arch/m68k/configs/m5208evb_defconfig:CONFIG_RAMBASE=0x40000000

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1270697 — Re: [PATCH 4/4] m68knommu: Add missing initialization of max_pfn and {min,max}_low_pfn

FromGreg Ungerer <gerg@uclinux.org>
Date2015-11-17 00:50 +0100
SubjectRe: [PATCH 4/4] m68knommu: Add missing initialization of max_pfn and {min,max}_low_pfn
Message-ID<qvBH3-5vs-1@gated-at.bofh.it>
In reply to#1270103
Hi Geert,

On 16/11/15 23:05, Geert Uytterhoeven wrote:
> On Mon, Nov 16, 2015 at 1:18 PM, Greg Ungerer <gerg@uclinux.org> wrote:
>>> --- a/arch/m68k/kernel/setup_no.c
>>> +++ b/arch/m68k/kernel/setup_no.c
>>> @@ -238,11 +238,14 @@ void __init setup_arch(char **cmdline_p)
>>>          * Give all the memory to the bootmap allocator, tell it to put
>>> the
>>>          * boot mem_map at the start of memory.
>>>          */
>>> +       min_low_pfn = PFN_DOWN(memory_start);
>>> +       max_pfn = max_low_pfn = PFN_DOWN(memory_end);
>>> +
>>>         bootmap_size = init_bootmem_node(
>>>                         NODE_DATA(0),
>>> -                       memory_start >> PAGE_SHIFT, /* map goes here */
>>> -                       PAGE_OFFSET >> PAGE_SHIFT,      /* 0 on coldfire
>>> */
>>> -                       memory_end >> PAGE_SHIFT);
>>> +                       min_low_pfn,            /* map goes here */
>>> +                       PFN_DOWN(PAGE_OFFSET),  /* 0 on coldfire */
>>> +                       max_pfn);
>>>         /*
>>>          * Free the usable memory, we have to make sure we do not free
>>>          * the bootmem bitmap so we then reserve it after freeing it :-)
>>
>> Should this be changed to use init_bootmem() as per your changes
>> in patch 3 ("m68k/mm: sun3 - Add missing initialization of max_pfn and
>> {min,max}_low_pfn")? For the same reason?
> 
> No. PAGE_OFFSET = PAGE_OFFSET_RAW = CONFIG_RAMBASE.
> As the comment says, this is zero on coldfire, but not on all m68knommu
> platforms.
> 
> Upon closer look, this isn't even true on all Coldfire boards:
> 
> arch/m68k/configs/m5208evb_defconfig:CONFIG_RAMBASE=0x40000000

Yes, that comment is definitely wrong!

Regards
Greg


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1270702 — Re: [PATCH 4/4] m68knommu: Add missing initialization of max_pfn and {min,max}_low_pfn

FromGreg Ungerer <gerg@uclinux.org>
Date2015-11-17 01:00 +0100
SubjectRe: [PATCH 4/4] m68knommu: Add missing initialization of max_pfn and {min,max}_low_pfn
Message-ID<qvBQJ-5zm-11@gated-at.bofh.it>
In reply to#1269685
Hi Geert,

On 15/11/15 21:04, Geert Uytterhoeven wrote:
> If max_pfn is not initialized, the block layer may use wrong DMA masks.
> 
> Replace open-coded shifts by PFN_DOWN() while we're at it.
> 
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>

Tested and working fine on m68knommu. So:

Tested-By: Greg Ungerer <gerg@uclinux.org>

If you respin this patch for any reason I wouldn't object
to removing the "/* 0 on coldfire */" comment...

Regards
Greg



> ---
> Compile-tested only.
> ---
>  arch/m68k/kernel/setup_no.c | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c
> index 88c27d94a7214c95..29b44e69f0f47375 100644
> --- a/arch/m68k/kernel/setup_no.c
> +++ b/arch/m68k/kernel/setup_no.c
> @@ -238,11 +238,14 @@ void __init setup_arch(char **cmdline_p)
>  	 * Give all the memory to the bootmap allocator, tell it to put the
>  	 * boot mem_map at the start of memory.
>  	 */
> +	min_low_pfn = PFN_DOWN(memory_start);
> +	max_pfn = max_low_pfn = PFN_DOWN(memory_end);
> +
>  	bootmap_size = init_bootmem_node(
>  			NODE_DATA(0),
> -			memory_start >> PAGE_SHIFT, /* map goes here */
> -			PAGE_OFFSET >> PAGE_SHIFT,	/* 0 on coldfire */
> -			memory_end >> PAGE_SHIFT);
> +			min_low_pfn,		/* map goes here */
> +			PFN_DOWN(PAGE_OFFSET),	/* 0 on coldfire */
> +			max_pfn);
>  	/*
>  	 * Free the usable memory, we have to make sure we do not free
>  	 * the bootmem bitmap so we then reserve it after freeing it :-)
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1274846 — Re: [PATCH 4/4] m68knommu: Add missing initialization of max_pfn and {min,max}_low_pfn

FromGeert Uytterhoeven <geert@linux-m68k.org>
Date2015-11-22 11:40 +0100
SubjectRe: [PATCH 4/4] m68knommu: Add missing initialization of max_pfn and {min,max}_low_pfn
Message-ID<qxAdQ-2sv-19@gated-at.bofh.it>
In reply to#1270702
Hi Greg,

On Tue, Nov 17, 2015 at 12:54 AM, Greg Ungerer <gerg@uclinux.org> wrote:
> On 15/11/15 21:04, Geert Uytterhoeven wrote:
>> If max_pfn is not initialized, the block layer may use wrong DMA masks.
>>
>> Replace open-coded shifts by PFN_DOWN() while we're at it.
>>
>> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
>
> Tested and working fine on m68knommu. So:
>
> Tested-By: Greg Ungerer <gerg@uclinux.org>
>
> If you respin this patch for any reason I wouldn't object
> to removing the "/* 0 on coldfire */" comment...

Thanks, done, applied, and queued for v4.4.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1270716 — Re: [PATCH 0/4] m68k/mm: Add missing initialization of max_pfn and {min,max}_low_pfn

FromGreg Ungerer <gerg@uclinux.org>
Date2015-11-17 01:20 +0100
SubjectRe: [PATCH 0/4] m68k/mm: Add missing initialization of max_pfn and {min,max}_low_pfn
Message-ID<qvCa7-5Wu-9@gated-at.bofh.it>
In reply to#1269684
Hi Geert,

On 15/11/15 21:04, Geert Uytterhoeven wrote:
> This patch series adds missing initialization of max_pfn, min_low_pfn,
> and max_low_pfn on various m68k platforms.
> 
> This was exposed by failing selftests/vm/mlock2-tests.
> 
> Note that several other architectures lack a proper initialization of
> max_pfn. On some of them it's completely missing, on others max_pfn is a
> local variable, hence it hides the global max_pfn, which is thus not
> initialized neither.
> 
> On platforms with MMU, this can easily be verified by reading the
> following virtual files (CONFIG_PROC_PAGE_MONITOR=y):
> 
>     /proc/kpagecount
>     /proc/kpageflags
>     /proc/kpagecgroup (CONFIG_MEMCG=y)
> 
> If max_pfn is not initialized, all three virtual files are empty.
> 
> Besides the above, max_pfn is also used to calculate DMA masks for block
> devices. An uninitialized (zero) value means all RAM is suitable for
> DMA.

All looks good to me. Tested-by acks set separately. But otherwise

Acked-by: Greg Ungerer <gerg@uclinux.org>

Regards
Greg


> Absence of initialization of min_low_pfn and max_low_pfn is more subtle.
> (are there any bad side-effects?).
> 
> Geert Uytterhoeven (4):
>   m68k/mm: motorola - Add missing initialization of max_pfn
>   m68k/mm: m54xx - Add missing initialization of max_pfn
>   m68k/mm: sun3 - Add missing initialization of max_pfn and
>     {min,max}_low_pfn
>   m68knommu: Add missing initialization of max_pfn and {min,max}_low_pfn
> 
>  arch/m68k/coldfire/m54xx.c  | 2 +-
>  arch/m68k/kernel/setup_no.c | 9 ++++++---
>  arch/m68k/mm/motorola.c     | 2 +-
>  arch/m68k/sun3/config.c     | 4 ++--
>  4 files changed, 10 insertions(+), 7 deletions(-)
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web