On Sat, 2006-02-11 at 03:43 -0700, Eric W. Biederman wrote:
> Kirill Korotaev <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
