Re: [PATCH] autofs: fix the wrong usage of the deprecatedtask_pgrp_nr()

[Oleg Nesterov]

On 01/19, Ian Kent wrote:
>
> On Mon, 2009-01-19 at 13:42 +0100, Oleg Nesterov wrote:
> >
> > Before the patch
> >
> > 	sbi->oz_pgrp != task_pgrp(automount)
> >
> > After the patch
> >
> > 	sbi->oz_pgrp == task_pgrp(automount)
> >
> > And please note that these "!="/"==" apply to any namespace. I mean,
> > when we call autofs_oz_mode() it does not matter in which namespace
> > autofs_oz_mode() is executed, we compare "struct pid*", not pid_t.
>
> I think your saying that the option pgrp= is broken and should be
> deprecated

No, no, sorry if I confused you.

If the "pgrp=" option was specified, the patch has no effect, and the
code is correct with or without the patch.

> It's interesting that your description appears to assume the the same
> process may appear in different pid namespaces (am I right?)

Yes. It is visible in its own namespace, in the ->parent namespace,
->parent->parent, and so on until the global init_pid_ns.

> whereas in
> the descriptions I have been writing I'm thinking of pid namspeces as
> having there own set of proceses and not being able to see processes
> outside the space.

Yes, we can not see the tasks outside the space (but of course we can
see the tasks from the child namespaces).

IOW. Let's suppose we are in the global namespace, and some task
forks the child C via clone(CLONE_NEWPID).

Now, in the global namespace it has, say, pid == 100. But when
C does sys_getpid() it gets 1.

C can not see the tasks from the global namespace, but any task
from the global ns can see C with pid == 100.

And please note that C has the single "struct pid" wchich represents
all pid_t's. The same for pgrp/session. task_pgrp() returns the same
pid (pointer to the struct, not pid_t), no matter in which namespace
the code runs. But the result of pid_vnr(pid) or find_pid(pid_nr) do
differ depending on current->nsproxy->pid_ns.

Oleg.

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