On 10/22, Tejun Heo wrote:

On Mon, Oct 22, 2012 at 08:04:45PM +0200, Oleg Nesterov wrote:

quoted

quoted

quoted

I am starting to think again about a big-rw-lock around copy_process.
Recently I tried to add one around dup_mmap for uprobes, but perhaps
cgroups can use it too...

If some other subsystems need it, maybe just make threadgroup locking
coarser?

What do you mean?

I probabl have misunderstood you

Probably me ;)

but If you're gonna add big-rw-lock
around copy-process which is always gonna be grabbed, I was suggesting
maybe we could simply repurpose the existing threadgroup locking.

Yes, yes. But in this case (I mean, for uprobes) "threadgroup" in the name
is misleading. It should be called unconditially without any argument.

Please see

	[PATCH 1/2] brw_mutex: big read-write mutex
	http://marc.info/?l=linux-kernel&m=135032816223715

	[PATCH 2/2] uprobes: Use brw_mutex to fix register/unregister vs dup_mmap() race
	http://marc.info/?l=linux-kernel&m=135032817823720

for details, but in short 2/2 needs this giant lock to block dup_mmap()
system-wide, while cgroup (currently) only needs threadgroup lock if
CLONE_THREAD (ignoring do_exit) and per-task.

So please forget, I no longer think it makes sense to use the same
thing for uprobes and cgroups.

Oleg.