linux-kernel - Re: [PATCH 07/13] task_work: Introduce task_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: <87cziubtfu.fsf@email.froward.int.ebiederm.org>
Date:   Wed, 09 Mar 2022 17:24:37 -0600
From:   "Eric W. Biederman" <ebiederm@...ssion.com>
To:     Jens Axboe <axboe@...nel.dk>
Cc:     linux-kernel@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Alexey Gladkov <legion@...nel.org>,
        Kyle Huey <me@...ehuey.com>, Oleg Nesterov <oleg@...hat.com>,
        Kees Cook <keescook@...omium.org>,
        Al Viro <viro@...IV.linux.org.uk>
Subject: Re: [PATCH 07/13] task_work: Introduce task_work_pending

Jens Axboe <axboe@...nel.dk> writes:

> On 3/9/22 9:24 AM, Eric W. Biederman wrote:
>> diff --git a/include/linux/task_work.h b/include/linux/task_work.h
>> index 5b8a93f288bb..897494b597ba 100644
>> --- a/include/linux/task_work.h
>> +++ b/include/linux/task_work.h
>> @@ -19,6 +19,11 @@ enum task_work_notify_mode {
>>  	TWA_SIGNAL,
>>  };
>>  
>> +static inline bool task_work_pending(struct task_struct *task)
>> +{
>> +	return READ_ONCE(task->task_works);
>> +}
>> +
>
> Most of the checks for this is current, do we need READ_ONCE here?

There is a non-current use in fs/io_uring in __io_uring_show_fdinfo
and another in task_work_cancel_match.

Beyond that there are quite a few writes that are not at all from
current so even on current task->task_works can change if you look
twice.

So if only to keep it from making unwarranted assumptions I think
READ_ONCE makes sense.

Given that READ_ONCE is practically free I don't see where there is
any harm in using it to document the kind of code we expect the compiler
to generate.

Looking a second time I see all of the other reads of task->task_works
are already READ_ONCE in kernel/task_work.c, so really I think if we
don't want READ_ONCE we need a big fat comment about why it is safe
in a check like task_work_pending and while it is needed everywhere
else.  At the moment I am not smart enough to write that comment.

I will see about adding this bit of discussion in the commit comment to
make it a little clearer why I am introducing READ_ONCE.

Eric