bridej@prism.CS.ORST.EDU (Jim Bride) (03/07/91)
Hi. I am working on a program which requires me to be able to access the u (user) structure of a process OTHER than the process which is currently running. After reading over several thousand lines of source code I can't find out how to get a pointer to the other process' user structure. I think it involves translating the pointer inside the proc structure (p->p_addr) that points to the PTEs for the user structure into an address (which I can then cast to a (struct user *)). My program is running as a system call and I have been able to access the proc structure for the process I need to modify (via a call to pfind()), but I need to change a few things in the user structure of the process as well. Does anyone know of a way (preferably in C, but I would be willing to resort to assembler if I have to) that I can translate the p_addr pointer to a usable address that I can use to access the u structure or another method that I can the the address of the u structure of this other process? Any help you could offer would be greatly appreciated. BTW, I am using a HP 9000 series 300 CPU running 4.3BSD Utah. Thanks! Jim ------------------------------------------------------------------------- Jim Bride - Networking | Internet: bridej@CS.ORST.EDU Computer Science Dept. | UUCP: hplabs!hp-pcd!orstcs!bridej Oregon State University| Phone: 737-6178
torek@elf.ee.lbl.gov (Chris Torek) (03/07/91)
In article <1991Mar06.203225.20019@lynx.CS.ORST.EDU> bridej@prism.CS.ORST.EDU (Jim Bride) writes: >Hi. I am working on a program which requires me to be able to access the >u (user) structure of a process OTHER than the process which is currently >running. >BTW, I am using a HP 9000 series 300 CPU running 4.3BSD Utah. (this is an important constraint.) >I think it involves translating the pointer inside the proc structure >(p->p_addr) that points to the PTEs for the user structure into an >address (which I can then cast to a (struct user *)). This is correct as far as it goes. p->p_addr points to the PTEs of pages mapping the u. area; there may be more than one such PTE (and in fact there are 3 in the Utah HP BSD kernel). But this is not the whole story. Half of the raison d'etre of the `u. area' is that it can be sloughed off when the process is not running. If this has been done, p->p_flag&SLOAD will be 0 and the u. area will reside only in swap space. To alter it you would have to read it in first. >My program is running as a system call ... This makes touching the u. area extra difficult. (It is easier to do in user code, except that it is unreliable since the process can move while you are doing your thing.) If the process is loaded, you can simply map in the corresponding pages (there are some maps dedicated to mapping u. areas, Xswapmap and Xswap2map with virtual addresses xswaputl and xswap2utl, and associated locks xswaplock&1 and xswaplock&2, which you could steal for this purpose; see vm_swap.c$swapout()). If not, you must bring it in. The easiest way is to call swapin(). Swapin can fail, returning 0, so you must loop; it may help to tickle the pager (see vm_sched.c$sched()). Once swapin succeeds, you can proceed as usual. To make xswaputl or xswap2utl map the u. area of the other process, you can simply call uaccess(); see swapout(). If you use the same algorithm, utl->u_xxx will then refer to the u_xxx field of the u. area of the other process. -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab EE div (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov
rbj@uunet.UU.NET (Root Boy Jim) (03/08/91)
In article <10712@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes: >In article <1991Mar06.203225.20019@lynx.CS.ORST.EDU> bridej@prism.CS.ORST.EDU >(Jim Bride) writes: >>Hi. I am working on a program which requires me to be able to access the >>u (user) structure of a process OTHER than the process which is currently >>running. Allow me to rephrase your (Jim's) question: How do you find the u area? Answer: I find it repulsive. >Half of the raison d'etre of the `u. area' is that it can be sloughed off >when the process is not running. If this has been done, p->p_flag&SLOAD >will be 0 and the u. area will reside only in swap space. To alter it >you would have to read it in first. What is the other half? To save space? I thought it was going to be merged with the proc table in 4.4. Eh? -- [rbj@uunet 1] stty sane unknown mode: sane