From: Oleg Nesterov <oleg@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: rjw@sisk.pl, linux-kernel@vger.kernel.org, lizefan@huawei.com,
containers@lists.linux-foundation.org, cgroups@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH 1/7] cgroup: cgroup_subsys->fork() should be called after the task is added to css_set
Date: Tue, 23 Oct 2012 17:51:28 +0200 [thread overview]
Message-ID: <20121023155128.GB16201@redhat.com> (raw)
In-Reply-To: <20121022211631.GE5951@atj.dyndns.org>
On 10/22, Tejun Heo wrote:
>
> On Mon, Oct 22, 2012 at 08:04:45PM +0200, Oleg Nesterov wrote:
>
> > > > 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.
next prev parent reply other threads:[~2012-10-23 15:50 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-16 22:28 [PATCHSET cgroup/for-3.8] cgroup_freezer: allow migration regardless of freezer state and update locking Tejun Heo
2012-10-16 22:28 ` [PATCH 1/7] cgroup: cgroup_subsys->fork() should be called after the task is added to css_set Tejun Heo
2012-10-17 8:28 ` Li Zefan
2012-10-18 1:25 ` Li Zefan
2012-10-21 19:11 ` Oleg Nesterov
2012-10-21 19:22 ` Tejun Heo
2012-10-22 18:04 ` Oleg Nesterov
2012-10-22 21:16 ` Tejun Heo
2012-10-23 15:51 ` Oleg Nesterov [this message]
2012-10-24 19:04 ` Tejun Heo
2012-10-25 17:42 ` Oleg Nesterov
2012-12-20 5:25 ` Herton Ronaldo Krzesinski
2012-12-28 21:22 ` [PATCH] cgroup: remove unused dummy cgroup_fork_callbacks() Tejun Heo
2012-10-16 22:28 ` [PATCH 2/7] freezer: add missing mb's to freezer_count() and freezer_should_skip() Tejun Heo
2012-10-22 17:44 ` Oleg Nesterov
2012-10-22 21:13 ` Tejun Heo
2012-10-23 15:39 ` Oleg Nesterov
2012-10-24 18:57 ` Tejun Heo
2012-10-25 16:39 ` [PATCH 0/1] (Was: freezer: add missing mb's to freezer_count() and freezer_should_skip()) Oleg Nesterov
2012-10-25 16:39 ` [PATCH 1/1] freezer: change ptrace_stop/do_signal_stop to use freezable_schedule() Oleg Nesterov
2012-10-25 17:18 ` Tejun Heo
2012-10-25 17:34 ` Oleg Nesterov
2012-10-25 17:36 ` Tejun Heo
2012-10-26 17:45 ` [PATCH v2 0/1] " Oleg Nesterov
2012-10-26 17:46 ` [PATCH v2 1/1] " Oleg Nesterov
2012-10-26 17:52 ` Tejun Heo
2012-10-26 18:01 ` Oleg Nesterov
2012-10-26 21:14 ` Rafael J. Wysocki
2012-10-26 21:29 ` Rafael J. Wysocki
2012-10-26 21:29 ` Tejun Heo
2012-10-28 0:16 ` Rafael J. Wysocki
2012-10-27 22:22 ` Ben Hutchings
2012-10-28 13:45 ` Oleg Nesterov
2012-10-16 22:28 ` [PATCH 3/7] cgroup_freezer: make it official that writes to freezer.state don't fail Tejun Heo
2012-10-16 22:28 ` [PATCH 4/7] cgroup_freezer: don't stall transition to FROZEN for PF_NOFREEZE or PF_FREEZER_SKIP tasks Tejun Heo
2012-10-22 18:34 ` Oleg Nesterov
2012-10-22 21:18 ` Tejun Heo
2012-10-23 15:55 ` Oleg Nesterov
2012-10-24 19:06 ` Tejun Heo
2012-10-25 17:12 ` [PATCH 0/1] (Was: cgroup_freezer: don't stall transition to FROZEN for PF_NOFREEZE or PF_FREEZER_SKIP tasks) Oleg Nesterov
2012-10-25 17:12 ` [PATCH 1/1] freezer: exec should clear PF_NOFREEZE along with PF_KTHREAD Oleg Nesterov
2012-10-25 17:20 ` Tejun Heo
2012-10-25 17:37 ` Oleg Nesterov
2012-10-25 17:37 ` Tejun Heo
2012-10-25 20:13 ` Rafael J. Wysocki
2012-10-16 22:28 ` [PATCH 5/7] cgroup_freezer: allow moving tasks in and out of a frozen cgroup Tejun Heo
2012-10-22 19:25 ` Oleg Nesterov
2012-10-22 21:25 ` Tejun Heo
2012-10-23 16:14 ` Oleg Nesterov
2012-10-16 22:28 ` [PATCH 6/7] cgroup_freezer: prepare update_if_frozen() for locking change Tejun Heo
2012-10-16 22:28 ` [PATCH 7/7] cgroup_freezer: don't use cgroup_lock_live_group() Tejun Heo
2012-10-17 19:16 ` [PATCHSET cgroup/for-3.8] cgroup_freezer: allow migration regardless of freezer state and update locking Matt Helsley
2012-10-18 21:14 ` Tejun Heo
2012-10-18 22:21 ` Matt Helsley
2012-10-18 22:35 ` Tejun Heo
2012-10-18 23:47 ` Matt Helsley
2012-10-19 0:01 ` Tejun Heo
2012-10-19 1:29 ` Matt Helsley
2012-10-19 20:02 ` Tejun Heo
2012-10-19 16:54 ` Rafael J. Wysocki
2012-10-19 20:04 ` Tejun Heo
2012-10-21 19:18 ` Oleg Nesterov
2012-10-21 19:24 ` Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121023155128.GB16201@redhat.com \
--to=oleg@redhat.com \
--cc=cgroups@vger.kernel.org \
--cc=containers@lists.linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan@huawei.com \
--cc=rjw@sisk.pl \
--cc=stable@vger.kernel.org \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).