On 10/16/20 5:09 PM, Thomas Gleixner wrote: > On Fri, Oct 16 2020 at 16:39, Jens Axboe wrote: >> On 10/16/20 3:44 PM, Thomas Gleixner wrote: >>>> - * @notify: send the notification if true >>>> + * @notify: send chosen notification, if any >>> >>> Is that really all you found to be wrong in that comment? >> >> There really is nothing wrong, but it's not very descriptive (wasn't >> before either). > > * This is like the signal handler which runs in kernel mode, but it doesn't > > > > * try to wake up the @task. > > If find a lot of wrongs in that sentence in context of TWA_SIGNAL. > > Agreed, it was hard to understand before that, but with TWA_SIGNAL it > does not make sense at all.
This is what I currently have: /** * task_work_add - ask the @task to execute @work->func() * @task: the task which should run the callback * @work: the callback to run * @notify: how to notify the targeted task * * Queue @work for task_work_run() below and notify the @task if @notify * is @TWA_RESUME or @TWA_SIGNAL. @TWA_SIGNAL work like signals, in that the * it will interrupt the targeted task and run the task_work. @TWA_RESUME * work is run only when the task exits the kernel and returns to user mode. * Fails if the @task is exiting/exited and thus it can't process this @work. * Otherwise @work->func() will be called when the @task returns from kernel * mode or exits. * * Note: there is no ordering guarantee on works queued here. * * RETURNS: * 0 if succeeds or -ESRCH. */ -- Jens Axboe