Fixups for l_pid

Since commit c69899a17ca4 "NFSv4: Update of VFS byte range lock must be atomic with the stateid update", NFSv4 has been inserting locks in rpciod worker context. The result is that the file_lock's fl_nspid is the kworker's pid instead of the original userspace pid.

The fl_nspid is only used to represent the namespaced virtual pid number when displaying locks or returning from F_GETLK. There's no reason to set it for every inserted lock, since we can usually just look it up from fl_pid. So, instead of looking up and holding struct pid for every lock, let's just look up the virtual pid number from fl_pid when it is needed. That means we can remove fl_nspid entirely.

Signed-off-by Benjamin Coddington <[email protected]>

---
 fs/locks.c         | 58 ++++++++++++++++++++++++++++++++----------------------
 include/linux/fs.h |  1 -
 2 files changed, 35 insertions(+), 24 deletions(-)

fs/locks.c +7 -7

index d7daa6c8932f..104398ccc9b9 100644
@@ -733,7 +733,6 @@ static void locks_wake_up_blocks(struct file_lock *blocker)
 static void
 locks_insert_lock_ctx(struct file_lock *fl, struct list_head *before)
 {
-	fl->fl_nspid = get_pid(task_tgid(current));
 	list_add_tail(&fl->fl_list, before);
 	locks_insert_global_locks(fl);
 }

@@ -743,10 +742,6 @@ locks_unlink_lock_ctx(struct file_lock *fl)
 {
 	locks_delete_global_locks(fl);
 	list_del_init(&fl->fl_list);
-	if (fl->fl_nspid) {
-		put_pid(fl->fl_nspid);
-		fl->fl_nspid = NULL;
-	}
 	locks_wake_up_blocks(fl);
 }
 

@@ -823,8 +818,6 @@ posix_test_lock(struct file *filp, struct file_lock *fl)
 	list_for_each_entry(cfl, &ctx->flc_posix, fl_list) {
 		if (posix_locks_conflict(fl, cfl)) {
 			locks_copy_conflock(fl, cfl);
-			if (cfl->fl_nspid)
-				fl->fl_pid = pid_vnr(cfl->fl_nspid);
 			goto out;
 		}
 	}

@@ -2048,6 +2041,31 @@ int vfs_test_lock(struct file *filp, struct file_lock *fl)
 }
 EXPORT_SYMBOL_GPL(vfs_test_lock);
 
+/**
+ * locks_translate_pid - translate a pid number into a namespace
+ * @nr: The pid number in the init_pid_ns
+ * @ns: The namespace into which the pid should be translated
+ *
+ * Used to tranlate a fl_pid into a namespace virtual pid number
+ */

fs/locks.c +18 -16

+	if (!task)
+		goto out;
+	vnr = task_pid_nr_ns(task, ns);
+	put_task_struct(task);
+out:
+	return vnr;
+}
+
 static int posix_lock_to_flock(struct flock *flock, struct file_lock *fl)
 {
 	flock->l_pid = IS_OFDLCK(fl) ? -1 : fl->fl_pid;

@@ -2584,22 +2602,16 @@ static void lock_get_status(struct seq_file *f, struct file_lock *fl,
 {
 	struct inode *inode = NULL;
 	unsigned int fl_pid;
+	struct pid_namespace *proc_pidns = file_inode(f->file)->i_sb->s_fs_info;
 
-	if (fl->fl_nspid) {
-		struct pid_namespace *proc_pidns = file_inode(f->file)->i_sb->s_fs_info;
-
-		/* Don't let fl_pid change based on who is reading the file */
-		fl_pid = pid_nr_ns(fl->fl_nspid, proc_pidns);
-
-		/*
-		 * If there isn't a fl_pid don't display who is waiting on
-		 * the lock if we are called from locks_show, or if we are
-		 * called from __show_fd_info - skip lock entirely
-		 */
-		if (fl_pid == 0)
-			return;
-	} else
-		fl_pid = fl->fl_pid;
+	fl_pid = locks_translate_pid(fl->fl_pid, proc_pidns);
+	/*
+	 * If there isn't a fl_pid don't display who is waiting on
+	 * the lock if we are called from locks_show, or if we are
+	 * called from __show_fd_info - skip lock entirely
+	 */
+	if (fl_pid == 0)
+		return;
 
 	if (fl->fl_file != NULL)
 		inode = locks_inode(fl->fl_file);

@@ -2674,7 +2686,7 @@ static int locks_show(struct seq_file *f, void *v)
 
 	fl = hlist_entry(v, struct file_lock, fl_link);
 
-	if (fl->fl_nspid && !pid_nr_ns(fl->fl_nspid, proc_pidns))
+	if (locks_translate_pid(fl->fl_pid, proc_pidns) == 0)
 		return 0;
 
 	lock_get_status(f, fl, iter->li_pos, "");

include/linux/fs.h +0 -1

index aa4affb38c39..b013fac515f7 100644
@@ -984,7 +984,6 @@ struct file_lock {
 	unsigned char fl_type;
 	unsigned int fl_pid;
 	int fl_link_cpu;		/* what cpu's list is this on? */
-	struct pid *fl_nspid;
 	wait_queue_head_t fl_wait;
 	struct file *fl_file;
 	loff_t fl_start;

Quoted 5 lines · Benjamin Coddington

Since commit c69899a17ca4 "NFSv4: Update of VFS byte range lock must be atomic with the stateid update", NFSv4 has been inserting locks in rpciod worker context. The result is that the file_lock's fl_nspid is the kworker's pid instead of the original userspace pid.

Quoted 7 lines

The fl_nspid is only used to represent the namespaced virtual pid number when displaying locks or returning from F_GETLK. There's no reason to set it for every inserted lock, since we can usually just look it up from fl_pid. So, instead of looking up and holding struct pid for every lock, let's just look up the virtual pid number from fl_pid when it is needed. That means we can remove fl_nspid entirely.

With this set, I think we ought to codify that the stored pid must be relative

Quoted 51 lines

Signed-off-by Benjamin Coddington <[email protected]>

---
 fs/locks.c         | 58 ++++++++++++++++++++++++++++++++----------------------
 include/linux/fs.h |  1 -
 2 files changed, 35 insertions(+), 24 deletions(-)

fs/locks.c +7 -7

index d7daa6c8932f..104398ccc9b9 100644
@@ -733,7 +733,6 @@ static void locks_wake_up_blocks(struct file_lock *blocker)
 static void
 locks_insert_lock_ctx(struct file_lock *fl, struct list_head *before)
 {
-	fl->fl_nspid = get_pid(task_tgid(current));
 	list_add_tail(&fl->fl_list, before);
 	locks_insert_global_locks(fl);
 }

@@ -743,10 +742,6 @@ locks_unlink_lock_ctx(struct file_lock *fl)
 {
 	locks_delete_global_locks(fl);
 	list_del_init(&fl->fl_list);
-	if (fl->fl_nspid) {
-		put_pid(fl->fl_nspid);
-		fl->fl_nspid = NULL;
-	}
 	locks_wake_up_blocks(fl);
 }
 

@@ -823,8 +818,6 @@ posix_test_lock(struct file *filp, struct file_lock *fl)
 	list_for_each_entry(cfl, &ctx->flc_posix, fl_list) {
 		if (posix_locks_conflict(fl, cfl)) {
 			locks_copy_conflock(fl, cfl);
-			if (cfl->fl_nspid)
-				fl->fl_pid = pid_vnr(cfl->fl_nspid);
 			goto out;
 		}
 	}

@@ -2048,6 +2041,31 @@ int vfs_test_lock(struct file *filp, struct file_lock *fl)
 }
 EXPORT_SYMBOL_GPL(vfs_test_lock);
 
+/**
+ * locks_translate_pid - translate a pid number into a namespace
+ * @nr: The pid number in the init_pid_ns
+ * @ns: The namespace into which the pid should be translated
+ *
+ * Used to tranlate a fl_pid into a namespace virtual pid number
+ */

fs/locks.c int vfs_test_lock(struct file *filp, struct file_lock *fl) · line 2060

Quoted 10 lines

fs/locks.c +10 -0

+static pid_t locks_translate_pid(int init_nr, struct pid_namespace *ns)
+{
+	pid_t vnr = 0;
+	struct task_struct *task;
+
+	rcu_read_lock();
+	task = find_task_by_pid_ns(init_nr, &init_pid_ns);
+	if (task)
+		get_task_struct(task);
+	rcu_read_unlock();

Is that safe? What prevents get_task_struct from doing a 0->1 transition there after the task usage count has already gone 1->0 and is on its way to being freed?

fs/locks.c int vfs_test_lock(struct file *filp, struct file_lock *fl) · line 2067

Quoted 7 lines

fs/locks.c +7 -0

+	if (!task)
+		goto out;
+	vnr = task_pid_nr_ns(task, ns);
+	put_task_struct(task);
+out:
+	return vnr;
+}

Quoted 56 lines

fs/locks.c +10 -16

 static int posix_lock_to_flock(struct flock *flock, struct file_lock *fl)
 {
 	flock->l_pid = IS_OFDLCK(fl) ? -1 : fl->fl_pid;

@@ -2584,22 +2602,16 @@ static void lock_get_status(struct seq_file *f, struct file_lock *fl,
 {
 	struct inode *inode = NULL;
 	unsigned int fl_pid;
+	struct pid_namespace *proc_pidns = file_inode(f->file)->i_sb->s_fs_info;
 
-	if (fl->fl_nspid) {
-		struct pid_namespace *proc_pidns = file_inode(f->file)->i_sb->s_fs_info;
-
-		/* Don't let fl_pid change based on who is reading the file */
-		fl_pid = pid_nr_ns(fl->fl_nspid, proc_pidns);
-
-		/*
-		 * If there isn't a fl_pid don't display who is waiting on
-		 * the lock if we are called from locks_show, or if we are
-		 * called from __show_fd_info - skip lock entirely
-		 */
-		if (fl_pid == 0)
-			return;
-	} else
-		fl_pid = fl->fl_pid;
+	fl_pid = locks_translate_pid(fl->fl_pid, proc_pidns);
+	/*
+	 * If there isn't a fl_pid don't display who is waiting on
+	 * the lock if we are called from locks_show, or if we are
+	 * called from __show_fd_info - skip lock entirely
+	 */
+	if (fl_pid == 0)
+		return;
 
 	if (fl->fl_file != NULL)
 		inode = locks_inode(fl->fl_file);

@@ -2674,7 +2686,7 @@ static int locks_show(struct seq_file *f, void *v)
 
 	fl = hlist_entry(v, struct file_lock, fl_link);
 
-	if (fl->fl_nspid && !pid_nr_ns(fl->fl_nspid, proc_pidns))
+	if (locks_translate_pid(fl->fl_pid, proc_pidns) == 0)
 		return 0;
 
 	lock_get_status(f, fl, iter->li_pos, "");

include/linux/fs.h +0 -1

index aa4affb38c39..b013fac515f7 100644
@@ -984,7 +984,6 @@ struct file_lock {
 	unsigned char fl_type;
 	unsigned int fl_pid;
 	int fl_link_cpu;		/* what cpu's list is this on? */
-	struct pid *fl_nspid;
 	wait_queue_head_t fl_wait;
 	struct file *fl_file;
 	loff_t fl_start;

Quoted 14 lines · Jeff Layton

Quoted 12 lines · Benjamin Coddington

Since commit c69899a17ca4 "NFSv4: Update of VFS byte range lock must be atomic with the stateid update", NFSv4 has been inserting locks in rpciod worker context. The result is that the file_lock's fl_nspid is the kworker's pid instead of the original userspace pid.

The fl_nspid is only used to represent the namespaced virtual pid number when displaying locks or returning from F_GETLK. There's no reason to set it for every inserted lock, since we can usually just look it up from fl_pid. So, instead of looking up and holding struct pid for every lock, let's just look up the virtual pid number from fl_pid when it is needed. That means we can remove fl_nspid entirely.

Quoted 2 lines

With this set, I think we ought to codify that the stored pid must be relative

...to the init_pid_ns. Let's make that clear in the comments for filesystem authors.

Quoted 61 lines

Quoted 61 lines

Signed-off-by Benjamin Coddington <[email protected]>

---
 fs/locks.c         | 58 
++++++++++++++++++++++++++++++++----------------------
 include/linux/fs.h |  1 -
 2 files changed, 35 insertions(+), 24 deletions(-)

fs/locks.c +0 -1

index d7daa6c8932f..104398ccc9b9 100644
@@ -733,7 +733,6 @@ static void locks_wake_up_blocks(struct 
 file_lock *blocker)
 static void
 locks_insert_lock_ctx(struct file_lock *fl, struct list_head 
 *before)
 {
-	fl->fl_nspid = get_pid(task_tgid(current));
 	list_add_tail(&fl->fl_list, before);

fs/locks.c +0 -6

 	locks_insert_global_locks(fl);
 }

@@ -743,10 +742,6 @@ locks_unlink_lock_ctx(struct file_lock *fl)
 {
 	locks_delete_global_locks(fl);
 	list_del_init(&fl->fl_list);
-	if (fl->fl_nspid) {
-		put_pid(fl->fl_nspid);
-		fl->fl_nspid = NULL;
-	}
 	locks_wake_up_blocks(fl);
 }
 

@@ -823,8 +818,6 @@ posix_test_lock(struct file *filp, struct 
 file_lock *fl)
 	list_for_each_entry(cfl, &ctx->flc_posix, fl_list) {
 		if (posix_locks_conflict(fl, cfl)) {
 			locks_copy_conflock(fl, cfl);
-			if (cfl->fl_nspid)
-				fl->fl_pid = pid_vnr(cfl->fl_nspid);
 			goto out;
 		}

fs/locks.c +13 -0

 	}

@@ -2048,6 +2041,31 @@ int vfs_test_lock(struct file *filp, struct 
 file_lock *fl)
 }
 EXPORT_SYMBOL_GPL(vfs_test_lock);
 
+/**
+ * locks_translate_pid - translate a pid number into a namespace
+ * @nr: The pid number in the init_pid_ns
+ * @ns: The namespace into which the pid should be translated
+ *
+ * Used to tranlate a fl_pid into a namespace virtual pid number
+ */
+static pid_t locks_translate_pid(int init_nr, struct pid_namespace 
 *ns)
+{
+	pid_t vnr = 0;
+	struct task_struct *task;
+
+	rcu_read_lock();

Quoted 8 lines

fs/locks.c int vfs_test_lock(struct file *filp, struct file_lock *fl) · line 2060

Quoted 4 lines

fs/locks.c +4 -0

+	task = find_task_by_pid_ns(init_nr, &init_pid_ns);
+	if (task)
+		get_task_struct(task);
+	rcu_read_unlock();

Is that safe? What prevents get_task_struct from doing a 0->1 transition there after the task usage count has already gone 1->0 and is on its way to being freed?

Quoted 18 lines · Jeff Layton

Quoted 16 lines · Jeff Layton

Quoted 5 lines · Benjamin Coddington

Since commit c69899a17ca4 "NFSv4: Update of VFS byte range lock must be atomic with the stateid update", NFSv4 has been inserting locks in rpciod worker context. The result is that the file_lock's fl_nspid is the kworker's pid instead of the original userspace pid.

Quoted 7 lines

The fl_nspid is only used to represent the namespaced virtual pid number when displaying locks or returning from F_GETLK. There's no reason to set it for every inserted lock, since we can usually just look it up from fl_pid. So, instead of looking up and holding struct pid for every lock, let's just look up the virtual pid number from fl_pid when it is needed. That means we can remove fl_nspid entirely.

With this set, I think we ought to codify that the stored pid must be relative

Quoted 2 lines

...to the init_pid_ns. Let's make that clear in the comments for filesystem authors.

OK, but I think you mean fl_pid should always be current->tgid or the pid as it is in init_pid_ns. We translate that pid into the virtual pid of the process doing F_GETLK or reading /proc/locks.

Quoted 22 lines · Jeff Layton

Quoted 21 lines · Jeff Layton

Quoted 19 lines · Benjamin Coddington

Since commit c69899a17ca4 "NFSv4: Update of VFS byte range lock must be
atomic with the stateid update", NFSv4 has been inserting locks in rpciod
worker context. The result is that the file_lock's fl_nspid is the kworker's pid instead of the original userspace pid.

The fl_nspid is only used to represent the namespaced virtual pid number
when displaying locks or returning from F_GETLK. There's no reason to set
it for every inserted lock, since we can usually just look it up from
fl_pid. So, instead of looking up and holding struct pid for every lock,
let's just look up the virtual pid number from fl_pid when it is needed.
That means we can remove fl_nspid entirely.

Quoted 5 lines

Quoted 2 lines

With this set, I think we ought to codify that the stored pid must be relative

...to the init_pid_ns. Let's make that clear in the comments for filesystem authors.

OK, but I think you mean fl_pid should always be current->tgid or the pid as
it is in init_pid_ns. We translate that pid into the virtual pid of the process doing F_GETLK or reading /proc/locks.

Quoted 63 lines

Quoted 63 lines

Quoted 63 lines

Signed-off-by Benjamin Coddington <[email protected]>

---
 fs/locks.c         | 58 
++++++++++++++++++++++++++++++++----------------------
 include/linux/fs.h |  1 -
 2 files changed, 35 insertions(+), 24 deletions(-)

fs/locks.c +0 -1

index d7daa6c8932f..104398ccc9b9 100644
@@ -733,7 +733,6 @@ static void locks_wake_up_blocks(struct 
 file_lock *blocker)
 static void
 locks_insert_lock_ctx(struct file_lock *fl, struct list_head 
 *before)
 {
-	fl->fl_nspid = get_pid(task_tgid(current));
 	list_add_tail(&fl->fl_list, before);

fs/locks.c +0 -6

 	locks_insert_global_locks(fl);
 }

@@ -743,10 +742,6 @@ locks_unlink_lock_ctx(struct file_lock *fl)
 {
 	locks_delete_global_locks(fl);
 	list_del_init(&fl->fl_list);
-	if (fl->fl_nspid) {
-		put_pid(fl->fl_nspid);
-		fl->fl_nspid = NULL;
-	}
 	locks_wake_up_blocks(fl);
 }
 

@@ -823,8 +818,6 @@ posix_test_lock(struct file *filp, struct 
 file_lock *fl)
 	list_for_each_entry(cfl, &ctx->flc_posix, fl_list) {
 		if (posix_locks_conflict(fl, cfl)) {
 			locks_copy_conflock(fl, cfl);
-			if (cfl->fl_nspid)
-				fl->fl_pid = pid_vnr(cfl->fl_nspid);
 			goto out;
 		}

fs/locks.c +15 -0

 	}

@@ -2048,6 +2041,31 @@ int vfs_test_lock(struct file *filp, struct 
 file_lock *fl)
 }
 EXPORT_SYMBOL_GPL(vfs_test_lock);
 
+/**
+ * locks_translate_pid - translate a pid number into a namespace
+ * @nr: The pid number in the init_pid_ns
+ * @ns: The namespace into which the pid should be translated
+ *
+ * Used to tranlate a fl_pid into a namespace virtual pid number
+ */
+static pid_t locks_translate_pid(int init_nr, struct pid_namespace 
 *ns)
+{
+	pid_t vnr = 0;
+	struct task_struct *task;
+
+	rcu_read_lock();
+	task = find_task_by_pid_ns(init_nr, &init_pid_ns);
+	if (task)

Quoted 8 lines

Quoted 8 lines

fs/locks.c int vfs_test_lock(struct file *filp, struct file_lock *fl) · line 2060

Quoted 2 lines

fs/locks.c +2 -0

+		get_task_struct(task);
+	rcu_read_unlock();

Is that safe? What prevents get_task_struct from doing a 0->1 transition
there after the task usage count has already gone 1->0 and is on its way
to being freed?

Uh, no -- seems not safe. I copied that directly from fs/proc/base.c, and
seems a problem there too.

Changing this to the below avoids the race with the struct task being released:

rcu_read_lock();
struct pid = find_pid_ns(init_nr, &init_pid_ns)
vnr = pid_vnr(pid);
rcu_read_unlock();