Svante Signell, le Tue 20 Jan 2015 11:19:21 +0100, a écrit : > On Tue, 2015-01-20 at 01:37 +0100, Samuel Thibault wrote: > > Hello, > > > > Thanks for reviving this, it'll definitely be useful! > > > > Svante Signell, le Thu 08 Jan 2015 12:28:05 +0100, a écrit : > > > 1) l_pid of struct flock is not set. According to the manpage (and > > > posix) the PID of the process blocking the lock should be reported. Can > > > maybe be solved by a shared memory solution in glibc or as indicated in > > > task 1022. > > > > We can not trust a shared memory solution, we need an io_reidentify > > round through the proc server. > > Can you give more information about how to implement this?
AIUI, it is the same principle as io_reauthenticate, see for instance in reauth_dtable for the d->port.port: In the application process glibc creates a rendez-vous port, sends it to the file server through io_reauthenticate, and to the auth server through auth_user_authenticate. The file server passes it to the auth server through auth_server_authenticate. The auth server notices the two auth_user_authenticate and auth_server_authenticate requests, notices that the rendez-vous port is the same, and then returns to the file server what it knows about the application process (uid, gid, etc.) Here it would be almost the same: In the application process glibc creates a rendez-vous port, sends it to the file server through io_reidentify, and to the proc server through proc_user_identify. The file server passes it to the proc server through proc_server_identify. The proc server notices the two proc_user_identify and proc_server_identify requests, notices that the rendez-vous port is the same, and then returns to the file server what it knows about the application process (pid). Samuel
