On Fri, Aug 04, 2006 at 07:56:03PM -0700, Paul Menage wrote:
> What's the recommended safe way to access current->res_group (or even
> an arbitrary task->res_group) without racing against a concurrent
> set_res_group() call from a different process?
I guess as long as we have done a kref_get() on ->res_group, we are safe
to access it. But this doesnt prevent task->res_group from changing
under our feet.
> For example, when calling numtasks_allow_fork(current->res_group) in
> numtasks, I don't see anything that guarantees that current will
> remain in the same res_group, or even that the res_group will persist
> for the lifetime of the call. (OK, so numtasks_allow_fork() isn't
> exactly a very long function call, but it's the principle that counts
> ...)
I think you have a point, yes. Nothing is protecting current->res_group
while we are in numtasks_allow_fork().
> How about using task->alloc_lock to protect task->res_group? So all
> manipulation would either have to be done inside task->alloc_lock, or
> else would need to use a function such as:
>
> struct resource_group *task_get_res_group(struct task_struct *task) {
> struct resource_group *res;
> lock_task(task);
> res = task->res_group;
> if (res) kref_get(&res->ref);
> unlock_task(task);
> return res;
> }
Sounds like a good idea to me.
> An alternative (more efficient but more complex) approach would be to use RCU.
We can use RCU if we can assume that the readers wont block, while they
are dereferencing task->res_group. That may be a bit of restriction on the
readers I suspect (in case of numtask controller I dont see it to be a problem,
but we havent seen other controllers yet!).
--
Regards,
vatsa
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
ckrm-tech mailing list
https://lists.sourceforge.net/lists/listinfo/ckrm-tech
