Refactor the post_opt handling code embedded in _spank_init() into
a spank_stack_post_opt() function, then call this in remote context
from a new spank_init_remote() function.

Instead of trying to handle missing plugstack.conf early in the code,
just treat missing plugstack.conf the same as an empty config.

Move struct spank_stack initialization code into a spank_stack_init()
function so that it can be called from multiple call sites.

Simplify code in _do_call_stack() by extracting case statement
to assign current callback symbol to its own function. Since all
spank functions have the same prototype we can then use the same
code to call _all_ callbacks, reducing greatly the number of lines
of code required.

Consolidate common code in spank_getenv, spank_setenv, spank_unsetenv
which checks for validity of the current context, spank handle, etc.

Consilidate checks for correct spank context in spank_job_control*
functions to avoid code duplication.

The use of globals in plugstack.c is cumbersome and prevents the
future expansion of spank plugins, e.g. calling spank plugins from
multiple contexts within the same process or reinitializing the
spank plugin state.

This patch consolidates the current globals (spank_stack, spank_ctx,
spank_optval, and option_cache) into a global "spank stack" structure
and expands many of the functions internal to plugstack.c to operate
on a struct spank_stack instead of globally.

There was likely a typo/thinko/patcho in the handling of the
return code from _do_call_stack(SPANK_INIT_POST_OPT) in _spank_init
in "remote" context. This error caused spank_init() to always
succeed, since the test less than zero would always return 0 or 1.

Avoid loading the same plugin more than once in plugstack.c.
Most likely this will be a configuration error, so we should
catch it early. If the same .so appears in the plugin stack
more than once, it is likely to cause very strange errors,
since dlopen() will only map the library a single time.

Change the owner of slurmctld and slurmdbd log files to the appropriate
user. Without this change the files will be created by and owned by the
user starting the daemons (likely user root).

CRAY: Fix support for configuration with SlurmdTimeout=0 (never mark
node that is DOWN in ALPS as DOWN in SLURM).

in the tightly coupled functions slurmd:stepd_completion and
slurmstepd:_handle_completion, a jobacct structure is
send from the main daemon to the step daemon to provide
the statistics of the children slurmstepd and do the aggregation.

The methodology used to send the structure is the use of
jobacct_gather_g_{setinfo,getinfo} over a pipe (JOBACCT_DATA_PIPE).
As {setinfo,getinfo} use a common internal lock and reading
or writing to a pipe is equivalent to holding a lock, slurmd and
slurmstepd have to avoid using both setinfo and getinfo over a
pipe or deadlock situations can occured. For example :
slurmd(lockforread,write)/slurmstepd(write,lockforread).

This patch remove the call to jobacct_gather_g_setinfo in slurmd
and the call to jobacct_gather_g_getinfo in slurmstepd ensuring
that slurmd only do getinfo operations over a pipe and slurmstepd
only do setinfo over a pipe. Instead jobacct_gather_g_{pack,unpack}
are used to marshall/unmarshall the data for transmission over the
pipe.
Patch by Matthieu Hautreux, CEA.

The patch committed here is a variation on the work by Matthieu.
Specifically, the logic is added to slurmstepd to read a new format
of RPC including an RPC version number and buffer with the data
structure. The slurmd however will not send the RPC in the new format
until SLURM version 2.5.

Replace some " \t" with just "\t" (that's a tab)

Improve support for overlapping advanced reservations.
Patch from Bill Brophy, Bull.

Added PriorityFlags configuration parameter

task/cgroup: minor job step memcg fixes

Improve task binding logic by making fuller use of HWLOC library,
especially with respect to Opteron 6000 series processors. Work contributed
by Komoto Masahiro.

The current task/cgroup memory code writes to force_empty at job step
completion and then waits for the release agent to be triggered to
remove the memcg. However, force_empty only causes clean cache pages
to be dropped from the memcg and does not actually move charges to
the parent [1].

This has two unfortunate side-effects. First, pages that can't be
dropped by force_empty are in-use and could stay that way indefinitely
(e.g. system library that is in-use until just after force_empty
completes). Thus, the step memcg never becomes 'empty' and the release
agent is not activated. Second, cached pages that can be freed are
likely associated with the job itself, and those files and libraries
will have to be paged in again for subsequent job steps.

In contrast, calling rmdir(2) on a memcg with no active tasks
causes *all* current charges to move to parent, which is really what
we want in this case. This allows cached libraries and binaries to
stay resident and be associated with the job, and also ensures that
the step memcg is removed immediately as the job step ends.

Thus, this patch replaces the write to force_empty with a call
to xcgroup_delete() on the step memcg, which in turn removes
the memcg with rmdir(2).

The functionality of this patch depends on the previous fix that
uses xcgroup_move_process() to move slurmstepd to the root memcg.
Otherwise, there will be leftover slurmstepd threads in the job
step memcg, and the rmdir will fail with EBUSY.

 [1] Sec 4.3: http://www.kernel.org/doc/Documentation/cgroups/memory.txt

In task_cgroup_memory_fini() the implementation attempts to move
the existing slurmstepd task to the root memory cgroup by writing
the result of getpid(2) to the root memory's 'task' file. This
does not work, however, because slurmstepd is multi-threaded and
thus only the main thread is moved.

This patch replaces the explicit write to 'tasks' with a call to
the new xcgroup_move_process() call, which handles moving all
threads in the process.

This patch adds a helper function to common/xcgroup.c to aid
in moving processes between cgroups. If the cgroups.procs file
is writable then writing the PID to that file is used, as this
method moves all threads in a process atomically.

If cgroups.procs is not writable, then each thread must be moved
individually by walking the /proc/PID/task/ directory and writing
each taskid individually to the 'tasks' file in the cgroup. The
second method is racy if a process is concurrently creating
threads, but it is better than the current method of just moving
one of the process's threads.

Conflicts:
	NEWS

Conflicts:
	META