@@ -47,6 +47,7 @@ nlm4svc_retrieve_args(struct svc_rqst *rqstp, struct nlm_args *argp,
/* Set up the missing parts of the file_lock structure */
lock->fl.fl_file = file->f_file;
lock->fl.fl_owner = (fl_owner_t) host;
+ lock->fl.fl_pid = current->tgid;
lock->fl.fl_lmops = &nlmsvc_lock_operations;
}
@@ -77,6 +77,7 @@ nlmsvc_retrieve_args(struct svc_rqst *rqstp, struct nlm_args *argp,
/* Set up the missing parts of the file_lock structure */
lock->fl.fl_file = file->f_file;
lock->fl.fl_owner = (fl_owner_t) host;
+ lock->fl.fl_pid = current->tgid;
lock->fl.fl_lmops = &nlmsvc_lock_operations;
}
In commit 9d5b86ac13c5 "fs/locks: Remove fl_nspid and use fs-specific l_pid for remote locks" the fl_pid number is translated into the namespace of the viewer when the viewer looks at the lock, and if a lock's fl_pid does not belong to the viewer's pid namespace then that lock is not displayed in /proc/locks or /proc/<pid>/fdinfo/<fd>. That change made it easy to notice that NLM has been using an uninitialized value for fl_pid when NLM locks would only show up in the listings if their fl_pid values happened to collide with existing pids. Fix this by correctly initializing fl_pid. Signed-off-by: Benjamin Coddington <bcodding@redhat.com> --- fs/lockd/svc4proc.c | 1 + fs/lockd/svcproc.c | 1 + 2 files changed, 2 insertions(+)