Re: RFC [patch 13/34] PID Virtualization Define new task_pid api

[ebiederm@xmission.com (Eric W. Biederman)]

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/