Messages in this thread | | | Subject | Re: RFC [patch 13/34] PID Virtualization Define new task_pid api | From | (Eric W. Biederman) | Date | Mon, 23 Jan 2006 12:28:14 -0700 |
| |
Hubertus Franke <frankeh@watson.ibm.com> writes:
> Eric W. Biederman wrote: >> Hubertus Franke <frankeh@watson.ibm.com> writes: >> Any place the kernel saves a pid and then proceeds to signal it later. >> At that later point in time it is possibly you will be in the wrong >> context. >> > > Yes, that's possible.. In the current patch that is not a problem, because > the internal pid (aka kpid) == <vpid,containerid> mangeled together. > So in those cases, the kernel would have to keep <pid, container_id>
Agreed, and for the internal implementation I think having them mangled together make sense, so long as we never export that form to userspace.
>> This probably justifies having a kpid_t that has both the process >> space id and the pid in it. For when the kernel is storing pids to >> use as weak references, for signal purposes etc. >> > > An that's what the current patch does. Only thing is we did not rename > everything to kpid_t!
Yep. But because of that you couldn't detect mixing of pid and kpid.
>> At least tty_io.c and fcntl.c have examples where you the caller >> may not have the proper context. > > Can you point those out directly .. thanks..
Short version. tty's send signals on hangup and f_setown can trigger signals being sent.
Eric
- 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/
| |