Re: [PATCH] sched: fix another race when reading /proc/sched_debug

[Paul Menage]

On Mon, Dec 15, 2008 at 2:43 AM, Peter Zijlstra <a.p.zijlstra@xxxxxxxxx> wrote:
>>
>> +             /*
>> +              * Some subsystems (cpu cgroup) might still be able to
>> +              * accessing the cgroup in rcu section.
>> +              */
>> +             synchronize_rcu();
>> +
>>               kfree(cgrp);
>>       }
>>       iput(inode);
>
> Is there any reason we cannot use call_rcu() ?

It should be OK to rcu-free cgrp and have it still safe to call
cgroup_path() on it - as long as we're confident that the dentry (and
all its parents) won't be released until after the RCU section as
well, since that's where we get the path elements from. And that does
seem to be the case from looking at dcache.c

It's certainly nicer than having two calls to synchronize_rcu() in
quick succession in cgroup_diput().
>
> Perhaps wrap that check in a cgroup_*() helper? That would avoid the
> duplication, be clearer and not open code the ->dentry assumption.

I think it would be simpler to not have the cgroup exposed to the
subsystem until the dentry and other structures have been created. The
current order (create subsystems, then create fs structures) is more
or less a carry-over from when I extended cpusets, rather than an
explicit design choice.

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