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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m1irkjodm2.fsf@ebiederm.dsl.xmission.com>
Date:	Wed, 23 Aug 2006 06:12:05 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Avi Kivity <avi@...o.co.il>
Cc:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	linux-kernel@...r.kernel.org, akpm@...l.org, pj@....com,
	saito.tadashi@...t.fujitsu.com, ak@...e.de
Subject: Re: [RFC][PATCH] ps command race fix take2 [1/4] list token

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

> ebiederm@...ssion.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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/