On 23 Jun, 2010, at 2:32 AM, Bogdan Harjoc wrote: On Tue, Jun 22, 2010 at 10:44 PM, Terry Lambert < email@hidden> wrote: The tcp_input() doesn't happen in the context of a process, it happens in
the context of a kernel thread (the moral equivalent of netisr() on BSD
systems). The data gets unloaded onto a socket at the top end, but the
binding between a socket and a process is via a file descriptor, and any
given file descriptor could be referenced by multiple processes [...]
Agreed here, there's no trivial way of mapping socket_t to pid. Since I'm only dealing with TCP sockets, I can get the pid in the 'attach' filter callback. The two possible cases are "connect()ed socket" which the process creates, and "accept()ed socket" for which I assume the pid is the same as its listening socket, which the process also creates.
Keep in mind that a fork may occur, so that the accepting/connecting process may not be the process that uses the socket. For example, the "server" process may accept the call, fork, close stdin (etc.), dup the newly accepted socket to stdin, and then exec the ultimate program. The latter can then proceed to use "stdin" w/o caring that it is connected to a remote actor.
HTH
Justin
-- Justin C. Walker, Curmudgeon at Large Director Institute for the Enhancement of the Director's Income ----------- Nobody knows the trouble I've been -----------
|