Re: [PATCH hurd 0/6] Add file record locking support

[Samuel Thibault]

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