From: Cliff Wickman <cpw@sgi.com>
To: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Cc: linux-numa <linux-numa@vger.kernel.org>
Subject: Re: numactl-2.0.4-rc3 addition
Date: Mon, 12 Jul 2010 17:27:16 -0500 [thread overview]
Message-ID: <20100712222716.GA5234@sgi.com> (raw)
In-Reply-To: <1278968402.3514.300.camel@localhost.localdomain>
Hi Lee,
On Mon, Jul 12, 2010 at 05:00:02PM -0400, Lee Schermerhorn wrote:
> 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
Huh. Don't know why I didn't encounter that error myself. I must
have missed a step.
> 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.
Looks like it should have been removed, as it is not referenced.
I included your change in Neil's patch (removed the free and removed
the reference in numa.h, and in ldscript).
The -rc3 tarball is updated with that fix.
Thanks for the test and the detective work.
-Cliff
>
> 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);
>
>
--
Cliff Wickman
SGI
cpw@sgi.com
(651) 683-3824
prev parent reply other threads:[~2010-07-12 22:27 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
2010-07-12 22:27 ` Cliff Wickman [this message]
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=20100712222716.GA5234@sgi.com \
--to=cpw@sgi.com \
--cc=Lee.Schermerhorn@hp.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 read-only IMAP folder(s) and NNTP newsgroup(s).