[Patch] mm: fix a section mismatch warning - Kernel

This is a discussion on [Patch] mm: fix a section mismatch warning - Kernel ; This patch fix this mismatch warning from mm: WARNING: vmlinux.o(.meminit.text+0x37f): Section mismatch in reference from the function free_area_init_core() to the function .init.text:setup_usemap() modpost: Found 1 section mismatch(es). Cc: Sam Ravnborg Signed-off-by: WANG Cong --- diff --git a/mm/page_alloc.c b/mm/page_alloc.c index b2838c2..8a9ae3c ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: [Patch] mm: fix a section mismatch warning

  1. [Patch] mm: fix a section mismatch warning


    This patch fix this mismatch warning from mm:

    WARNING: vmlinux.o(.meminit.text+0x37f): Section mismatch in reference from the function free_area_init_core() to the function .init.text:setup_usemap()
    modpost: Found 1 section mismatch(es).

    Cc: Sam Ravnborg
    Signed-off-by: WANG Cong

    ---

    diff --git a/mm/page_alloc.c b/mm/page_alloc.c
    index b2838c2..8a9ae3c 100644
    --- a/mm/page_alloc.c
    +++ b/mm/page_alloc.c
    @@ -3321,7 +3321,7 @@ static inline int pageblock_default_order(unsigned int order)
    * - mark all memory queues empty
    * - clear the memory bitmaps
    */
    -static void __meminit free_area_init_core(struct pglist_data *pgdat,
    +static void __init free_area_init_core(struct pglist_data *pgdat,
    unsigned long *zones_size, unsigned long *zholes_size)
    {
    enum zone_type j;
    @@ -3445,7 +3445,7 @@ static void __init_refok alloc_node_mem_map(struct pglist_data *pgdat)
    #endif /* CONFIG_FLAT_NODE_MEM_MAP */
    }

    -void __meminit free_area_init_node(int nid, struct pglist_data *pgdat,
    +void __init free_area_init_node(int nid, struct pglist_data *pgdat,
    unsigned long *zones_size, unsigned long node_start_pfn,
    unsigned long *zholes_size)
    {
    --
    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/

  2. Re: [Patch] mm: fix a section mismatch warning

    Hi WANG.

    On Fri, Feb 01, 2008 at 01:25:17AM +0800, WANG Cong wrote:
    >
    > This patch fix this mismatch warning from mm:
    >
    > WARNING: vmlinux.o(.meminit.text+0x37f): Section mismatch in reference from the function free_area_init_core() to the function .init.text:setup_usemap()
    > modpost: Found 1 section mismatch(es).
    >
    > Cc: Sam Ravnborg
    > Signed-off-by: WANG Cong
    >
    > ---
    >
    > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
    > index b2838c2..8a9ae3c 100644
    > --- a/mm/page_alloc.c
    > +++ b/mm/page_alloc.c
    > @@ -3321,7 +3321,7 @@ static inline int pageblock_default_order(unsigned int order)
    > * - mark all memory queues empty
    > * - clear the memory bitmaps
    > */
    > -static void __meminit free_area_init_core(struct pglist_data *pgdat,
    > +static void __init free_area_init_core(struct pglist_data *pgdat,
    > unsigned long *zones_size, unsigned long *zholes_size)
    > {
    > enum zone_type j;
    > @@ -3445,7 +3445,7 @@ static void __init_refok alloc_node_mem_map(struct pglist_data *pgdat)
    > #endif /* CONFIG_FLAT_NODE_MEM_MAP */
    > }
    >
    > -void __meminit free_area_init_node(int nid, struct pglist_data *pgdat,
    > +void __init free_area_init_node(int nid, struct pglist_data *pgdat,

    This change make me a bit unnerved. HAve you checked all callers?
    I simple grep shows 46 hits in the tree.

    It is always good to explain why the change you do is OK,
    for no other reasons than to show you really thought it through.

    Sam
    --
    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/

  3. Re: [Patch] mm: fix a section mismatch warning

    On Thu, Jan 31, 2008 at 07:38:53PM +0100, Sam Ravnborg wrote:
    >Hi WANG.
    >
    >On Fri, Feb 01, 2008 at 01:25:17AM +0800, WANG Cong wrote:
    >>
    >> This patch fix this mismatch warning from mm:
    >>
    >> WARNING: vmlinux.o(.meminit.text+0x37f): Section mismatch in reference from the function free_area_init_core() to the function .init.text:setup_usemap()
    >> modpost: Found 1 section mismatch(es).
    >>
    >> Cc: Sam Ravnborg
    >> Signed-off-by: WANG Cong
    >>
    >> ---
    >>
    >> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
    >> index b2838c2..8a9ae3c 100644
    >> --- a/mm/page_alloc.c
    >> +++ b/mm/page_alloc.c
    >> @@ -3321,7 +3321,7 @@ static inline int pageblock_default_order(unsigned int order)
    >> * - mark all memory queues empty
    >> * - clear the memory bitmaps
    >> */
    >> -static void __meminit free_area_init_core(struct pglist_data *pgdat,
    >> +static void __init free_area_init_core(struct pglist_data *pgdat,
    >> unsigned long *zones_size, unsigned long *zholes_size)
    >> {
    >> enum zone_type j;
    >> @@ -3445,7 +3445,7 @@ static void __init_refok alloc_node_mem_map(struct pglist_data *pgdat)
    >> #endif /* CONFIG_FLAT_NODE_MEM_MAP */
    >> }
    >>
    >> -void __meminit free_area_init_node(int nid, struct pglist_data *pgdat,
    >> +void __init free_area_init_node(int nid, struct pglist_data *pgdat,

    >This change make me a bit unnerved. HAve you checked all callers?
    >I simple grep shows 46 hits in the tree.


    I use cscope to do the check.

    free_area_init_node is the only caller of free_area_init_core,
    but free_area_init_node has more than one callers that didn't
    mark __init/__meminit.

    >
    >It is always good to explain why the change you do is OK,
    >for no other reasons than to show you really thought it through.


    OK. Thanks.

    --
    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/

+ Reply to Thread