[ltt-dev] [UST PATCH] Only send the pids that are currently online in ustclt_get_online_pids().

[Mathieu Desnoyers]

* Matthew Khouzam (matthew.khouzam at gmail.com) wrote:
> 
> Signed-off-by: Matthew Khouzam <matthew.khouzam at ericsson.com>
> ---
>  libustctl/libustctl.c |   14 +++++++++++++-
>  1 files changed, 13 insertions(+), 1 deletions(-)
> 
> diff --git a/libustctl/libustctl.c b/libustctl/libustctl.c
> index d57e645..443cbb9 100644
> --- a/libustctl/libustctl.c
> +++ b/libustctl/libustctl.c
> @@ -92,6 +92,8 @@ pid_t *ustctl_get_online_pids(void)
>  {
>  	struct dirent *dirent;
>  	DIR *dir;
> +	DIR *proc_dir;
> +	char proc_dir_path[PATH_MAX];
>  	unsigned int ret_size = 1 * sizeof(pid_t), i = 0;
>  
>  	dir = opendir(SOCK_DIR);
> @@ -117,7 +119,17 @@ pid_t *ustctl_get_online_pids(void)
>  			 * We need to figure out an intelligent way of solving
>  			 * this, maybe connect-disconnect.
>  			 */
> -			if (1) {
> +			 snprintf(proc_dir_path, PATH_MAX, "/proc/%u/", ret[i]);
> +			 proc_dir = opendir(proc_dir_path);

Where do you free proc_dir ? I think you have a memory leak here.

> +			 /*
> +			  * Note:
> +			  * maybe we should remove the empty dir in this pass
> +			  * too. Since the detection method is not perfect,
> +			  * this step is not yet implemented.
> +			  * A process can die, and its pid can be still taken
> +			  * when reading online pids.

Yes, that's racy. We can have a new process coming up and reusing a PID
of an old process that died concurrently with us poking /proc to see
which processes are there. So deleting the socket file non-atomically
with the /proc PID dir verifcation is really asking for trouble.

The only way I can see us doing the socket file removal relatively
racelessly is if we synchronize the creation/removal of these files in a
centralized place, e.g. in ltt-sessiond eventually.

Could you update your comment to reflect this thought ?

Thanks,

Mathieu

> +			  */
> +			 if (proc_dir) {
>  				ret_size += sizeof(pid_t);
>  				ret = (pid_t *) realloc(ret, ret_size);
>  				++i;
> -- 
> 1.7.0.4
> 
> 
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> 

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com