Re: + proc-dont-lock-task_structs-indefinitely-cpuset-fix-2.patchadded to -mm tree

[Eric W. Biederman]

Paul Jackson <pj@xxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/