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] [thread-next>] [day] [month] [year] [list]

Message-ID: <872612b5-b9c6-43aa-a167-1c204d0f1c5a@kernel.dk>
Date:   Fri, 9 Jul 2021 08:18:27 -0600
From:   Jens Axboe <axboe@...nel.dk>
To:     yaozhenguo <yaozhenguo1@...il.com>, oleg@...hat.comm
Cc:     linux-kernel@...r.kernel.org, yaozhenguo@...com
Subject: Re: [PATCH] task_work: return -EBUSY when adding same work

On 7/9/21 6:27 AM, yaozhenguo wrote:
> when same work is added to task->task_works list one by one,
> the list becomes endless loop. So return -EBUSY when this
> situation happen.
> 
> Signed-off-by: yaozhenguo <yaozhenguo1@...il.com>
> ---
>  kernel/task_work.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/task_work.c b/kernel/task_work.c
> index 1698fbe..5061ebf 100644
> --- a/kernel/task_work.c
> +++ b/kernel/task_work.c
> @@ -27,7 +27,7 @@
>   * list is LIFO.
>   *
>   * RETURNS:
> - * 0 if succeeds or -ESRCH.
> + * 0 if succeeds or -ESRCH, -EBUSY.
>   */
>  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?

-- 
Jens Axboe