Re: [RFC][PATCH 04/20] pspace: Allow multiple instaces of the process id namespace

[Dave Hansen <haveblue@us.ibm.com>]

On Sat, 2006-02-11 at 03:43 -0700, Eric W. Biederman wrote:
> Kirill Korotaev <dev@sw.ru> writes:
> >> +static inline int pspace_task_visible(struct pspace *pspace, struct
> > task_struct *tsk)
> >> +{
> >> +	return (tsk->pspace == pspace) ||
> >> +		((tsk->pspace->child_reaper.pspace == pspace) &&
> >> +		 (tsk->pspace->child_reaper.task == tsk));
> > <<< the logic with child_reaper which can be somehow partly inside pspace... and
> > this check is not that abvious.
> 
> This is the check for what shows up in /proc.
> 
> Given that is how I have explicitly documented things to work, (the
> init process straddles the boundary) I fail to see how it is not obvious.  

I'd claim that the (tsk->pspace == pspace) test is pretty obvious.

However, the child_reaper one takes a little deduction.  Sometimes, I
think separating out even trivial functions into even trivialler :)
functions really does make sense for these.  They can be really
confusing.  BTW, I _still_ don't understand exactly what this is doing,
but I haven't had any coffee.

Is something like this more clear?

static inline int pspace_task_visible(struct pspace *pspace, struct
task_struct *tsk)
{
	if (tsk->pspace == pspace)
		return 1;

	/*
	 * Init tasks straggle namespaces.  They have the explicit
	 * pspace of their parent, but are visible from thier
	 * children.
	 */
	if (pspace_child_reaper_is_task(pspace, tsk)
		return 1;

	return 0;
}

int pspace_child_reaper_is_task(struct pspace *pspace,
				struct task_struct *tsk)
{
	if ((tsk->pspace->child_reaper.pspace == pspace) &&
	    (tsk->pspace->child_reaper.task == tsk))
		return 1;

	return 0;
}

-- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/