On Mon, Jan 26, 2015 at 06:46:12PM -0500, Sasha Levin wrote:
> This seems to cause the following lockdep warning:
Yeah, so this one in particular seems caused by:
fadfe7be6e50 ("perf: Add queued work to remove orphaned child events")
But I'm not sure why it wasn't already true for hrtimers,
On Mon, Jan 26, 2015 at 06:46:12PM -0500, Sasha Levin wrote:
> This seems to cause the following lockdep warning:
unlikely, the fork -> sched_move_task() was only used to establish that
rq->lock nests inside p->pi_lock, and there's a gazillion other ways to
establish that.
That said, its a right
On Mon, Jan 26, 2015 at 06:46:12PM -0500, Sasha Levin wrote:
This seems to cause the following lockdep warning:
unlikely, the fork - sched_move_task() was only used to establish that
rq-lock nests inside p-pi_lock, and there's a gazillion other ways to
establish that.
That said, its a right
On Mon, Jan 26, 2015 at 06:46:12PM -0500, Sasha Levin wrote:
This seems to cause the following lockdep warning:
Yeah, so this one in particular seems caused by:
fadfe7be6e50 (perf: Add queued work to remove orphaned child events)
But I'm not sure why it wasn't already true for hrtimers, we
On 10/27/2014 06:18 AM, Kirill Tkhai wrote:
> The race may happen when somebody is changing task_group of a forking task.
> Child's cgroup is the same as parent's after dup_task_struct() (there just
> memory copying). Also, cfs_rq and rt_rq are the same as parent's.
>
> But if parent changes its
On 10/27/2014 06:18 AM, Kirill Tkhai wrote:
The race may happen when somebody is changing task_group of a forking task.
Child's cgroup is the same as parent's after dup_task_struct() (there just
memory copying). Also, cfs_rq and rt_rq are the same as parent's.
But if parent changes its
On 10/29, Kirill Tkhai wrote:
>
> On 29.10.2014 01:52, Oleg Nesterov wrote:
>
> > And cgroup_task_migrate() can free ->cgroups via call_rcu(). Of course,
> > in practice raw_spin_lock_irq() should also act as rcu_read_lock(), but
> > we should not rely on implementation details.
>
> Do you mean
В Ср, 29/10/2014 в 10:16 +0100, Peter Zijlstra пишет:
> On Wed, Oct 29, 2014 at 06:20:48AM +0300, Kirill Tkhai wrote:
> > > And cgroup_task_migrate() can free ->cgroups via call_rcu(). Of course,
> > > in practice raw_spin_lock_irq() should also act as rcu_read_lock(), but
> > > we should not rely
On Wed, Oct 29, 2014 at 06:20:48AM +0300, Kirill Tkhai wrote:
> > And cgroup_task_migrate() can free ->cgroups via call_rcu(). Of course,
> > in practice raw_spin_lock_irq() should also act as rcu_read_lock(), but
> > we should not rely on implementation details.
>
> Do you mean
On Wed, Oct 29, 2014 at 06:20:48AM +0300, Kirill Tkhai wrote:
And cgroup_task_migrate() can free -cgroups via call_rcu(). Of course,
in practice raw_spin_lock_irq() should also act as rcu_read_lock(), but
we should not rely on implementation details.
Do you mean
В Ср, 29/10/2014 в 10:16 +0100, Peter Zijlstra пишет:
On Wed, Oct 29, 2014 at 06:20:48AM +0300, Kirill Tkhai wrote:
And cgroup_task_migrate() can free -cgroups via call_rcu(). Of course,
in practice raw_spin_lock_irq() should also act as rcu_read_lock(), but
we should not rely on
On 10/29, Kirill Tkhai wrote:
On 29.10.2014 01:52, Oleg Nesterov wrote:
And cgroup_task_migrate() can free -cgroups via call_rcu(). Of course,
in practice raw_spin_lock_irq() should also act as rcu_read_lock(), but
we should not rely on implementation details.
Do you mean
On 29.10.2014 01:52, Oleg Nesterov wrote:
> On 10/28, Kirill Tkhai wrote:
>>
>> Shouldn't we do that in separate patch? How about this?
>
> Up to Peter, but I think a separate patch is fine.
>
>> [PATCH]sched: Remove lockdep check in sched_move_task()
>>
>> sched_move_task() is the only
On 10/28, Kirill Tkhai wrote:
>
> Shouldn't we do that in separate patch? How about this?
Up to Peter, but I think a separate patch is fine.
> [PATCH]sched: Remove lockdep check in sched_move_task()
>
> sched_move_task() is the only interface to change sched_task_group:
> cpu_cgrp_subsys methods
On 10/28, Kirill Tkhai wrote:
Shouldn't we do that in separate patch? How about this?
Up to Peter, but I think a separate patch is fine.
[PATCH]sched: Remove lockdep check in sched_move_task()
sched_move_task() is the only interface to change sched_task_group:
cpu_cgrp_subsys methods and
On 29.10.2014 01:52, Oleg Nesterov wrote:
On 10/28, Kirill Tkhai wrote:
Shouldn't we do that in separate patch? How about this?
Up to Peter, but I think a separate patch is fine.
[PATCH]sched: Remove lockdep check in sched_move_task()
sched_move_task() is the only interface to change
В Вт, 28/10/2014 в 00:04 +0100, Oleg Nesterov пишет:
> On 10/27, Kirill Tkhai wrote:
> >
> > +static void cpu_cgroup_fork(struct task_struct *task)
> > +{
> > + sched_move_task(task);
> > +}
> > +
> > static int cpu_cgroup_can_attach(struct cgroup_subsys_state *css,
> >
On 10/27, Kirill Tkhai wrote:
>
> +static void cpu_cgroup_fork(struct task_struct *task)
> +{
> + sched_move_task(task);
> +}
> +
> static int cpu_cgroup_can_attach(struct cgroup_subsys_state *css,
>struct cgroup_taskset *tset)
> {
> @@ -8205,6 +8210,7 @@
On Mon, Oct 27, 2014 at 02:18:25PM +0400, Kirill Tkhai wrote:
>
> The race may happen when somebody is changing task_group of a forking task.
> Child's cgroup is the same as parent's after dup_task_struct() (there just
> memory copying). Also, cfs_rq and rt_rq are the same as parent's.
>
> But
On Mon, Oct 27, 2014 at 02:18:25PM +0400, Kirill Tkhai wrote:
The race may happen when somebody is changing task_group of a forking task.
Child's cgroup is the same as parent's after dup_task_struct() (there just
memory copying). Also, cfs_rq and rt_rq are the same as parent's.
But if
On 10/27, Kirill Tkhai wrote:
+static void cpu_cgroup_fork(struct task_struct *task)
+{
+ sched_move_task(task);
+}
+
static int cpu_cgroup_can_attach(struct cgroup_subsys_state *css,
struct cgroup_taskset *tset)
{
@@ -8205,6 +8210,7 @@ struct
В Вт, 28/10/2014 в 00:04 +0100, Oleg Nesterov пишет:
On 10/27, Kirill Tkhai wrote:
+static void cpu_cgroup_fork(struct task_struct *task)
+{
+ sched_move_task(task);
+}
+
static int cpu_cgroup_can_attach(struct cgroup_subsys_state *css,
struct
22 matches
Mail list logo
