On Thu, 22 Feb 2018, Jan Kara wrote: > I don't see how task work can be used here. Firstly I don't know of a case > where task work would be used for something else than the current task - > and that is substantial because otherwise you have to deal with lots of > problems like races with task exit, when work gets executed (normally it > gets executed once task exits to userspace) etc. Or do you mean that you'd > queue task work for current task and then somehow magically switch memcg > there? In that case this magic switching isn't clear to me... Thats surprising since one can specify the task. If its only for current then why do you need a parameter? I think a capability of executing a function in the context of another running task could simplify a lot. In particular if something triggers behavior that is related to another task from the kernel like whats happening here. It should not be that difficult to do proper synchronization on the list of work and then set some flag (maybe SIGPENDING) to make the task execute whats on the tasklist. Signal delivery is after all similar. -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
