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.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
