Subject: Re: kern/20914: kernel panic in sysctl_procargs()
To: Andrew Brown <email@example.com>
From: David Laight <firstname.lastname@example.org>
Date: 04/08/2003 15:58:20
Ok, so the break is in this 'memcpy' - which the compiler has inlined
to a single 'mov' instruction (at sysctl_procargs+0x1fd):
> case KERN_PROC_ARGV:
> /* XXX compat32 stuff here */
> memcpy(&tmp, (char *)&pss + p->p_psargv, sizeof(tmp));
> c030f590 <sysctl_procargs+0x1f4> 8b 7d bc mov 0xffffffbc(%ebp),%edi
> c030f593 <sysctl_procargs+0x1f7> 8b 87 7c 01 00 00 mov 0x17c(%edi),%eax
> c030f599 <sysctl_procargs+0x1fd> 8b 44 28 f0 mov 0xfffffff0(%eax,%ebp,1),%eax
Now we don't have the registers of the panic (anyone fancy fixing ddb?)
but the above should have extreme difficulty in exploding.
p->p_psargv is a constant - I think it should be 0 for all processes
and all the time. The only time it will be wrong (for a pointer that
has been a valid proc pointer) is if the process has exited and the
memory page released from the pool back for general use.
I don't see any need for p->p_psargv and friends - but I can't quite
see how the value read can be invalid - even though it must be!
OTOH this code is completly borked should the process actually exit!
David Laight: email@example.com