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
boyd@necisa.ho.necisa.oz.au (Boyd Roberts) (03/08/91)
In article <1991Mar06.203225.20019@lynx.CS.ORST.EDU> bridej@prism.CS.ORST.EDU (Jim Bride) writes: > > [dubious thread about finding some other processes u-area deleted ] > You should first ask yourself whether this is a good idea. If you really want to, some UNIX kernels have a uaccess() call that maps in another processes u-area at some known kernel virtual address. Other implementations may return you a pointer to it. Let's be careful out there :-) Boyd Roberts boyd@necisa.ho.necisa.oz.au ``When the going gets wierd, the weird turn pro...''
jfh@rpp386.cactus.org (John F Haugh II) (03/08/91)
In article <2033@necisa.ho.necisa.oz.au> boyd@necisa.ho.necisa.oz.au (Boyd Roberts) writes: >You should first ask yourself whether this is a good idea. > >If you really want to, some UNIX kernels have a uaccess() call >that maps in another processes u-area at some known kernel virtual >address. Other implementations may return you a pointer to it. There are plenty of good reasons for wanting to get your hands on some other U area. The "ofiles" command posted to the net some time back dopes around the process table, then goes out and grabs the U areas of all the active processes. >Let's be careful out there :-) Hmmmm. Anyone reading this group who doesn't have a good kernel debugger should give up now. If you can't snoop about, you can't figger out where this stuff is ... -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "I've never written a device driver, but I have written a device driver manual" -- Robert Hartman, IDE Corp.
torek@elf.ee.lbl.gov (Chris Torek) (03/09/91)
>In article <10712@dog.ee.lbl.gov> I wrote: >>Half of the raison d'etre of the `u. area' is that it can be sloughed off >>when the process is not running. ... In article <124885@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes: >What is the other half? To save space? Hm, well, make that `9/10ths' :-) . I am not sure exactly what I was thinking, but half of it could now be considered `hysterical raisins'. >I thought it was going to be merged with the proc table in 4.4. Eh? 4.4? What is 4.4? :-) `wc -l' output: 155 /arch/4.2bsd/usr/src/sys/h/user.h 147 /arch/4.3bsd/usr/src/sys/h/user.h 147 /arch/4.3tahoe/usr/src/sys/h/user.h 128 [previous alpha release (`4.3reno') user.h] 53 [tonight's user.h] I would say there is a definite trend here.... Note that the pcb and kernel stack are slated to stay in a `sloughable' area; whether it is to be called the `u. area', and whether it will live at a fixed virtual address, is open to question. -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab EE div (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov