![]() | |||||||||||||
Messages in this thread |
Paul Jackson <pj@sgi.com> writes: > Eric wrote: >> I can kill a kernel this way as well. Thanks this looks like >> a good reproducer I will see if I can figure out why. > > I suspect two problems, one with your patches that the fuser provokes, > and a separate bug earlier in *-mm that the DEBUG options noted below > provoke. > > Details: > > In addition to the problem that shows up with the three patches >> proc-dont-lock-task_structs-indefinitely.patch >> proc-dont-lock-task_structs-indefinitely-git-nfs-fix.patch >> proc-dont-lock-task_structs-indefinitely-cpuset-fix.patch > > when running the fuser command: >> /bin/fuser -n tcp 5553 > > I am seeing as a separate bug the crash during boot that I reported > last, when I turned on some DEBUG options. That crash occurs even with > none of your proc patches. Ok. I think I have found the big bug in my task_ref patches. I had missed that __unhash_process got moved outside of the tasklist_lock. Which messed up my serialization with detach_pid. My gut feel says modifying doubly linked lists without a lock isn't even safe. Which is probably why I never considered the possibility. Now to think through what this means in terms of locking. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2006-03-01 06:15 [W:6.219 / U:0.010 seconds] ©2003-2008 Jasper Spaans | |||||||||||||