lkml.org 
[lkml]   [2006]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: RFC [patch 13/34] PID Virtualization Define new task_pid api
From
Date
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/

\
 
 \ /
  Last update: 2006-01-25 19:05    [W:0.134 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site