Paul Jackson <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
