Re: Process exit notifcation in a kext
Re: Process exit notifcation in a kext
- Subject: Re: Process exit notifcation in a kext
- From: Terry Lambert <email@hidden>
- Date: Tue, 22 Jun 2010 12:44:42 -0700
On Jun 18, 2010, at 3:00 AM, Bogdan Harjoc wrote:
On Thu, Jun 17, 2010 at 9:24 PM, Terry Lambert <email@hidden>
wrote:
I'd like to ask is this approach is correct: call
proc_find(pid) which takes a reference to the proc_t, and then
proc_rele(pid) when the exit notification from kqueue comes. This
avoids the race, but will the process exit while I am holding a
reference to it ?
In addition, you have no guarantee that the locking order will
happen the
way you want it to, i.e. there is a race in acquiring the lock on the
process list between you doing the pfind() and the process ID being
reused
between the time you decide a given PID is interesting to you and
the time
that the process reference is obtained on a process with that PID,
such that
it may not be the process you found interesting by the time you
have the
reference. It's undefined, which is why it's bad to use PID as a
unique
identifier for security purposes.
True, because I would call pfind() in a callback coming from
tcp_input() (and not from a user process). I was hoping for a way to
tag a process (like one can tag mbuf's), is this somehow possible ?
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, either via parent/child descriptor inheritance or
explicit descriptor passing via UNIX domain socket. You could brute-
force the lookup to try and figure your way back to the process(es)
that have the descriptor open, which would be prohibitively expensive,
but it's racy for the same reasons as before, and whoever reads from
the thing first is the "real" process of the moment. And that's
indeterminate.
Are you going to be building your own kernel? If you're building your
own kernel, you could potentially add a tag field to the proc
structure and provide your own SPI for an accessor/mutator for the tag
field. That would be reasonable if this were a research project
rather than being intended as a commercial product. You still have to
figure out a way to get back to the process from the socket, though,
if you want to do the lookup in tcp_input(), so you're still stuck
there. You could add a linked list of processes to the socket, and
modify the accept/connect/bind/shutdown/close code to maintain the
list under the proper locking conditions, but unless it's the
difference between you getting your PhD and not getting it, it's
probably more trouble than it's worth.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden