Question regarding vnodes and memory mapped files
Question regarding vnodes and memory mapped files
- Subject: Question regarding vnodes and memory mapped files
- From: Narayan Subramanian <email@hidden>
- Date: Wed, 21 Jan 2009 14:51:13 +0530
I had a question regarding the 'vnode' and memory mapped files.
Observations:
After examining the source for lsof, I found out that lsof gets all executables mapped into process memory (the ones it labels as 'txt') by looking at those regions that are backed by an external pager. Assuming (or knowing) that this is a vnode pager, lsof then obtains the pager / memory object, and then the vnode corresponding to that object, and then reads off the name of file that the vnode represents (from the v_name field). (By this method of course you not only get executable files but even normal text files (e.g CFUnicode etc.) that may be mapped into the processs address space). I am referring here to the raw method that lsof uses (and not the libproc method).
Question(s):
My question here is: Do we not call close() on the executable files descriptor after we mmap() them into the process address space (inside dyld)? I am assuming that the vnode corresponding to the file descriptor should get freed after the file descriptor gets closed (right?). (I mean isn't that the only way we can move around an (on disk) executable file that being run by another process?). If that is true, how is it that we are still able to trace the vnode that represents the file that was mmap()ed, after its descriptor was close()d? Who caches this vnode, how and where? If this vnode is still 'alive' how is one able to physically move the executable file (mapped by the process) on disk?
If you would like to point me to some code in the kernel for some explanation, that is welcome. I have the sources for 10.4.11 with me.
Really appreciate your response / clarification.
Thank You,
Narayan
_______________________________________________
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