From: Vitaliy Gusev <vgusev@openvz.org>
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
linux-fsdevel@vger.kernel.org,
Linux Containers <containers@lists.osdl.org>
Subject: Re: [RFC][PATCH] Pid namespaces vs locks interaction
Date: Thu, 6 Dec 2007 18:19:59 +0300 [thread overview]
Message-ID: <200712061819.59841.vgusev@openvz.org> (raw)
In-Reply-To: <20071206145340.GB7083@sergelap.austin.ibm.com>
On 6 December 2007 17:53:40 Serge E. Hallyn wrote:
> Quoting Vitaliy Gusev (vgusev@openvz.org):
> > Hello!
> >
> > I am working on pid namespaces vs locks interaction and want to evaluate
> > the idea.
> > fcntl(F_GETLK,..) can return pid of process for not current pid namespace
> > (if process is belonged to the several namespaces). It is true also for
> > pids in /proc/locks. So correct behavior is saving pointer to the struct
> > pid of the process lock owner.
> > --
> > Thank,
> > Vitaliy Gusev
> >
> > diff --git a/fs/locks.c b/fs/locks.c
> > index 8b8388e..d2d3d75 100644
> > --- a/fs/locks.c
> > +++ b/fs/locks.c
> > @@ -125,6 +125,7 @@
> > #include <linux/syscalls.h>
> > #include <linux/time.h>
> > #include <linux/rcupdate.h>
> > +#include <linux/pid_namespace.h>
> >
> > #include <asm/semaphore.h>
> > #include <asm/uaccess.h>
> > @@ -185,6 +186,7 @@ void locks_init_lock(struct file_lock *fl)
> > fl->fl_fasync = NULL;
> > fl->fl_owner = NULL;
> > fl->fl_pid = 0;
> > + fl->fl_nspid = NULL;
>
> The idea seems right, but why are you keeping fl->fl_pid around?
>
> Seems like the safer thing to do would be to have a separate
> struct user_flock, with an integer pid, for communicating to userspace,
> and a struct flock, with struct pid, for kernel use? Then fcntl_getlk()
> and fcntl_setlk() do the appropriate conversions.
fl_pid is used by nfs, fuse and gfs2. For instance nfs keeps in fl_pid some
unique id to identify locking process between hosts - it is not a process
pid.
>
> thanks,
> -serge
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Thank,
Vitaliy Gusev
next prev parent reply other threads:[~2007-12-06 15:19 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 [this message]
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
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=200712061819.59841.vgusev@openvz.org \
--to=vgusev@openvz.org \
--cc=bfields@fieldses.org \
--cc=containers@lists.osdl.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=serue@us.ibm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.