linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serue@us.ibm.com>
To: Vitaliy Gusev <vgusev@openvz.org>
Cc: "Serge E. Hallyn" <serue@us.ibm.com>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	linux-fsdevel@vger.kernel.org,
	Linux Containers <containers@lists.osdl.org>,
	Pavel Emelyanov <xemul@sw.ru>
Subject: Re: [RFC][PATCH] Pid namespaces vs locks interaction
Date: Thu, 13 Dec 2007 10:40:55 -0600	[thread overview]
Message-ID: <20071213164055.GA13580@sergelap.austin.ibm.com> (raw)
In-Reply-To: <200712131713.56564.vgusev@openvz.org>

Quoting Vitaliy Gusev (vgusev@openvz.org):
> On 12 December 2007 21:42:25 Serge E. Hallyn wrote:
> > Ok sorry - by letting this thread sit a few days I lost track of where
> > we were.
> >
> > I see now, so you're saying fl_pid for nfs is not in fact a task pid.
> > It's a magically derived unique id.  (And you say it is unique across
> > all the nfs clients?)
> 
> It is unique for pair client,server.
> 
> >
> > So does the p in fl_pid stand for something, or could we rename it to
> > fl_id or fl_uniqueid?
> 
> If fl_pid will be renamed with fl_uniqueid or something, it still need 
> accessing from fs/locks.c: cat /proc/locks shows pids which also are NFS  
> pids (unique id). 
> 
> For example, let's look the /proc/locks in my system (NFS-server) when do 
> flock on a NFS client:
> 
> 1: POSIX  ADVISORY  WRITE 2 08:06:63116 0 EOF
> 2: POSIX  ADVISORY  WRITE 7047 08:09:1899694 0 EOF
> 3: FLOCK  ADVISORY  WRITE 3334 08:06:110497 0 EOF
> 4: FLOCK  ADVISORY  WRITE 3265 08:06:94786 0 EOF
> 5: POSIX  ADVISORY  WRITE 2582 08:06:110462 0 EOF
> 
> It indicates that process with pid 2 has a posix lock. Really it is a NFS 
> unique id. Problem can be solved by using pid of lockd.
> 
> > Maybe that's too much bother, but so long as we're bothering with a pid
> > cleanup at all it seems worth it to me.  On the other hand maybe
> > J. Bruce Fields was right and we should accept the fact that the
> > flock->fl_pid shouldn't be taken too seriously, and leave it be.
> 
> Mix pids from some namespaces is not good. We can store process pid seen from 

Agreed, and that was the basis for my earlier objection.

It sounds like it's clear to all people smarter than I that fl_pid is
not really a pid, so there is no reason for changing the name.  And your
patch (contrary to my earlier read of it) only translates fl_nspid into
fl_pids in temporary flocks being passed to userspace, through fcntl and
/proc/locks.

So I completely withdraw my objection.

Except, for the sake of other cognitively challenged types like myself,
could you add a comment by fl_pid and fl_nspid in fs.h, to the effect of

	unsigned int fl_pid;  /* unique id and sometimes global pid */
	struct pid *fl_nspid; /* to calculate owner pid_nr for userspace */

(or something more accurate if I'm off)?

So after all that,

Acked-by: Serge Hallyn <serue@us.ibm.com>

(sorry)

thanks,
-serge

> init namespace to the flock->fl_pid (instead pid from the current namespace). 
> Thus fcntl(F_GETLK,...) and  "cat /proc/locks" will show global pids.   But 
> some LTP tests can fail.



  reply	other threads:[~2007-12-13 16:42 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200712061411.32159.vgusev@openvz.org>
2007-12-06 12:57 ` [RFC][PATCH] Pid namespaces vs locks interaction Vitaliy Gusev
2007-12-06 14:53   ` Serge E. Hallyn
2007-12-06 15:19     ` Vitaliy Gusev
2007-12-06 15:51       ` Serge E. Hallyn
2007-12-08 22:21         ` Brad Boyer
     [not found]         ` <20071206155130.GA12463-6s5zFf/epYLPQpwDFJZrxKsjOiXwFzmk@public.gmane.org>
2007-12-12 16:07           ` Vitaliy Gusev
2007-12-12 17:31             ` Serge E. Hallyn
     [not found]               ` <20071212173115.GA21956-6s5zFf/epYLPQpwDFJZrxKsjOiXwFzmk@public.gmane.org>
2007-12-12 17:42                 ` Vitaliy Gusev
2007-12-12 18:42                   ` Serge E. Hallyn
     [not found]                     ` <20071212184225.GA23504-6s5zFf/epYLPQpwDFJZrxKsjOiXwFzmk@public.gmane.org>
2007-12-13 14:13                       ` Vitaliy Gusev
2007-12-13 16:40                         ` Serge E. Hallyn [this message]
2007-12-06 22:15   ` J. Bruce Fields
2007-12-07 14:51     ` Serge E. Hallyn
2007-12-21 12:22 ` [PATCH] " Vitaliy Gusev
2007-12-21 14:42   ` Serge E. Hallyn
2007-12-22  0:50   ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071213164055.GA13580@sergelap.austin.ibm.com \
    --to=serue@us.ibm.com \
    --cc=bfields@fieldses.org \
    --cc=containers@lists.osdl.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=vgusev@openvz.org \
    --cc=xemul@sw.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).