On 6 December 2007 17:53:40 Serge E. Hallyn wrote: > Quoting Vitaliy Gusev (vgusev@xxxxxxxxxx): > > 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Thank, Vitaliy Gusev - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
