From mboxrd@z Thu Jan 1 00:00:00 1970 From: "J. Bruce Fields" Subject: Re: [RFC][PATCH] Pid namespaces vs locks interaction Date: Thu, 6 Dec 2007 17:15:10 -0500 Message-ID: <20071206221510.GF10953@fieldses.org> References: <200712061411.32159.vgusev@openvz.org> <200712061557.29543.vgusev@openvz.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org To: Vitaliy Gusev Return-path: Received: from mail.fieldses.org ([66.93.2.214]:57976 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751739AbXLFWPM (ORCPT ); Thu, 6 Dec 2007 17:15:12 -0500 Content-Disposition: inline In-Reply-To: <200712061557.29543.vgusev@openvz.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, Dec 06, 2007 at 03:57:29PM +0300, Vitaliy Gusev wrote: > 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. Forgive me, I'm not familiar with pid namespaces. Exactly what bug does this patch aim to fix? > @@ -673,14 +682,16 @@ posix_test_lock(struct file *filp, struct file_lock *fl) > if (posix_locks_conflict(fl, cfl)) > break; > } > - if (cfl) > + if (cfl) { > __locks_copy_lock(fl, cfl); > - else > + if (cfl->fl_nspid) > + fl->fl_pid = pid_nr_ns(cfl->fl_nspid, > + task_active_pid_ns(current)); What does pid_nr_ns() do? I took a quick look at the implementation and didn't get it. I tend to think that the pid returned by fcntl(.,F_GETLK,.) shouldn't be taken too seriously--it may be helpful when debugging--e.g. it might help an administrator looking for clues as to who's holding some annoying lock. But it probably shouldn't be depended on for the correctness of an application. Maybe I'm wrong and there's some reason we should worry about it more. It's also likely to be wrong in the presence of locks held on behalf of nfs clients. --b.