Messages in this thread | | | Date | Sat, 14 Apr 2012 22:27:08 +0200 | From | Oleg Nesterov <> | Subject | Re: [PATCH v4 1/3] task_work_add: generic process-context callbacks |
| |
On 04/14, Linus Torvalds wrote: > > On Fri, Apr 13, 2012 at 8:39 PM, Oleg Nesterov <oleg@redhat.com> wrote: > >> > > Once the caller does task_work_add(twork), it no longer "owns" this > > twork. > > > > But, if task_work_cancel() succeeds - you own it again. > > *IF* it succeeds.
Sure.
> >> But then you can't allocate it on the stack any more, and have to > >> allocate it separately. > > > > Yes, unless you do task_work_add/cancel(current). > > Ok, your argument seems to be that "current" is special, and can not > race, because the work execution is always synchronous with the task > it got scheduled on.
Yes, exactly.
> And that whole "run_task_work()" function should *not* take a "task" > pointer, because it would be horribly horribly wrong to ever run it in > any context than "current".
And it was task_work_queue(void) initially. But then I decided to micro-optimize this, the callers already have this task_struct in the register. And we have other examples like this, say, exit_mm().
However. I agree that it would be more understandable and clean to use current in task_work_run(void), and percpu_read is cheap.
So I'll remove this argument and send v5 after David reviews 3/3.
Oleg.
| |