Changing the pid of a process generates an OOPS in other places

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I'm messing up with kernel 2.6.11.7. I'm trying to change the pid of a process as part of a system call. More exactly, I try to "steal" the pid of a dead process. Whenever I do this other processes generate errors like:

"Unable to handle kernel paging request at virtual address xxx" in copy_process (kernel/fork.c) next time the do_fork function it's called by any other process,
or I get similar memory related errors. I am changing other parts of the kernel as part of my work, so I could very well be breaking something else.
However, I noticed that if I don't mess up with the pid these errors do not occur. I appended to this message the begining of one of the OOPSes that I get.

My questions are the following.
1. Are the pids of processes cached anywhere?
2. Even if I don't try to reuse an old pid but do current->pid = alloc_pidmap() I get the same behavior. Can somebody explain to me the functionality of pidmaps? alloc_pidmap/attach_pid/detach_pid?

Any suggestions?

Just as a sidenote for people that will be looking at the OOPs, I am using this inside vmware but this should not be affecting anything since I have no vmware specific patch applied to the kernel.

Cheers,

Cristian.

^MUnable to handle kernel paging request at virtual address cb8b0b44
^M printing eip:
^Mc011581a
^M*pde = 0002d067
^M*pte = 0b8b0000
^MOops: 0002 [#1]
^MPREEMPT DEBUG_PAGEALLOC
^MModules linked in: md5 ipv6 autofs4 sunrpc iptable_filter ip_tables pcnet32 mii floppy sd_mod
^MCPU:    0
^MEIP:    0060:[<c011581a>]    Not tainted VLI
^MEFLAGS: 00010086   (2.6.11.7-spec)
^MEIP is at copy_process+0xf2a/0x11a0
^Meax: cb7aeb44   ebx: 00000063   ecx: 00000000   edx: cb8b0b44
^Mesi: 00000001   edi: cb7aeaf0   ebp: ce851f5c   esp: ce851f10
^Mds: 007b   es: 007b   ss: 0068
^MProcess vmware-guestd (pid: 1209, threadinfo=ce850000 task=cf256af0)
^MStack: c0325b0c 000004b9 00000063 cb7aeaf0 cb7aeb98 ce851f73 00000001 00000001
^M       00000001 ce851fc4 bffff804 00000011 cb596f70 000009cf 00000001 00000000
^M       ce851fc4 00000011 000009d0 ce851fa8 c0115b73 00000000 00000000 00000000
^MCall Trace:
^M [<c0102c4a>] show_stack+0x7a/0x90
^M [<c0102dc9>] show_registers+0x149/0x1c0
^M [<c0102fd9>] die+0xe9/0x180
^M [<c0110253>] do_page_fault+0x453/0x672
^M [<c01028d3>] error_code+0x2b/0x30
^M [<c0115b73>] do_fork+0x63/0x193
^M [<c01010a9>] sys_fork+0x29/0x30
^M [<c01026bf>] syscall_call+0x7/0xb
^MCode: 04 24 0c 5b 32 c0 89 44 24 04 e8 d2 13 00 00 e9 92 f7 ff ff c7 47 54 74
4b 36 c0 8b 15 78 4b 36 c0 89 f8 83 c0 54 a3 78 4b 36 c0 <89> 02 89 50 04 e9 86
f7 ff ff 8b 83 88 01 00 00 e8 21 c5 ff ff
^M <6>note: vmware-guestd[1209] exited with preempt_count 1


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux