2005/11/29, Steven Rostedt <[EMAIL PROTECTED]>: > > What you are showing, would probably show up by others if this were a > vanilla kernel issue. I don't have an 8 way machine, just 2 way, but the > vanilla kernel is being used on many 8 ways out there, so I think you are > right that this _is_ a vserver issue.
Yeah, I guess so. I also noticed that running an older build (w/o ACPI so it sees only 2 CPUs due to lack of HT - it's a dual Xeon HT machine so there are 4 logical CPUs) seems a bit more stable, but it happens there too. > > Unless, of course, that the vserver is producing an obscure race in the > vanilla kernel that normal operations would seldom have. Just like the > PREEMPT_RT patch has discovered many race conditions that were in the > vanilla kernel but were not often a problem. > I'm not using preemption. What made me just stare in wonder was when I added a check in do_task_stat at the very beginning to the effect of: if (!task) { printk(...); return -ENOENT; } /* dereference task as usual */ I *still* got the oops (and no message got logged). So either it is used before the entry point (there is an occurrence of sizeof(task->comm) but that should be statically determined by the compiler, right?) or it is set to NULL in some magical way between the check and usage (yep, it's still a race but the window should be smaller I think). The only place I can find a proc_inode.task field set to NULL is in proc_pid_make_inode(). However, it is set to the value of task parameter just a few instructions later. Am I right? Or can proc_pid_make_inode get passed a NULL pointer? I'm lost. Any assistance will be invaluable. Best regards, Grzegorz Nosek _______________________________________________ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver