All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
To: Michal Hocko <mhocko@suse.com>
Cc: kernel test robot <lkp@intel.com>,
	kbuild-all@lists.01.org, linux-kernel@vger.kernel.org,
	Oscar Salvador <osalvador@suse.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Memory Management List <linux-mm@kvack.org>,
	linux-mips@vger.kernel.org
Subject: Re: undefined reference to `node_data'
Date: Thu, 24 Mar 2022 10:04:43 +0100	[thread overview]
Message-ID: <20220324090443.GA5375@alpha.franken.de> (raw)
In-Reply-To: <YjtPAwl/lhh+n3c2@dhcp22.suse.cz>

On Wed, Mar 23, 2022 at 05:46:59PM +0100, Michal Hocko wrote:
> > > If you fix the issue, kindly add following tag as appropriate
> > > Reported-by: kernel test robot <lkp@intel.com>
> > > 
> > > All errors (new ones prefixed by >>):
> > > 
> > >    mips64-linux-ld: mm/page_alloc.o: in function `free_area_init':
> > > >> (.init.text+0x1680): undefined reference to `node_data'
> > >    mips64-linux-ld: (.init.text+0x1690): undefined reference to `node_data'
> > 
> > OK, I can see what is going here. The page allocator normally
> > uses NODE_DATA but arch_refresh_nodedata refers to node_data directly.
> > This is a problem with
> > arch/mips/include/asm/mach-loongson64/mmzone.h:
> > extern struct pglist_data *__node_data[];
> > 
> > #define NODE_DATA(n)            (__node_data[n])
> > 
> > Unfortunately we cannot use NODE_DATA there because of header inclusion
> > ordering. I will think about a solution.
> 
> Is there any reason why (some?) MIPS arches use __node_data rather than
> node_data as most other architectures? Would it be acceptable to do the
> renaming? It would help to cover the above compilation problem because
> arch_refresh_nodedata could keep using node_data directly.

I've just checked history and I don't see a reason for __node_data.
So I'm fine with changing it to node_data.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

WARNING: multiple messages have this Message-ID (diff)
From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
To: kbuild-all@lists.01.org
Subject: Re: undefined reference to `node_data'
Date: Thu, 24 Mar 2022 10:04:43 +0100	[thread overview]
Message-ID: <20220324090443.GA5375@alpha.franken.de> (raw)
In-Reply-To: <YjtPAwl/lhh+n3c2@dhcp22.suse.cz>

[-- Attachment #1: Type: text/plain, Size: 1511 bytes --]

On Wed, Mar 23, 2022 at 05:46:59PM +0100, Michal Hocko wrote:
> > > If you fix the issue, kindly add following tag as appropriate
> > > Reported-by: kernel test robot <lkp@intel.com>
> > > 
> > > All errors (new ones prefixed by >>):
> > > 
> > >    mips64-linux-ld: mm/page_alloc.o: in function `free_area_init':
> > > >> (.init.text+0x1680): undefined reference to `node_data'
> > >    mips64-linux-ld: (.init.text+0x1690): undefined reference to `node_data'
> > 
> > OK, I can see what is going here. The page allocator normally
> > uses NODE_DATA but arch_refresh_nodedata refers to node_data directly.
> > This is a problem with
> > arch/mips/include/asm/mach-loongson64/mmzone.h:
> > extern struct pglist_data *__node_data[];
> > 
> > #define NODE_DATA(n)            (__node_data[n])
> > 
> > Unfortunately we cannot use NODE_DATA there because of header inclusion
> > ordering. I will think about a solution.
> 
> Is there any reason why (some?) MIPS arches use __node_data rather than
> node_data as most other architectures? Would it be acceptable to do the
> renaming? It would help to cover the above compilation problem because
> arch_refresh_nodedata could keep using node_data directly.

I've just checked history and I don't see a reason for __node_data.
So I'm fine with changing it to node_data.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

  reply	other threads:[~2022-03-24  9:05 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-23 12:58 undefined reference to `node_data' kernel test robot
2022-03-23 14:53 ` Michal Hocko
2022-03-23 14:53   ` Michal Hocko
2022-03-23 16:46   ` Michal Hocko
2022-03-23 16:46     ` Michal Hocko
2022-03-24  9:04     ` Thomas Bogendoerfer [this message]
2022-03-24  9:04       ` Thomas Bogendoerfer
2022-03-24 12:40       ` Michal Hocko
2022-03-24 12:40         ` Michal Hocko
2022-03-25  1:16         ` [kbuild-all] " Chen, Rong A
2022-03-25  3:40           ` Tiezhu Yang
2022-03-25  3:40             ` Tiezhu Yang
2022-03-25  7:46             ` [kbuild-all] " Michal Hocko
2022-03-25  7:46               ` Michal Hocko

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=20220324090443.GA5375@alpha.franken.de \
    --to=tsbogend@alpha.franken.de \
    --cc=akpm@linux-foundation.org \
    --cc=kbuild-all@lists.01.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lkp@intel.com \
    --cc=mhocko@suse.com \
    --cc=osalvador@suse.de \
    /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.