Re: [RFC][PATCH] ps command race fix take2 [1/4] list token

[ebiederm@xmission.com (Eric W. Biederman)]

Avi Kivity <avi@argo.co.il> writes:

> ebiederm@xmission.com wrote:
>>
>> I almost removed the tasklist_lock from all read paths.  But as it
>> happens sending a signal to a process group is an atomic operation
>> with respect to fork so that path has to take the lock, or else
>> we get places where "kill -9 -pgrp" fails to kill every process in
>> the process group.  Which is even worse.
>>
>
> Can't that be fixed by adding a per-pgrp lock, and having both fork()/clone()
> and kill(-pgrp) take that lock?

Possibly.  The core issue though is that you still need to take a lock and
a big group can be as bad as just about anything else.  So all you do with
a per group lock is you change the odds of hitting the problem and make the
code a little more complicated.  For the small systems that most people have
I don't believe the tasklist_lock shows up at all.

If someone can find a data structure that I could use on two independent 
machines to create processes in the same process group and still allow atomic
kill behavior between those two machines I think we would have something that
could be made to scale very well.

Until the point where I see the truly better data structure or that people
who can actually see problems with the lock start to fix it.  I think
it is not to modify the data structure more than necessary, at runtime.

Modifying the global task list in the middle of readdir looks like it will
allow user space simply by running top with a fast update frequency to
cause problems for people on bigger machines.  Which is really the
wrong direction to go.

Eric