Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp4673812ybf; Wed, 4 Mar 2020 08:27:39 -0800 (PST) X-Google-Smtp-Source: ADFU+vspMJNZKgz3zH9U84L7gtr6/+E1oEhnH/sv+3WxxSmmB0ApLRLcxwUFLuLhnqVSCq8FbGPh X-Received: by 2002:a05:6830:1615:: with SMTP id g21mr3098531otr.49.1583339259029; Wed, 04 Mar 2020 08:27:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583339259; cv=none; d=google.com; s=arc-20160816; b=o4kM23waAdmkUnwipYPI04m5A9EzBEje2P8HXN8kbCq/00mP2Dz7A4jxi+VECr9CVE Q71U8FBQ1oKsIujK03dT1GKLluRsW+nqQMKQn5yyEccNqyH5MCGvMtprbQ8x7lDJQ5jl 3wzTYOC1vVj2z6vPOp8Mu9yt+L+rJhQOJ2VRljuBx9VppEqrjKMI88jj99sjJlU3Otuw tGYjIzIrKC66MO2p9UrHuBV+y8f8WRyhKY2tEWZpYxU1H47gPtxWPEO2x6MypHprNTle KUzwNTLWJFqum8tEoNkGv5+qQuQtUVjxbnAdsrr0bFNIcBfi0f/w2VPJTnadsxue0jbh dvgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:from:subject:references :mime-version:message-id:in-reply-to:date:dkim-signature; bh=0XgZjHOQdGAxXnAanWU5HksJ52ua72n/XN1fQpNKAB0=; b=qksljU/6k7BsLDNT4b9EK3A57VwFmwdMuoaO7znWc6Z+0FZPc7k3TWvV2dQtru3IZT RsIvlbXWPKwqkIGgapUExpcRSX6Thb9FDLedusVoFZOTMIf/7aK7FD4yuMmYOilkW7jS Z58rDnPd4tdly/GKOui/kKbCOfQtRi1EyeEth1my80i6eq8SrKMZU0bo5IND1ggHPwzw 9FXU6xA3M2qxLsDyNP7Z+z0AobQPaYQHzWRFyx6dloSjXB2AoWEgRSsuYI3RJXucoPmU 4LOhotQYjF77AarDYTzCPhqO4acoq5N0oazEXNRgssivV2Z5IFNznnLzsrBWG46sg/jw xpEw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=g8pGpYPs; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l8si1460993oii.249.2020.03.04.08.27.26; Wed, 04 Mar 2020 08:27:39 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=g8pGpYPs; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388280AbgCDQ1C (ORCPT + 99 others); Wed, 4 Mar 2020 11:27:02 -0500 Received: from mail-wm1-f74.google.com ([209.85.128.74]:56257 "EHLO mail-wm1-f74.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388315AbgCDQ07 (ORCPT ); Wed, 4 Mar 2020 11:26:59 -0500 Received: by mail-wm1-f74.google.com with SMTP id v21so746804wml.5 for ; Wed, 04 Mar 2020 08:26:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:in-reply-to:message-id:mime-version:references:subject:from:to :cc; bh=0XgZjHOQdGAxXnAanWU5HksJ52ua72n/XN1fQpNKAB0=; b=g8pGpYPsvsDBrxlO6M3Y4hyIMgiyMcfYpKkTsZMXMp2XdZRs26B29lIDZ0AuNxaw7b YspHylRaXDB0l6aDBl5gPboatWoZhU7g8xQgKFsnUrXEw1hWc+H783wR6tYEQZOi7w0E ylp9ygDFP4GfK1NbxWuFz3Bnd5tP7Qu+rLH2qWCeQw0LpDEHS+aqvs7iw3TL0t6G1C8O hNCOVQlhQu6i37LnBhERzPCqOl1T3LYex0b12Dk7crnY1Xdtx3DJPRiTsENMl7Dtz84v MTtOuTCjdcMx7mSrkm/Wvqp2lfwmgbia7n+BfS/krcy2ARjEsQGizs8LqzS+TM9OtVQ7 c1uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:in-reply-to:message-id:mime-version :references:subject:from:to:cc; bh=0XgZjHOQdGAxXnAanWU5HksJ52ua72n/XN1fQpNKAB0=; b=EajIvmP6hBzw8xMPViPagwqKGdGxpPlqfawnxD6HtnlYX5t7nVKFuFJwGn+cKdcLRs hi5k9tuWaQn2ig9Qbacg0bCVeHbIyPUFI6FUGPCV9jhII7/b1jZn7bKnQYf3HOoCB7Mk 2Zo/iz5YxLfC5YvtCADiuzsknbTfYAjWNCRB5mbPTblyslJtIgk42VDis9EEDIC+KnLM qXJc2u+6ScKmaOMYLYl8P0kUJ0m0UT9lHkXy4n690JrZ4sWApJuwf00F1WIFZHBy3ayu hIZrcLmqbVfvfnor0tv8Fv1DD+bVRoRC/59sfURvTnuk9OF31BvnTzdXDuyE4JtDVNDM ZtPw== X-Gm-Message-State: ANhLgQ23x1QJ/MCCfBrzTEKzBxvCJFN5FIfw3fKpAn3JmUmWMQIGjlEk phiQvxMga24iKiknOJjQRq2CgD8Ikw== X-Received: by 2002:adf:db84:: with SMTP id u4mr4877175wri.317.1583339215472; Wed, 04 Mar 2020 08:26:55 -0800 (PST) Date: Wed, 4 Mar 2020 17:25:41 +0100 In-Reply-To: <20200304162541.46663-1-elver@google.com> Message-Id: <20200304162541.46663-3-elver@google.com> Mime-Version: 1.0 References: <20200304162541.46663-1-elver@google.com> X-Mailer: git-send-email 2.25.0.265.gbab2e86ba0-goog Subject: [PATCH 3/3] kcsan: Update API documentation in kcsan-checks.h From: Marco Elver To: elver@google.com Cc: paulmck@kernel.org, andreyknvl@google.com, glider@google.com, dvyukov@google.com, kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, corbet@lwn.net, linux-doc@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Update the API documentation for ASSERT_EXCLUSIVE_* macros and make them generate readable documentation for the code examples. All @variable short summaries were missing ':', which was updated for the whole file. Tested with 'make htmldocs'. Signed-off-by: Marco Elver --- include/linux/kcsan-checks.h | 98 ++++++++++++++++++++++-------------- 1 file changed, 61 insertions(+), 37 deletions(-) diff --git a/include/linux/kcsan-checks.h b/include/linux/kcsan-checks.h index 1b8aac5d6a0b5..14fd10e5a9177 100644 --- a/include/linux/kcsan-checks.h +++ b/include/linux/kcsan-checks.h @@ -26,9 +26,9 @@ /** * __kcsan_check_access - check generic access for races * - * @ptr address of access - * @size size of access - * @type access type modifier + * @ptr: address of access + * @size: size of access + * @type: access type modifier */ void __kcsan_check_access(const volatile void *ptr, size_t size, int type); @@ -64,7 +64,7 @@ void kcsan_flat_atomic_end(void); * Force treating the next n memory accesses for the current context as atomic * operations. * - * @n number of following memory accesses to treat as atomic. + * @n: number of following memory accesses to treat as atomic. */ void kcsan_atomic_next(int n); @@ -74,7 +74,7 @@ void kcsan_atomic_next(int n); * Set the access mask for all accesses for the current context if non-zero. * Only value changes to bits set in the mask will be reported. * - * @mask bitmask + * @mask: bitmask */ void kcsan_set_access_mask(unsigned long mask); @@ -106,16 +106,16 @@ static inline void kcsan_check_access(const volatile void *ptr, size_t size, /** * __kcsan_check_read - check regular read access for races * - * @ptr address of access - * @size size of access + * @ptr: address of access + * @size: size of access */ #define __kcsan_check_read(ptr, size) __kcsan_check_access(ptr, size, 0) /** * __kcsan_check_write - check regular write access for races * - * @ptr address of access - * @size size of access + * @ptr: address of access + * @size: size of access */ #define __kcsan_check_write(ptr, size) \ __kcsan_check_access(ptr, size, KCSAN_ACCESS_WRITE) @@ -123,16 +123,16 @@ static inline void kcsan_check_access(const volatile void *ptr, size_t size, /** * kcsan_check_read - check regular read access for races * - * @ptr address of access - * @size size of access + * @ptr: address of access + * @size: size of access */ #define kcsan_check_read(ptr, size) kcsan_check_access(ptr, size, 0) /** * kcsan_check_write - check regular write access for races * - * @ptr address of access - * @size size of access + * @ptr: address of access + * @size: size of access */ #define kcsan_check_write(ptr, size) \ kcsan_check_access(ptr, size, KCSAN_ACCESS_WRITE) @@ -158,14 +158,26 @@ static inline void kcsan_check_access(const volatile void *ptr, size_t size, * allowed. This assertion can be used to specify properties of concurrent code, * where violation cannot be detected as a normal data race. * - * For example, if a per-CPU variable is only meant to be written by a single - * CPU, but may be read from other CPUs; in this case, reads and writes must be - * marked properly, however, if an off-CPU WRITE_ONCE() races with the owning - * CPU's WRITE_ONCE(), would not constitute a data race but could be a harmful - * race condition. Using this macro allows specifying this property in the code - * and catch such bugs. + * For example, if we only have a single writer, but multiple concurrent + * readers, to avoid data races, all these accesses must be marked; even + * concurrent marked writes racing with the single writer are bugs. + * Unfortunately, due to being marked, they are no longer data races. For cases + * like these, we can use the macro as follows: * - * @var variable to assert on + * .. code-block:: c + * + * void writer(void) { + * spin_lock(&update_foo_lock); + * ASSERT_EXCLUSIVE_WRITER(shared_foo); + * WRITE_ONCE(shared_foo, ...); + * spin_unlock(&update_foo_lock); + * } + * void reader(void) { + * // update_foo_lock does not need to be held! + * ... = READ_ONCE(shared_foo); + * } + * + * @var: variable to assert on */ #define ASSERT_EXCLUSIVE_WRITER(var) \ __kcsan_check_access(&(var), sizeof(var), KCSAN_ACCESS_ASSERT) @@ -177,16 +189,22 @@ static inline void kcsan_check_access(const volatile void *ptr, size_t size, * writers). This assertion can be used to specify properties of concurrent * code, where violation cannot be detected as a normal data race. * - * For example, in a reference-counting algorithm where exclusive access is - * expected after the refcount reaches 0. We can check that this property - * actually holds as follows: + * For example, where exclusive access is expected after determining no other + * users of an object are left, but the object is not actually freed. We can + * check that this property actually holds as follows: + * + * .. code-block:: c * * if (refcount_dec_and_test(&obj->refcnt)) { * ASSERT_EXCLUSIVE_ACCESS(*obj); - * safely_dispose_of(obj); + * do_some_cleanup(obj); + * release_for_reuse(obj); * } * - * @var variable to assert on + * Note: For cases where the object is freed, `KASAN `_ is a better + * fit to detect use-after-free bugs. + * + * @var: variable to assert on */ #define ASSERT_EXCLUSIVE_ACCESS(var) \ __kcsan_check_access(&(var), sizeof(var), KCSAN_ACCESS_WRITE | KCSAN_ACCESS_ASSERT) @@ -200,7 +218,7 @@ static inline void kcsan_check_access(const volatile void *ptr, size_t size, * concurrent readers are permitted. This assertion captures more detailed * bit-level properties, compared to the other (word granularity) assertions. * Only the bits set in @mask are checked for concurrent modifications, while - * ignoring the remaining bits, i.e. concurrent writes (or reads) to ~@mask bits + * ignoring the remaining bits, i.e. concurrent writes (or reads) to ~mask bits * are ignored. * * Use this for variables, where some bits must not be modified concurrently, @@ -210,17 +228,21 @@ static inline void kcsan_check_access(const volatile void *ptr, size_t size, * but other bits may still be modified concurrently. A reader may wish to * assert that this is true as follows: * + * .. code-block:: c + * * ASSERT_EXCLUSIVE_BITS(flags, READ_ONLY_MASK); * foo = (READ_ONCE(flags) & READ_ONLY_MASK) >> READ_ONLY_SHIFT; * - * Note: The access that immediately follows ASSERT_EXCLUSIVE_BITS() is - * assumed to access the masked bits only, and KCSAN optimistically assumes it - * is therefore safe, even in the presence of data races, and marking it with - * READ_ONCE() is optional from KCSAN's point-of-view. We caution, however, - * that it may still be advisable to do so, since we cannot reason about all - * compiler optimizations when it comes to bit manipulations (on the reader - * and writer side). If you are sure nothing can go wrong, we can write the - * above simply as: + * Note: The access that immediately follows ASSERT_EXCLUSIVE_BITS() is assumed + * to access the masked bits only, and KCSAN optimistically assumes it is + * therefore safe, even in the presence of data races, and marking it with + * READ_ONCE() is optional from KCSAN's point-of-view. We caution, however, that + * it may still be advisable to do so, since we cannot reason about all compiler + * optimizations when it comes to bit manipulations (on the reader and writer + * side). If you are sure nothing can go wrong, we can write the above simply + * as: + * + * .. code-block:: c * * ASSERT_EXCLUSIVE_BITS(flags, READ_ONLY_MASK); * foo = (flags & READ_ONLY_MASK) >> READ_ONLY_SHIFT; @@ -230,15 +252,17 @@ static inline void kcsan_check_access(const volatile void *ptr, size_t size, * be modified concurrently. Writers, where other bits may change concurrently, * could use the assertion as follows: * + * .. code-block:: c + * * spin_lock(&foo_lock); * ASSERT_EXCLUSIVE_BITS(flags, FOO_MASK); - * old_flags = READ_ONCE(flags); + * old_flags = flags; * new_flags = (old_flags & ~FOO_MASK) | (new_foo << FOO_SHIFT); * if (cmpxchg(&flags, old_flags, new_flags) != old_flags) { ... } * spin_unlock(&foo_lock); * - * @var variable to assert on - * @mask only check for modifications to bits set in @mask + * @var: variable to assert on + * @mask: only check for modifications to bits set in @mask */ #define ASSERT_EXCLUSIVE_BITS(var, mask) \ do { \ -- 2.25.0.265.gbab2e86ba0-goog