linux-kernel - Re: [PATCH] block: Annotate a racy read in blk_do_io

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 for Android: free password hash cracker in your pocket

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

Message-ID: <ca7c2ef0-7e21-4fb3-ac6b-3dae652a7a0e@acm.org>
Date: Fri, 10 May 2024 16:22:58 -0700
From: Bart Van Assche <bvanassche@....org>
To: paulmck@...nel.org
Cc: Breno Leitao <leitao@...ian.org>, Jens Axboe <axboe@...nel.dk>,
 "open list:BLOCK LAYER" <linux-block@...r.kernel.org>,
 open list <linux-kernel@...r.kernel.org>, Marco Elver <elver@...gle.com>
Subject: Re: [PATCH] block: Annotate a racy read in blk_do_io_stat()

On 5/10/24 3:35 PM, Paul E. McKenney wrote:
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index c00cc6c0878a1..78593b40fe7e9 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -194,9 +194,18 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
>    * This data_race() macro is useful for situations in which data races
>    * should be forgiven.  One example is diagnostic code that accesses
>    * shared variables but is not a part of the core synchronization design.
> + * For example, if accesses to a given variable are protected by a lock,
> + * except for diagnostic code, then the accesses under the lock should
> + * be plain C-language accesses and those in the diagnostic code should
> + * use data_race().  This way, KCSAN will complain if buggy lockless
> + * accesses to that variable are introduced, even if the buggy accesses
> + * are protected by READ_ONCE() or WRITE_ONCE().
> + *
> + * This macro *does not* affect normal code generation, but is a hint to
> + * tooling that data races here are to be ignored.  If code generation must
> + * be protected *and* KCSAN should ignore the access, use both data_race()
> + * and READ_ONCE(), for example, data_race(READ_ONCE(x)).
>    *
> - * This macro *does not* affect normal code generation, but is a hint
> - * to tooling that data races here are to be ignored.
>    */

This patch changes the end of the comment from "*/" into "*\n*/".
That's probably unintended? Otherwise this patch looks good to me.

Thanks,

Bart.