linux-numa.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
To: Cliff Wickman <cpw@sgi.com>
Cc: linux-numa <linux-numa@vger.kernel.org>
Subject: Re: numactl-2.0.4-rc3 addition
Date: Mon, 12 Jul 2010 17:00:02 -0400	[thread overview]
Message-ID: <1278968402.3514.300.camel@localhost.localdomain> (raw)
In-Reply-To: <20100702224336.GA19438@sgi.com>

On Fri, 2010-07-02 at 17:43 -0500, Cliff Wickman wrote: 
> Hi again,
> 
> On Fri, Jul 02, 2010 at 03:54:38PM -0500, Cliff Wickman wrote:
> > Hi linux-numa members,
> > 
> > numactl-2.0.4-rc3.tar.gz
> > is now on ftp://oss.sgi.com/www/projects/libnuma/download/
> > 
> > It includes:
> > - Fix numactl for a machine with sparse cpu ids (Anton Blanchard)
> > - Fix makefile to remove move_pages on make clean (Andi)
> > - Fix numa_node_to_cpus() (Sharyathi Nagesh)
> > - Rename 'thread' to 'task' (Lee Schermerhorn)
> > - Remove other trailing spaces (Cliff)
> > 
> > and recently:
> > - Man page correction/clarification for numa_node_to_cpus() (Ian Wienand)
> > - Man page clarification for numactl (Mike MacCana)
> > - Fix numactl --hardware for cpu-less nodes (Thomas Renninger)
> > - Fix set_configured_cpus() (Jan Beulich)
> > - Fix memory corrupting use of strlen (Jan Beulich)
> 
> I found one other patch that for some reason had never been applied:
> - Add a DSO destructor for memory deallocation (Neil Horman)
> 
> It is now included in numactl-2.0.4-rc3.tar.gz.

Cliff:

What happened to "nodes_allowed_list" ?

I'm trying to build 2.0.4-rc3 on a RHEL6b2 install and I'm seeing:

cc   numactl.o util.o shm.o bitops.o libnuma.so   -o numactl
libnuma.so: undefined reference to `nodes_allowed_list'
collect2: ld returned 1 exit status
make: *** [numactl] Error 1


rc2 builds fine.  diffing libnuma.c rc2:rc3:  I see:

--- ../numactl-2.0.4-rc2/libnuma.c       2010-04-08 10:08:17.000000000 -0400
+++ ./libnuma.c 2010-07-02 18:40:21.000000000 -0400
@@ -54,8 +54,6 @@
 static unsigned long *node_cpu_mask_v1[NUMA_NUM_NODES];
 struct bitmask **node_cpu_mask_v2;
 
-char *nodes_allowed_list = NULL;
-
 WEAK void numa_error(char *where);
 
 #ifdef __thread
@@ -95,6 +93,19 @@
        memset(&numa_no_nodes, 0, sizeof(numa_no_nodes));
 }
 
+void
+numa_fini(void)
+{
+       if (numa_all_cpus_ptr)
+               numa_bitmask_free(numa_all_cpus_ptr);
+       if (numa_all_nodes_ptr)
+               numa_bitmask_free(numa_all_nodes_ptr);
+       if (numa_no_nodes_ptr)
+               numa_bitmask_free(numa_no_nodes_ptr);
+       if (nodes_allowed_list)
+               free(nodes_allowed_list);
+}
+
 /*
  * The following bitmask declarations, bitmask_*() routines, and associated
  * _setbit() and _getbit() routines are:
@@ -460,12 +471,6 @@
                        maxprocnode =
                                read_mask(mask, numa_all_nodes_ptr);
                }
-               if (strncmp(buffer,"Mems_allowed_list:",18) == 0) {
-                       nodes_allowed_list = malloc(strlen(buffer)-18);
-                       strncpy(nodes_allowed_list, buffer + 19,
-                               strlen(buffer) - 19);
-                       nodes_allowed_list[strlen(nodes_allowed_list)-1] = '\0';
-               }
        }
        fclose(f);
        free(buffer);
<snip>

So, it looks like the nodes_allowed_list was removed while the
destructor was being added to free it.  Is the removal intentional?  If
so, the patch below allows it to build.

Lee

Remove free of undefined nodes_allowed_list from destructor and
numa header.

 libnuma.c |    2 --
 numa.h    |    2 --
 2 files changed, 4 deletions(-)

Index: numactl-2.0.4-rc3/libnuma.c
===================================================================
--- numactl-2.0.4-rc3.orig/libnuma.c	2010-07-02 18:40:21.000000000 -0400
+++ numactl-2.0.4-rc3/libnuma.c	2010-07-12 16:52:49.000000000 -0400
@@ -102,8 +102,6 @@ numa_fini(void)
 		numa_bitmask_free(numa_all_nodes_ptr);
 	if (numa_no_nodes_ptr)
 		numa_bitmask_free(numa_no_nodes_ptr);
-	if (nodes_allowed_list)
-		free(nodes_allowed_list);
 }
 
 /*
Index: numactl-2.0.4-rc3/numa.h
===================================================================
--- numactl-2.0.4-rc3.orig/numa.h	2010-07-02 18:40:21.000000000 -0400
+++ numactl-2.0.4-rc3/numa.h	2010-07-12 16:52:38.000000000 -0400
@@ -161,8 +161,6 @@ extern struct bitmask *numa_no_nodes_ptr
 /* Source compatibility */
 extern nodemask_t numa_no_nodes;
 
-extern char *nodes_allowed_list;
-
 /* Only run and allocate memory from a specific set of nodes. */
 void numa_bind(struct bitmask *nodes);
 


  reply	other threads:[~2010-07-12 21:00 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-02 20:54 numactl-2.0.4-rc3 Cliff Wickman
2010-07-02 22:43 ` numactl-2.0.4-rc3 addition Cliff Wickman
2010-07-12 21:00   ` Lee Schermerhorn [this message]
2010-07-12 22:27     ` Cliff Wickman

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=1278968402.3514.300.camel@localhost.localdomain \
    --to=lee.schermerhorn@hp.com \
    --cc=cpw@sgi.com \
    --cc=linux-numa@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).