linux-kernel - Re: [PATCH] task_work: return -EBUSY when adding same work

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 13 Jul 2021 14:22:10 -0600
From:   Jens Axboe <axboe@...nel.dk>
To:     David Laight <David.Laight@...LAB.COM>,
        yaozhenguo <yaozhenguo1@...il.com>,
        "oleg@...hat.comm" <oleg@...hat.comm>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "yaozhenguo@...com" <yaozhenguo@...com>
Subject: Re: [PATCH] task_work: return -EBUSY when adding same work

On 7/13/21 4:41 AM, David Laight wrote:
> From: Jens Axboe
>> Sent: 09 July 2021 15:18
> ...
>>>   */
>>>  int task_work_add(struct task_struct *task, struct callback_head *work,
>>>  		  enum task_work_notify_mode notify)
>>> @@ -41,6 +41,8 @@ int task_work_add(struct task_struct *task, struct callback_head *work,
>>>  		head = READ_ONCE(task->task_works);
>>>  		if (unlikely(head == &work_exited))
>>>  			return -ESRCH;
>>> +		if (unlikely(head == work))
>>> +			return -EBUSY;
>>>  		work->next = head;
>>>  	} while (cmpxchg(&task->task_works, head, work) != head);
>>
>> I don't think there's anything conceptually wrong with this patch, but
>> it makes me think that you hit this condition. It's really a bug in the
>> caller, of course, is a WARN_ON_ONCE() warranted here? And who was the
>> caller?
> 
> How can the caller know that the task is on the queue?

It's similar to double adding a list entry to a list. It's the callers
responsibility to make sure that doesn't happen. The item happens to be
per-task here, but that doesn't really change the mechanics of it.

> There will be a race condition just before the work function
> is called and/or just after it returns that the caller
> can't detect.
> The check needs to be done atomically with the code that
> removes the work item from the list.

We're not polluting task_work with caller specific code like that, as
far as I'm concerned. Fix it in the caller. By the time ->func is run,
the item is off the original list and it can get re-added just fine. If
the event triggers after removing from the list but before ->func is
called, I don't see a problem with that. The caller just wants to ensure
that func is run, which it will be.

If the caller needs stronger guarantees than that, then it should
implement them separately on top of task_work.

-- 
Jens Axboe