From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 10C0EC48291 for ; Fri, 2 Feb 2024 10:13:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 785906B007E; Fri, 2 Feb 2024 05:13:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 70EE46B0080; Fri, 2 Feb 2024 05:13:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 588976B0082; Fri, 2 Feb 2024 05:13:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 45C976B007E for ; Fri, 2 Feb 2024 05:13:38 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 004BD40EB7 for ; Fri, 2 Feb 2024 10:13:37 +0000 (UTC) X-FDA: 81746452074.27.B409E1A Received: from mail-ua1-f43.google.com (mail-ua1-f43.google.com [209.85.222.43]) by imf06.hostedemail.com (Postfix) with ESMTP id 3C44418000D for ; Fri, 2 Feb 2024 10:13:35 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="c/gSjVFb"; spf=pass (imf06.hostedemail.com: domain of elver@google.com designates 209.85.222.43 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706868816; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=itc1lWSzDl2ak1k3l4KGvZCc9ZWdvBnL0W7Kq6iSLm8=; b=yui2ZHKffa58XE6jj/VwVXDvpABRdau/Ar6BDlNOF7myeNFEXSrC1H8NXdfXF54ewES1Ep LOChPSWld+bDOjQEJRF6ZTgUJNrDgJItLyBqlffi8HYsfqbCDILOPJNLmSOAkfSSMuubPb f+6qtgGSmG5M/DJKzebNz8me1K398UM= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="c/gSjVFb"; spf=pass (imf06.hostedemail.com: domain of elver@google.com designates 209.85.222.43 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706868816; a=rsa-sha256; cv=none; b=K6li+fa/c2Aoj3LxrDPWbpOh0RDDuuBLbHsYgfp52ijjukBynDHam0lY3uO8F2AEzTAigr Me9aprHvkxjzmSTG07nPF2EIx2+DgdCugs2wKC11sGKZWvTKTvboboJDo2bQxtbf1xhfsO 3TGpgBhCLR/qsouHKKzB64d4iMHEwHU= Received: by mail-ua1-f43.google.com with SMTP id a1e0cc1a2514c-7ce3c7566e0so928687241.1 for ; Fri, 02 Feb 2024 02:13:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1706868815; x=1707473615; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=itc1lWSzDl2ak1k3l4KGvZCc9ZWdvBnL0W7Kq6iSLm8=; b=c/gSjVFbEzxReZeqhbTImAWoaxMngMr+FO4rRWwWyIx6YtXI2ejyEzUulzyljDRg4x S6Rz0RpKS+Zps9cfCRH5m1622vE5VjF8kFP7wScmMJkp7jhxMFPOOH9fN4zv481P4iXZ hUFieDSCZW4Dhp4KeDrSWrpBfnQKzBPIotwTScvD7EQLhXBZvH+auBnsejlsoRR2Ltbx hcZgo5Hbqx7K/Tw3Otsl6S9mcXTTXRuuAnp0X8dCw/Zp83KkZXkn/m3Rw6ZLV1a+sNdp Hx58J0b59ojC8Wwx6vtg1PzWf9tu/8W5A+C5KjZi3c1ad5ulojc/YshhfZJOEcxxfJqB 2Tug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706868815; x=1707473615; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=itc1lWSzDl2ak1k3l4KGvZCc9ZWdvBnL0W7Kq6iSLm8=; b=UShmlUpbkAirNyYyLsBK9YdlAruuRRUyTcqNZ6Ova9/y/VCTVBH1lLFG7WNOUePdgJ QQ0op7Zcd0zL3rnvbgZlxMnbjqTkdF3xMmdXqQo2CqLIjiL15Lp85WseTxmQ5Vui6sfK /5EMLFNaxUsHwZqBqPA1SkOtlabYNb1Y2Cp5FDaHBTqGrwy7GXua/oLWKfDy9hMAiXhe chiLHcPhlqoV68GVly+5M7YU+Wlk/MuTpNlfcBYQALbo2lTI+ZlmxLH9dD3DLe9Se3Ux ENLI3iFpxrY6BgxF9VrSJnQzG9qvEAnDCsRJaz7adK5Al+XFSAz+qrxCey6eYUMqOp5z Swzw== X-Gm-Message-State: AOJu0Yw/vy7QwVSCMONTA32Q/L9hks+yzz8eNaZ4r7Y3n0IIiMgw+1TA m5cjMFaNm6xKsTpvfWvtQcrKlPzUMX86k6jGUdkP+900nCLxr+Z9rVJr66xjry4wOt0dFVxOlnw s9mTKbRezM5GfUbm7lkySm1z97Pb+UZmINwcy X-Google-Smtp-Source: AGHT+IEzBgLYEciVPVcpCXSuKNO5sRz/LDpHNGxnl1X6HRseV3PVdmUe7idbfSkvOlrk/qYs+fmMOUdq2h2uHAW10r8= X-Received: by 2002:a05:6122:13a:b0:4bd:789a:64dd with SMTP id a26-20020a056122013a00b004bd789a64ddmr6184191vko.2.1706868814944; Fri, 02 Feb 2024 02:13:34 -0800 (PST) MIME-Version: 1.0 References: <20240131210041.686657-1-paul.heidekrueger@tum.de> In-Reply-To: From: Marco Elver Date: Fri, 2 Feb 2024 11:12:56 +0100 Message-ID: Subject: Re: Re: [PATCH RFC v2] kasan: add atomic tests To: =?UTF-8?Q?Paul_Heidekr=C3=BCger?= Cc: Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Andrew Morton , kasan-dev@googlegroups.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 3C44418000D X-Rspam-User: X-Stat-Signature: as5quea4tw9th7dgef6zfturkj91oju8 X-Rspamd-Server: rspam01 X-HE-Tag: 1706868815-784965 X-HE-Meta: U2FsdGVkX1+53RvWB6vLfM4zMpLnWRnhvVNBBjnu+X2aEbYU+0ZnrpfBj6gBw+8hQppTP4okASZK3mbAXiZc5fQwRthakEu+OwaUy3oRvvZ53b8sRYyK/gJWyJmLgKFtbZFnjxqlhKDiDFxDurXfkn7SWa0d2w5nUx7OcHQ/sKukb8d3xQF/nNiTqPhGvX4fBTLQVlNkTY5S1IFjcq1ZymKxl29AMDXXoDyc7Nm5II9SS3wlNXZg+/JdO+uW/oEdXTkOionn5mDJUsjICSl5ykF1rWlQScy/AmuNkE5FOkFQFx8W/HzOhNUaevjI4v4xQQQmRHH5yC44RGvyx8oHnz8ZZD7ZU+drGeNAusScdVruoHFKqNCqXNbrC6bOCN+dVOOGELsXDPRR4aLYh5XA7AA91hhGAHPUBXmsXjnqBnUGoyArMXLdW7kC5vKZfV5ktTe9rNYR3NH1a2vFf1iglf0nl6QX7AUHgSNqxxq2T1gAmkbFrEIyG37xPh5D9fmhHBx3cAyAfFuIsS1UPX6G25rxZUCw9Y2qZ8OzQGTUyM2C2p7AJvHaTr9kmRh6jkDLPZkx5rdBUSO0TVxRASNHKbbsYCOfPY90RufYp/sh4yQZYCS/lRV38EKAIb5gqnogk+EcbiudUeYBgKqUeeVvjwlfnVwaToPMtslTE3TNEfmjhwr5rz7g8Cf9532CJALHem56s8FpYXSGYNfyYZeNDWiOCiLDxSDF7xKZYPC3fcKB/3Fj5QjGEbk8i83oWD03EsdTgTbx6ym74CYuYrPdQJXLQRooGHxsBT38fYQ2fpCd4sxZjLZph1PfuWnOhFUR6ZDt42Fp/5h5cKrP48FAAjS0YUuXlUMGzBQwHEPDSJ/FuJGYi3AbxNnPQwoRwhF4p6QrzHP6kWDM95QXhVHAGwPSE1qgLoOh++Lnh1QdH730zoSxMg8QOkfvXplamvgGFqNIS7IhPnxCuDBqUfE dFJk3WrN ISXR/c7nup3YBhB9vOqn5ONZTARoxXXerMLbgJ7n4ge7LOoqu5oGolPk1RompfE/xm/NlcShhyKZObpEO6Nt/vubArE4/gTvDYo84UH8BnMmWj4LTwhEQm+9XDmaymCjz9VO6e0ztPLVC1dvu7sOzKYBiyjMYKsICLxc1DWr+IaUCyuCWJiXnDxszMxsLawWAxSFIgYKwjp5M1GKhHd9Lan+WaYJRT+5J3UUVIIJYr7dLb3oNM9raWaIDXjX3lM/Ag6cEoWFGwgza2LJ+K+Dnax915cgRUIHH/X2grrb8EKgE+W0= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, 2 Feb 2024 at 11:03, Paul Heidekr=C3=BCger wrote: > > On 01.02.2024 10:38, Marco Elver wrote: > > On Wed, 31 Jan 2024 at 22:01, Paul Heidekr=C3=BCger wrote: > > > > > > Hi! > > > > > > This RFC patch adds tests that detect whether KASan is able to catch > > > unsafe atomic accesses. > > > > > > Since v1, which can be found on Bugzilla (see "Closes:" tag), I've ma= de > > > the following suggested changes: > > > > > > * Adjust size of allocations to make kasan_atomics() work with all KA= San modes > > > * Remove comments and move tests closer to the bitops tests > > > * For functions taking two addresses as an input, test each address i= n a separate function call. > > > * Rename variables for clarity > > > * Add tests for READ_ONCE(), WRITE_ONCE(), smp_load_acquire() and smp= _store_release() > > > > > > I'm still uncelar on which kinds of atomic accesses we should be test= ing > > > though. The patch below only covers a subset, and I don't know if it > > > would be feasible to just manually add all atomics of interest. Which > > > ones would those be exactly? > > > > The atomics wrappers are generated by a script. An exhaustive test > > case would, if generated by hand, be difficult to keep in sync if some > > variants are removed or renamed (although that's probably a relatively > > rare occurrence). > > > > I would probably just cover some of the most common ones that all > > architectures (that support KASAN) provide. I think you are already > > covering some of the most important ones, and I'd just say it's good > > enough for the test. > > > > > As Andrey pointed out on Bugzilla, if we > > > were to include all of the atomic64_* ones, that would make a lot of > > > function calls. > > > > Just include a few atomic64_ cases, similar to the ones you already > > include for atomic_. Although beware that the atomic64_t helpers are > > likely not available on 32-bit architectures, so you need an #ifdef > > CONFIG_64BIT. > > > > Alternatively, there is also atomic_long_t, which (on 64-bit > > architectures) just wraps atomic64_t helpers, and on 32-bit the > > atomic_t ones. I'd probably opt for the atomic_long_t variants, just > > to keep it simpler and get some additional coverage on 32-bit > > architectures. > > If I were to add some atomic_long_* cases, e.g. atomic_long_read() or > atomic_long_write(), in addition to the test cases I already have, wouldn= 't that > mean that on 32-bit architectures we would have the same test case twice = because > atomic_read() and long_atomic_read() both boil down to raw_atomic_read() = and > raw_atomic_write() respectively? Or did I misunderstand and I should only= be > covering long_atomic_* functions whose atomic_* counterpart doesn't exist= in the > test cases already? Sure, on 32-bit this would be a little redundant, but we don't care so much about what underlying atomic is actually executed, but more about the instrumentation being correct. >From a KASAN point of view, I can't really tell that if atomic_read() works that atomic_long_read() also works. On top of that, we don't care all that much about 32-bit architectures anymore (I think KASAN should work on some 32-bit architectures, but I haven't tested that in a long time). ;-)