site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com 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 ? 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 ? -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... On Jun 18, 2010, at 3:00 AM, Bogdan Harjoc wrote: On Thu, Jun 17, 2010 at 9:24 PM, Terry Lambert <tlambert@apple.com> wrote: 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. 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. This email sent to site_archiver@lists.apple.com