On Tue, Oct 16, 2012 at 03:28:40PM -0700, Tejun Heo wrote:
[...]
>
> diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
> index f8a030c..4cd1d0f 100644
> --- a/include/linux/cgroup.h
> +++ b/include/linux/cgroup.h
> @@ -34,7 +34,6 @@ extern int cgroup_lock_is_held(void);
> extern bool c
On 10/24, Tejun Heo wrote:
>
> Hello,
>
> On Tue, Oct 23, 2012 at 05:51:28PM +0200, Oleg Nesterov wrote:
> > 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/
Hello,
On Tue, Oct 23, 2012 at 05:51:28PM +0200, Oleg Nesterov wrote:
> 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
>
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
Hey,
On Mon, Oct 22, 2012 at 08:04:45PM +0200, Oleg Nesterov wrote:
> > * Clear ->cgroup to %NULL during copy_process().
>
> I completely agree. new_child->cgroups copied from parent looks simply
> strange until post_fork. If nothing else, the new task is still under
> construction by the time cg
Hi Tejun,
On 10/21, Tejun Heo wrote:
>
> On Sun, Oct 21, 2012 at 09:11:41PM +0200, Oleg Nesterov wrote:
>
> > And it seems that fork() can race with cgroup iterator. post_fork
> > will notice use_task_css_set_links, but until then the child belongs
> > to the parent's css and it is not "visible" t
Hello, Oleg.
On Sun, Oct 21, 2012 at 09:11:41PM +0200, Oleg Nesterov wrote:
> A couple of off-topic questions. With or without this patch I do not
> understand cgroup_fork,
>
> /*
>* We don't need to task_lock() current because current->cgroups
>* can't be changed concurrent
On 10/16, Tejun Heo wrote:
>
> cgroup_subsys->fork() is invoked way before the new task is added to
> the css_set.
Plus, it called before this task (and even its task_struct) was fully
initialized.
All I can say is: personally I like this patch, it also simplifies
copy_process().
But I am in no
δΊ 2012/10/17 16:28, Li Zefan ει:
> On 2012/10/17 6:28, Tejun Heo wrote:
>> cgroup core has a bug which violates a basic rule about event
>> notifications - when a new entity needs to be added, you add that to
>> the notification list first and then make the new entity conform to
>> the current stat
On 2012/10/17 6:28, Tejun Heo wrote:
> cgroup core has a bug which violates a basic rule about event
> notifications - when a new entity needs to be added, you add that to
> the notification list first and then make the new entity conform to
> the current state. If done in the reverse order, an ev
cgroup core has a bug which violates a basic rule about event
notifications - when a new entity needs to be added, you add that to
the notification list first and then make the new entity conform to
the current state. If done in the reverse order, an event happening
inbetween will be lost.
cgroup
11 matches
Mail list logo
