If JOBCTL_TASK_WORK is already set on the targeted task, then we need
not go through {lock,unlock}_task_sighand() to set it again and queue
a signal wakeup. This is safe as we're checking it _after adding the
new task_work with cmpxchg().
Signed-off-by: Jens Axboe <[email protected]>
---
Tested this with an intensive task_work based io_uring workload, and
the benefits are quite large.
diff --git a/kernel/task_work.c b/kernel/task_work.c
index 5c0848ca1287..cbf8cab6e864 100644
--- a/kernel/task_work.c
+++ b/kernel/task_work.c
@@ -42,7 +42,8 @@ task_work_add(struct task_struct *task, struct callback_head *work, int notify)
set_notify_resume(task);
break;
case TWA_SIGNAL:
- if (lock_task_sighand(task, &flags)) {
+ if (!(READ_ONCE(task->jobctl) & JOBCTL_TASK_WORK) &&
+ lock_task_sighand(task, &flags)) {
task->jobctl |= JOBCTL_TASK_WORK;
signal_wake_up(task, 0);
unlock_task_sighand(task, &flags);
--
Jens Axboe
On 08/11, Jens Axboe wrote:
>
> --- a/kernel/task_work.c
> +++ b/kernel/task_work.c
> @@ -42,7 +42,8 @@ task_work_add(struct task_struct *task, struct callback_head *work, int notify)
> set_notify_resume(task);
> break;
> case TWA_SIGNAL:
> - if (lock_task_sighand(task, &flags)) {
> + if (!(READ_ONCE(task->jobctl) & JOBCTL_TASK_WORK) &&
> + lock_task_sighand(task, &flags)) {
Aaaaah, sorry Jens, now I think this is racy. So I am glad I didn't add
this optimization into the initial version ;)
It is possible that JOBCTL_TASK_WORK is set but ->task_works == NULL. Say,
task_work_add(TWA_SIGNAL) + task_work_cancel(), or the target task can call
task_work_run() before it enters get_signal().
And in this case another task_work_add(tsk, TWA_SIGNAL) can actually race
with get_signal() which does
current->jobctl &= ~JOBCTL_TASK_WORK;
if (unlikely(current->task_works)) {
spin_unlock_irq(&sighand->siglock);
task_work_run();
nothing guarantees that get_signal() sees ->task_works != NULL. Probably
this is what Jann meant.
We can probably add a barrier into get_signal() but I didn't sleep today,
I'll try to think tomorrow.
Oleg.
On 8/11/20 9:23 AM, Oleg Nesterov wrote:
> On 08/11, Jens Axboe wrote:
>>
>> --- a/kernel/task_work.c
>> +++ b/kernel/task_work.c
>> @@ -42,7 +42,8 @@ task_work_add(struct task_struct *task, struct callback_head *work, int notify)
>> set_notify_resume(task);
>> break;
>> case TWA_SIGNAL:
>> - if (lock_task_sighand(task, &flags)) {
>> + if (!(READ_ONCE(task->jobctl) & JOBCTL_TASK_WORK) &&
>> + lock_task_sighand(task, &flags)) {
>
> Aaaaah, sorry Jens, now I think this is racy. So I am glad I didn't add
> this optimization into the initial version ;)
>
> It is possible that JOBCTL_TASK_WORK is set but ->task_works == NULL. Say,
> task_work_add(TWA_SIGNAL) + task_work_cancel(), or the target task can call
> task_work_run() before it enters get_signal().
>
> And in this case another task_work_add(tsk, TWA_SIGNAL) can actually race
> with get_signal() which does
>
> current->jobctl &= ~JOBCTL_TASK_WORK;
> if (unlikely(current->task_works)) {
> spin_unlock_irq(&sighand->siglock);
> task_work_run();
>
> nothing guarantees that get_signal() sees ->task_works != NULL. Probably
> this is what Jann meant.
>
> We can probably add a barrier into get_signal() but I didn't sleep today,
> I'll try to think tomorrow.
Appreciate you looking into this! Would be pretty critical for me to get
this working.
--
Jens Axboe
On 08/11, Oleg Nesterov wrote:
>
> On 08/11, Jens Axboe wrote:
> >
> > --- a/kernel/task_work.c
> > +++ b/kernel/task_work.c
> > @@ -42,7 +42,8 @@ task_work_add(struct task_struct *task, struct callback_head *work, int notify)
> > set_notify_resume(task);
> > break;
> > case TWA_SIGNAL:
> > - if (lock_task_sighand(task, &flags)) {
> > + if (!(READ_ONCE(task->jobctl) & JOBCTL_TASK_WORK) &&
> > + lock_task_sighand(task, &flags)) {
>
> Aaaaah, sorry Jens, now I think this is racy. So I am glad I didn't add
> this optimization into the initial version ;)
>
> It is possible that JOBCTL_TASK_WORK is set but ->task_works == NULL. Say,
> task_work_add(TWA_SIGNAL) + task_work_cancel(), or the target task can call
> task_work_run() before it enters get_signal().
>
> And in this case another task_work_add(tsk, TWA_SIGNAL) can actually race
> with get_signal() which does
>
> current->jobctl &= ~JOBCTL_TASK_WORK;
> if (unlikely(current->task_works)) {
> spin_unlock_irq(&sighand->siglock);
> task_work_run();
>
> nothing guarantees that get_signal() sees ->task_works != NULL. Probably
> this is what Jann meant.
>
> We can probably add a barrier into get_signal() but I didn't sleep today,
> I'll try to think tomorrow.
I see nothing better than the additional change below. Peter, do you see
another solution?
This needs a comment to explain that this mb() pairs with another barrier
provided by cmpxchg() in task_work_add(). It ensures that either get_signal()
sees the new work added by task_work_add(), or task_work_add() sees the
result of "&= ~JOBCTL_TASK_WORK".
Oleg.
--- x/kernel/signal.c
+++ x/kernel/signal.c
@@ -2541,7 +2541,7 @@ bool get_signal(struct ksignal *ksig)
relock:
spin_lock_irq(&sighand->siglock);
- current->jobctl &= ~JOBCTL_TASK_WORK;
+ smp_store_mb(current->jobctl, current->jobctl & ~JOBCTL_TASK_WORK);
if (unlikely(current->task_works)) {
spin_unlock_irq(&sighand->siglock);
task_work_run();
On Wed, Aug 12, 2020 at 04:54:23PM +0200, Oleg Nesterov wrote:
> I see nothing better than the additional change below. Peter, do you see
> another solution?
Nope -- although I don't claim to understand the signal code much.
> This needs a comment to explain that this mb() pairs with another barrier
> provided by cmpxchg() in task_work_add(). It ensures that either get_signal()
> sees the new work added by task_work_add(), or task_work_add() sees the
> result of "&= ~JOBCTL_TASK_WORK".
>
> Oleg.
>
> --- x/kernel/signal.c
> +++ x/kernel/signal.c
> @@ -2541,7 +2541,7 @@ bool get_signal(struct ksignal *ksig)
>
> relock:
> spin_lock_irq(&sighand->siglock);
> - current->jobctl &= ~JOBCTL_TASK_WORK;
> + smp_store_mb(current->jobctl, current->jobctl & ~JOBCTL_TASK_WORK);
> if (unlikely(current->task_works)) {
> spin_unlock_irq(&sighand->siglock);
> task_work_run();
>
I agree this should work; smp_store_mb() isn't my favourite primitive,
but yes, this seems as good a use of it as there is so why not.
On 8/12/20 8:54 AM, Oleg Nesterov wrote:
> On 08/11, Oleg Nesterov wrote:
>>
>> On 08/11, Jens Axboe wrote:
>>>
>>> --- a/kernel/task_work.c
>>> +++ b/kernel/task_work.c
>>> @@ -42,7 +42,8 @@ task_work_add(struct task_struct *task, struct callback_head *work, int notify)
>>> set_notify_resume(task);
>>> break;
>>> case TWA_SIGNAL:
>>> - if (lock_task_sighand(task, &flags)) {
>>> + if (!(READ_ONCE(task->jobctl) & JOBCTL_TASK_WORK) &&
>>> + lock_task_sighand(task, &flags)) {
>>
>> Aaaaah, sorry Jens, now I think this is racy. So I am glad I didn't add
>> this optimization into the initial version ;)
>>
>> It is possible that JOBCTL_TASK_WORK is set but ->task_works == NULL. Say,
>> task_work_add(TWA_SIGNAL) + task_work_cancel(), or the target task can call
>> task_work_run() before it enters get_signal().
>>
>> And in this case another task_work_add(tsk, TWA_SIGNAL) can actually race
>> with get_signal() which does
>>
>> current->jobctl &= ~JOBCTL_TASK_WORK;
>> if (unlikely(current->task_works)) {
>> spin_unlock_irq(&sighand->siglock);
>> task_work_run();
>>
>> nothing guarantees that get_signal() sees ->task_works != NULL. Probably
>> this is what Jann meant.
>>
>> We can probably add a barrier into get_signal() but I didn't sleep today,
>> I'll try to think tomorrow.
>
> I see nothing better than the additional change below. Peter, do you see
> another solution?
>
> This needs a comment to explain that this mb() pairs with another barrier
> provided by cmpxchg() in task_work_add(). It ensures that either get_signal()
> sees the new work added by task_work_add(), or task_work_add() sees the
> result of "&= ~JOBCTL_TASK_WORK".
>
> Oleg.
>
> --- x/kernel/signal.c
> +++ x/kernel/signal.c
> @@ -2541,7 +2541,7 @@ bool get_signal(struct ksignal *ksig)
>
> relock:
> spin_lock_irq(&sighand->siglock);
> - current->jobctl &= ~JOBCTL_TASK_WORK;
> + smp_store_mb(current->jobctl, current->jobctl & ~JOBCTL_TASK_WORK);
> if (unlikely(current->task_works)) {
> spin_unlock_irq(&sighand->siglock);
> task_work_run();
>
I think this should work when paired with the READ_ONCE() on the
task_work_add() side. I haven't managed to reproduce badness with the
existing one that doesn't have the smp_store_mb() here, so can't verify
much beyond that...
Are you going to send this out as a complete patch?
--
Jens Axboe
On 08/12, Jens Axboe wrote:
>
> On 8/12/20 8:54 AM, Oleg Nesterov wrote:
> >
> > --- x/kernel/signal.c
> > +++ x/kernel/signal.c
> > @@ -2541,7 +2541,7 @@ bool get_signal(struct ksignal *ksig)
> >
> > relock:
> > spin_lock_irq(&sighand->siglock);
> > - current->jobctl &= ~JOBCTL_TASK_WORK;
> > + smp_store_mb(current->jobctl, current->jobctl & ~JOBCTL_TASK_WORK);
> > if (unlikely(current->task_works)) {
> > spin_unlock_irq(&sighand->siglock);
> > task_work_run();
> >
>
> I think this should work when paired with the READ_ONCE() on the
> task_work_add() side.
It pairs with mb (implied by cmpxchg) before READ_ONCE. So we roughly have
task_work_add: get_signal:
STORE(task->task_works, new_work); STORE(task->jobctl);
mb(); mb();
LOAD(task->jobctl); LOAD(task->task_works);
and we can rely on STORE-MB-LOAD.
> I haven't managed to reproduce badness with the
> existing one that doesn't have the smp_store_mb() here, so can't verify
> much beyond that...
Yes, the race is very unlikely. And the problem is minor, the target task
can miss the new work added by TWA_SIGNAL and return from get_signal() without
TIF_SIGPENDING.
> Are you going to send this out as a complete patch?
Jens, could you please send the patch? I am on vacation and travelling.
Feel free to add my ACK.
Oleg.