Messages in this thread | | | Subject | Re: RFC [patch 13/34] PID Virtualization Define new task_pid api | From | (Eric W. Biederman) | Date | Wed, 25 Jan 2006 11:01:34 -0700 |
| |
Trond Myklebust <trond.myklebust@fys.uio.no> writes:
> On Wed, 2006-01-25 at 02:58 -0700, Eric W. Biederman wrote: >> >> On Maw, 2006-01-24 at 12:26 -0700, Eric W. Biederman wrote: >> >> > There is at least NFS lockd that appreciates having a single integer >> >> > per process unique identifier. So there is a practical basis for >> >> > wanting such a thing. > > The NFS lock manager mainly wants a unique 32-bit identifier that can > follow clone(CLONE_FILES). The reason is that the Linux VFS is forced to > use the pointer to the file table as the "process identifier" for posix > locks (i.e. fcntl() locks).
Ok. I think I was thinking of a different case, but if I missed one this could explain the weirdness I was seeing.
Let me list the cases I know of and see if I hit what you are thinking of.
fs/nfs/nfs3proc.c:nfs3_proc_create() For O_EXCL we have arg.verifier = current->pid.
fs/lockd/clntproc.c:nlmclnt_setlockargs() We have: lock->oh.len = sprintf(req->a_owner, "%d@%s", current->pid, system_utsname.nodename);
I think this is the fcntl() case. I would suggest fl_pid might have something to do with it but that is part flock based locking.
So I'm not certain I see the part of NFS you are refering to.
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/
| |