lkml.org 
[lkml]   [2012]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.



\
 
 \ /
  Last update: 2012-04-14 22:31    [W:0.072 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site