I'm running a customized 2.6.10 and seeing some interesting behaviour.
Based on some additional debugging that we added, the "p->signal" member
is being set to NULL between the time we call spin_lock() and the time
we return from it.
Anyone have any ideas what might be going on? It seems to go away if we
boot with only 1 cpu. I assume that some other cpu already holds that
lock and does something while holding it that causes the "p->signal"
member to become NULL.
void release_task(struct task_struct * p)
{
int zap_leader;
task_t *leader;
struct dentry *proc_dentry;
repeat:
atomic_dec(&p->user->processes);
spin_lock(&p->proc_lock);
proc_dentry = proc_pid_unhash(p);
Thanks,
Chris
On Tue, 2006-03-21 at 08:52 -0600, Christopher Friesen wrote:
> I'm running a customized 2.6.10 and seeing some interesting behaviour.
> Based on some additional debugging that we added, the "p->signal" member
> is being set to NULL between the time we call spin_lock() and the time
> we return from it.
hmm odd... is your kernel patch available somewhere? Maybe there's a bug
in that (since this is not normal behavior at all)
(but then again 2.6.10 is *old* :)