->pid in dnotify

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm not entirely sure about this change. But it seems to be necessary.
The dnotify code stores the PID in the file structure. The entire
process shares the file and any signal (is it used for that?) should be sent to the process (thread group), not the individual thread. Also keep in mind that threads can go away while the process (and therefore file descriptor) remain. And the ID of the thread can be reused.

Somebody who knows this code should take a good look.

- --
- --------------. ,-. 444 Castro Street
Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA
Red Hat --' drepper at redhat.com ---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/Tk4T2ijCOnn/RHQRAh5cAJkBTNx7g9pj+naBm5fyftI9LatRTACfaPkg t/ZzWXPAjlaqRJc+wIRP8AU=
=x8G3
-----END PGP SIGNATURE-----

@@ -94,7 +94,7 @@
 		prev = &odn->dn_next;
 	}
 
-	error = f_setown(filp, current->pid, 1);
+	error = f_setown(filp, current->tgid, 1);
 	if (error)
 		goto out_free;
 

The problem of owner churn goes beyond threads - fds can be passed to other process and outlive the original thread or process which created them. Changing ->pid to ->tgid doesn't fix this.

Using ->tgid in dnotify is at least consistent with fcntl_setlease() in locks.c, and the call to f_setown() in futex.c.

Unfortunately I can think of a few situations where you would want the signal delivered to one thread, but none where you'd want it delivered to a whole process (same for dnotify and setlease).

Userspace can change the pid straight after to ->pid using fcntl(fd,F_SETOWN,...), but that leaves a time window where a thread creates a dnotify or lease, and the signal will be delivered process-wide until the thread can direct it to itself.

-- Jamie