On 2012/11/1 3:44, Tejun Heo wrote:
> 2ef37d3fe4 ("memcg: Simplify mem_cgroup_force_empty_list error
> handling") removed the last user of __DEPRECATED_clear_css_refs. This
> patch removes __DEPRECATED_clear_css_refs and mechanisms to support
> it.
>
> * Conditionals dependent on __DEPRECATED_cle
(2012/11/01 5:24), Tejun Heo wrote:
On Wed, Oct 31, 2012 at 09:14:16PM +0100, Michal Hocko wrote:
On Wed 31-10-12 13:11:02, Tejun Heo wrote:
Hello,
On Wed, Oct 31, 2012 at 1:08 PM, Michal Hocko wrote:
local_irq_disable doesn't guarantee atomicity, because other CPUs will
Maybe it should sa
(2012/10/31 13:22), Tejun Heo wrote:
> 2ef37d3fe4 ("memcg: Simplify mem_cgroup_force_empty_list error
> handling") removed the last user of __DEPRECATED_clear_css_refs. This
> patch removes __DEPRECATED_clear_css_refs and mechanisms to support
> it.
>
> * Conditionals dependent on __DEPRECATED_cl
On Wed 31-10-12 13:14:07, Tejun Heo wrote:
> Hey, Michal.
>
> On Wed, Oct 31, 2012 at 1:12 PM, Michal Hocko wrote:
> > And sorry for being to annoying about this WARN_ON_ONCE but I really
> > don't see any reason for it. pre_destroy can still happen and now it is
> > even reduced to a reasonable
On Wed 31-10-12 13:24:00, Tejun Heo wrote:
[...]
> local_irq_save/restore() from cgroup_clear_css_refs() are replaced
> with local_irq_disable/enable() for simplicity. This is safe as
> cgroup_rmdir() is always called with IRQ enabled. Note that this IRQ
> switching is necessary to ensure that cs
On Wed, Oct 31, 2012 at 09:14:16PM +0100, Michal Hocko wrote:
> On Wed 31-10-12 13:11:02, Tejun Heo wrote:
> > Hello,
> >
> > On Wed, Oct 31, 2012 at 1:08 PM, Michal Hocko wrote:
> > > local_irq_disable doesn't guarantee atomicity, because other CPUs will
> >
> > Maybe it should say atomicity on
On Wed 31-10-12 13:11:02, Tejun Heo wrote:
> Hello,
>
> On Wed, Oct 31, 2012 at 1:08 PM, Michal Hocko wrote:
> > local_irq_disable doesn't guarantee atomicity, because other CPUs will
>
> Maybe it should say atomicity on the local CPU.
That would be more clear but being more verbose doesn't hur
Hey, Michal.
On Wed, Oct 31, 2012 at 1:12 PM, Michal Hocko wrote:
> And sorry for being to annoying about this WARN_ON_ONCE but I really
> don't see any reason for it. pre_destroy can still happen and now it is
> even reduced to a reasonable condition (somebody shown up). So I would
> put it out
On Wed 31-10-12 12:44:03, Tejun Heo wrote:
> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> index 7981850..8c605e2 100644
> --- a/kernel/cgroup.c
> +++ b/kernel/cgroup.c
> @@ -865,11 +865,8 @@ static int cgroup_call_pre_destroy(struct cgroup *cgrp)
> continue;
>
>
Hello,
On Wed, Oct 31, 2012 at 1:08 PM, Michal Hocko wrote:
> local_irq_disable doesn't guarantee atomicity, because other CPUs will
Maybe it should say atomicity on the local CPU.
> see the change in steps so this is a bit misleading. The real reason
> AFAICS is that we do not want to hang in
On Wed 31-10-12 12:44:03, Tejun Heo wrote:
[...]
> local_irq_save/restore() from cgroup_clear_css_refs() are replaced
> with local_irq_disable/enable() for simplicity. This is safe as
> cgroup_rmdir() is always called with IRQ enabled. Note that this IRQ
> switching is necessary to make CSS deact
2ef37d3fe4 ("memcg: Simplify mem_cgroup_force_empty_list error
handling") removed the last user of __DEPRECATED_clear_css_refs. This
patch removes __DEPRECATED_clear_css_refs and mechanisms to support
it.
* Conditionals dependent on __DEPRECATED_clear_css_refs removed.
* cgroup_clear_css_refs()
On Wed 31-10-12 11:16:24, Tejun Heo wrote:
> 2ef37d3fe4 ("memcg: Simplify mem_cgroup_force_empty_list error
> handling") removed the last user of __DEPRECATED_clear_css_refs. This
> patch removes __DEPRECATED_clear_css_refs and mechanisms to support
> it.
>
> * Conditionals dependent on __DEPRECA
2ef37d3fe4 ("memcg: Simplify mem_cgroup_force_empty_list error
handling") removed the last user of __DEPRECATED_clear_css_refs. This
patch removes __DEPRECATED_clear_css_refs and mechanisms to support
it.
* Conditionals dependent on __DEPRECATED_clear_css_refs removed.
* ->pre_destroy() now can
Hey, Michal.
On Wed, Oct 31, 2012 at 05:48:55PM +0100, Michal Hocko wrote:
> > The WARN_ON_ONCE() is just moved from the original
> > cgroup_call_pre_destroy(). We can add an error out there but that
> > makes future changes difficult. It's a chicken and egg problem. You
> > gotta break the loo
On Wed 31-10-12 09:41:23, Tejun Heo wrote:
> Hey, Michal.
>
> On Wed, Oct 31, 2012 at 03:37:51PM +0100, Michal Hocko wrote:
> > > + for_each_subsys(cgrp->root, ss)
> > > + if (ss->pre_destroy)
> > > + WARN_ON_ONCE(ss->pre_destroy(cgrp));
> >
> > Hmm, I am not sure I like t
Hey, Michal.
On Wed, Oct 31, 2012 at 03:37:51PM +0100, Michal Hocko wrote:
> > + for_each_subsys(cgrp->root, ss)
> > + if (ss->pre_destroy)
> > + WARN_ON_ONCE(ss->pre_destroy(cgrp));
>
> Hmm, I am not sure I like this WARN_ON_ONCE. First it can happen for
> more than
Hello, Glauber.
On Wed, Oct 31, 2012 at 05:21:29PM +0400, Glauber Costa wrote:
> > +
> > + local_irq_disable();
> > +
> > + /* block new css_tryget() by deactivating refcnt */
> > + for_each_subsys(cgrp->root, ss) {
> > + struct cgroup_subsys_state *css = cgrp->subsys[ss->subsys_id
On Tue 30-10-12 21:22:38, Tejun Heo wrote:
> 2ef37d3fe4 ("memcg: Simplify mem_cgroup_force_empty_list error
> handling") removed the last user of __DEPRECATED_clear_css_refs. This
> patch removes __DEPRECATED_clear_css_refs and mechanisms to support
> it.
>
> * Conditionals dependent on __DEPRECA
> }
> prepare_to_wait(&cgroup_rmdir_waitq, &wait, TASK_INTERRUPTIBLE);
> - if (!cgroup_clear_css_refs(cgrp)) {
> - mutex_unlock(&cgroup_mutex);
> - /*
> - * Because someone may call cgroup_wakeup_rmdir_waiter() before
> - * prepare_
2ef37d3fe4 ("memcg: Simplify mem_cgroup_force_empty_list error
handling") removed the last user of __DEPRECATED_clear_css_refs. This
patch removes __DEPRECATED_clear_css_refs and mechanisms to support
it.
* Conditionals dependent on __DEPRECATED_clear_css_refs removed.
* ->pre_destroy() now can
21 matches
Mail list logo
