>       }
>       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_to_wait(), we need to check this flag.
> -              */
> -             if (test_bit(CGRP_WAIT_ON_RMDIR, &cgrp->flags))
> -                     schedule();
> -             finish_wait(&cgroup_rmdir_waitq, &wait);
> -             clear_bit(CGRP_WAIT_ON_RMDIR, &cgrp->flags);
> -             if (signal_pending(current))
> -                     return -EINTR;
> -             goto again;
> +
> +     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];
> +
> +             WARN_ON(atomic_read(&css->refcnt) < 0);
> +             atomic_add(CSS_DEACT_BIAS, &css->refcnt);
>       }
> -     /* NO css_tryget() can success after here. */
> +
> +     /*
> +      * Set REMOVED.  All in-progress css_tryget() will be released.
> +      * Put all the base refs.  Each css holds an extra reference to the
> +      * cgroup's dentry and cgroup removal proceeds regardless of css
> +      * refs.  On the last put of each css, whenever that may be, the
> +      * extra dentry ref is put so that dentry destruction happens only
> +      * after all css's are released.
> +      */
> +     for_each_subsys(cgrp->root, ss) {
> +             struct cgroup_subsys_state *css = cgrp->subsys[ss->subsys_id];
> +
> +             set_bit(CSS_REMOVED, &css->flags);
> +             css_put(css);
> +     }
> +
> +     local_irq_enable();
> +
>       finish_wait(&cgroup_rmdir_waitq, &wait);

It seems to me that the main reason for doing this in two passes was to
derive a global "failed" state on the first pass. Now that we can't
fail, why can't you just loop through the subsystems just once ?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to