* Section mismatches in memblock
@ 2010-10-05 22:46 H. Peter Anvin
2010-10-05 23:30 ` Yinghai Lu
0 siblings, 1 reply; 5+ messages in thread
From: H. Peter Anvin @ 2010-10-05 22:46 UTC (permalink / raw)
To: Yinghai Lu, Benjamin Herrenschmidt; +Cc: Ingo Molnar, Thomas Gleixner, LKML
o.i386-allconfig/make.log:WARNING: mm/built-in.o(.text+0x48b6f): Section
mismatch in reference from the function memblock_is_memory() to the
variable .init.data:memblock
o.i386-allconfig/make.log:The function memblock_is_memory() references
o.i386-allconfig/make.log:This is often because memblock_is_memory lacks
a __initdata
o.i386-allconfig/make.log:WARNING: mm/built-in.o(.text+0x48bb0): Section
mismatch in reference from the function memblock_is_region_memory() to
the variable .init.data:memblock
o.i386-allconfig/make.log:The function memblock_is_region_memory()
references
o.i386-allconfig/make.log:This is often because
memblock_is_region_memory lacks a __initdata
o.i386-allconfig/make.log:WARNING: mm/built-in.o(.text+0x48bd5): Section
mismatch in reference from the function memblock_is_region_memory() to
the variable .init.data:memblock
o.i386-allconfig/make.log:The function memblock_is_region_memory()
references
o.i386-allconfig/make.log:This is often because
memblock_is_region_memory lacks a __initdata
Happens with both i386 and x86-64.
-hpa
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Section mismatches in memblock
2010-10-05 22:46 Section mismatches in memblock H. Peter Anvin
@ 2010-10-05 23:30 ` Yinghai Lu
2010-10-06 2:30 ` H. Peter Anvin
0 siblings, 1 reply; 5+ messages in thread
From: Yinghai Lu @ 2010-10-05 23:30 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Benjamin Herrenschmidt, Ingo Molnar, Thomas Gleixner, LKML
On 10/05/2010 03:46 PM, H. Peter Anvin wrote:
> o.i386-allconfig/make.log:WARNING: mm/built-in.o(.text+0x48b6f): Section
> mismatch in reference from the function memblock_is_memory() to the
> variable .init.data:memblock
> o.i386-allconfig/make.log:The function memblock_is_memory() references
> o.i386-allconfig/make.log:This is often because memblock_is_memory lacks
> a __initdata
> o.i386-allconfig/make.log:WARNING: mm/built-in.o(.text+0x48bb0): Section
> mismatch in reference from the function memblock_is_region_memory() to
> the variable .init.data:memblock
> o.i386-allconfig/make.log:The function memblock_is_region_memory()
> references
> o.i386-allconfig/make.log:This is often because
> memblock_is_region_memory lacks a __initdata
> o.i386-allconfig/make.log:WARNING: mm/built-in.o(.text+0x48bd5): Section
> mismatch in reference from the function memblock_is_region_memory() to
> the variable .init.data:memblock
> o.i386-allconfig/make.log:The function memblock_is_region_memory()
> references
> o.i386-allconfig/make.log:This is often because
> memblock_is_region_memory lacks a __initdata
>
> Happens with both i386 and x86-64.
[PATCH] memblock: Fix section mismatch warnings with memblock_search()
HPA found
o.i386-allconfig/make.log:WARNING: mm/built-in.o(.text+0x48b6f): Section
mismatch in reference from the function memblock_is_memory() to the
variable .init.data:memblock
o.i386-allconfig/make.log:The function memblock_is_memory() references
o.i386-allconfig/make.log:This is often because memblock_is_memory lacks
a __initdata
o.i386-allconfig/make.log:WARNING: mm/built-in.o(.text+0x48bb0): Section
mismatch in reference from the function memblock_is_region_memory() to
the variable .init.data:memblock
o.i386-allconfig/make.log:The function memblock_is_region_memory()
references
o.i386-allconfig/make.log:This is often because
memblock_is_region_memory lacks a __initdata
looks like gcc problem.
| static int memblock_search(struct memblock_type *type, phys_addr_t addr)
| {
| .....
| }
|
|int __init memblock_is_reserved(phys_addr_t addr)
|{
| return memblock_search(&memblock.reserved, addr) != -1;
|}
|
|int __init_memblock memblock_is_memory(phys_addr_t addr)
|{
| return memblock_search(&memblock.memory, addr) != -1;
|}
Because We already have __init for those two functions.
Just make memblock_search to have __init_memblock atribute.
Reported-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Yinghai Lu <Yinghai@kernel.org>
---
mm/memblock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6/mm/memblock.c
===================================================================
--- linux-2.6.orig/mm/memblock.c
+++ linux-2.6/mm/memblock.c
@@ -653,7 +653,7 @@ void __init memblock_enforce_memory_limi
}
}
-static int memblock_search(struct memblock_type *type, phys_addr_t addr)
+static int __init_memblock memblock_search(struct memblock_type *type, phys_addr_t addr)
{
unsigned int left = 0, right = type->cnt;
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Section mismatches in memblock
2010-10-05 23:30 ` Yinghai Lu
@ 2010-10-06 2:30 ` H. Peter Anvin
2010-10-06 3:04 ` H. Peter Anvin
0 siblings, 1 reply; 5+ messages in thread
From: H. Peter Anvin @ 2010-10-06 2:30 UTC (permalink / raw)
To: Yinghai Lu; +Cc: Benjamin Herrenschmidt, Ingo Molnar, Thomas Gleixner, LKML
On 10/05/2010 04:30 PM, Yinghai Lu wrote:
>
> looks like gcc problem.
What makes you say that?
> | static int memblock_search(struct memblock_type *type, phys_addr_t addr)
> | {
> | .....
> | }
> |
> |int __init memblock_is_reserved(phys_addr_t addr)
> |{
> | return memblock_search(&memblock.reserved, addr) != -1;
> |}
> |
> |int __init_memblock memblock_is_memory(phys_addr_t addr)
> |{
> | return memblock_search(&memblock.memory, addr) != -1;
> |}
>
> Because We already have __init for those two functions.
>
> Just make memblock_search to have __init_memblock atribute.
>
Wrong functions! Furhtermore, at least the tip tree definitely does not
have __init_memblock here:
static int memblock_search(struct memblock_type *type, phys_addr_t addr)
{
unsigned int left = 0, right = type->cnt;
do {
unsigned int mid = (right + left) / 2;
if (addr < type->regions[mid].base)
right = mid;
else if (addr >= (type->regions[mid].base +
type->regions[mid].size))
left = mid + 1;
else
return mid;
} while (left < right);
return -1;
}
int __init memblock_is_reserved(phys_addr_t addr)
{
return memblock_search(&memblock.reserved, addr) != -1;
}
int memblock_is_memory(phys_addr_t addr)
{
return memblock_search(&memblock.memory, addr) != -1;
}
int memblock_is_region_memory(phys_addr_t base, phys_addr_t size)
{
int idx = memblock_search(&memblock.reserved, base);
if (idx == -1)
return 0;
return memblock.reserved.regions[idx].base <= base &&
(memblock.reserved.regions[idx].base +
memblock.reserved.regions[idx].size) >= (base + size);
}
... so I don't know why you're saying that you already have them.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Section mismatches in memblock
2010-10-06 2:30 ` H. Peter Anvin
@ 2010-10-06 3:04 ` H. Peter Anvin
2010-10-08 8:16 ` Ingo Molnar
0 siblings, 1 reply; 5+ messages in thread
From: H. Peter Anvin @ 2010-10-06 3:04 UTC (permalink / raw)
To: Yinghai Lu; +Cc: Benjamin Herrenschmidt, Ingo Molnar, Thomas Gleixner, LKML
On 10/05/2010 07:30 PM, H. Peter Anvin wrote:
>
> Wrong functions! Furhtermore, at least the tip tree definitely does not
> have __init_memblock here:
>
Nevermind. I had missed that Ingo had put stuff into core/memblock on
top of x86/memblock, just to be confusing.
-hpa
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Section mismatches in memblock
2010-10-06 3:04 ` H. Peter Anvin
@ 2010-10-08 8:16 ` Ingo Molnar
0 siblings, 0 replies; 5+ messages in thread
From: Ingo Molnar @ 2010-10-08 8:16 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Yinghai Lu, Benjamin Herrenschmidt, Thomas Gleixner, LKML
* H. Peter Anvin <hpa@kernel.org> wrote:
> On 10/05/2010 07:30 PM, H. Peter Anvin wrote:
> >
> > Wrong functions! Furhtermore, at least the tip tree definitely does not
> > have __init_memblock here:
> >
>
> Nevermind. I had missed that Ingo had put stuff into core/memblock on
> top of x86/memblock, just to be confusing.
Correct - we better keep it as a generic, non-x86 topic as it affects
other architectures. We can zap x86/memblock (it's fully contained in
core/memblock) so that it's not confusing.
Thanks,
Ingo
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-10-08 8:16 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-10-05 22:46 Section mismatches in memblock H. Peter Anvin
2010-10-05 23:30 ` Yinghai Lu
2010-10-06 2:30 ` H. Peter Anvin
2010-10-06 3:04 ` H. Peter Anvin
2010-10-08 8:16 ` Ingo Molnar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox