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 X-Spam-Level: X-Spam-Status: No, score=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_RED,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 90A9DC433ED for ; Mon, 10 May 2021 17:16:49 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2EEAC6121E for ; Mon, 10 May 2021 17:16:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2EEAC6121E Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 9C07C6B006E; Mon, 10 May 2021 13:16:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9703A6B0071; Mon, 10 May 2021 13:16:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7E9B76B0072; Mon, 10 May 2021 13:16:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0152.hostedemail.com [216.40.44.152]) by kanga.kvack.org (Postfix) with ESMTP id 626146B006E for ; Mon, 10 May 2021 13:16:48 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 20EC982499A8 for ; Mon, 10 May 2021 17:16:48 +0000 (UTC) X-FDA: 78125976096.26.791A672 Received: from mail-yb1-f181.google.com (mail-yb1-f181.google.com [209.85.219.181]) by imf14.hostedemail.com (Postfix) with ESMTP id 00F74C001C60 for ; Mon, 10 May 2021 17:16:23 +0000 (UTC) Received: by mail-yb1-f181.google.com with SMTP id y2so22600458ybq.13 for ; Mon, 10 May 2021 10:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PpOkt0ElCphGo2kwCiXD7cgewiK52gxKiOZlKtvjMsM=; b=NScMccGGbdnt2x0pRivH/YyoIpsom5IGF+Cczk/qMObXl1jX1R3FKiAHPisPSC/g2d LstDx3W5FCb0FQTZJNuv/jWHDl7LzSzZZusccfblbBVQm8e3SO4/6T3ai/AuEMUI7oBA gwztu66tpd1gdBuYpWYIBvo/SOWHOpQjEsoOkkkMcUY4fekxJqATdxTAmbNfXAc167DC bjCDB68VJiy9xEeOf+TEFa1omo9XIwhnr4aPCzJGXHZL6hIS7+NJt4idKV6LsaGBjpLc QA8fhnIsG3rjM7Za3tXg9n1DiyIM+Xu2dczcg0n6Y6L4KbVo2bzBGdJhHsa48zzg+muy 2q3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PpOkt0ElCphGo2kwCiXD7cgewiK52gxKiOZlKtvjMsM=; b=dX7IR2TnFnfNBYcuKuJLus4Ln0nOaK5MoGMPlD4F5wxZYwlaVFXGZzJjp77fKINo1X lUt4AnNtaPt+0f6jTOvEZ1JnOyZhA0rDCMCTAJjfuYl+3bhvquXX+lR8c3OpYp7wcEM6 E6qmI70Z0be13pEnjn22D2MV0f7MKlsmTHeIY7QGtzJtUzL/K55BUN6T7F6/FrjyfPp4 8l66PSiRYEPujW0ACUHIk5hfd/RNU6nd4OKJBQhwtKkpf7IuerN84BXt4qJqPHOA5nCV Dfg5/711OeXP90PAtyaZm4g4fdO5XrtEhLkm4zZduuK7M8KQ5HM4W6DHPo27kT7+rUa4 XCuA== X-Gm-Message-State: AOAM533I6zih3MjZZ0q58U6G3Pku69dOCPb8sDi+K1K6XhKgehjEnQtR CksQPuTLsMs/RADrWCbm1SGARpghOprevw/WUgPTWw== X-Google-Smtp-Source: ABdhPJyeQ92c3lR8Dg9fGvXXku3eqm0RAwwB+GSccJZTMx5U4cv+3hhjp/bWKHTiEd55C4FyD2A/CsTGsA1qbF0dV/g= X-Received: by 2002:a25:2d64:: with SMTP id s36mr35311357ybe.412.1620667006738; Mon, 10 May 2021 10:16:46 -0700 (PDT) MIME-Version: 1.0 References: <20210506212025.815380-1-pcc@google.com> <20210508173009.781b8a401fefc2ab71cb3907@linux-foundation.org> In-Reply-To: <20210508173009.781b8a401fefc2ab71cb3907@linux-foundation.org> From: Peter Collingbourne Date: Mon, 10 May 2021 10:16:37 -0700 Message-ID: Subject: Re: [PATCH] kasan: fix unit tests with CONFIG_UBSAN_LOCAL_BOUNDS enabled To: Andrew Morton Cc: Andrey Konovalov , Alexander Potapenko , George Popescu , Elena Petrova , Evgenii Stepanov , Linux Memory Management List , stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=NScMccGG; spf=pass (imf14.hostedemail.com: domain of pcc@google.com designates 209.85.219.181 as permitted sender) smtp.mailfrom=pcc@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 00F74C001C60 X-Stat-Signature: zsnz7j6ua4daqf1iipp9wjwq6ym4o3cu Received-SPF: none (google.com>: No applicable sender policy available) receiver=imf14; identity=mailfrom; envelope-from=""; helo=mail-yb1-f181.google.com; client-ip=209.85.219.181 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1620666983-127598 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: On Sat, May 8, 2021 at 5:30 PM Andrew Morton wrote: > > On Thu, 6 May 2021 14:20:25 -0700 Peter Collingbourne wrote: > > > These tests deliberately access these arrays out of bounds, > > which will cause the dynamic local bounds checks inserted by > > CONFIG_UBSAN_LOCAL_BOUNDS to fail and panic the kernel. To avoid this > > problem, access the arrays via volatile pointers, which will prevent > > the compiler from being able to determine the array bounds. > > Huh. Is this use of volatile the official way of suppressing the > generation of the checking code or is it just something which happened > to work? I'm wondering if this workaround should be formalized in some > fashion (presumably a wrapper) rather than mysteriously and > unexplainedly open-coding it like this. I would consider it the official way in the sense that the compiler must assume that the pointer that it loads from the address of "array" has an arbitrary value due to the volatile qualifier, and the array bounds stuff follows from that. Actually I don't think the compiler is powerful enough yet to look through the store and load of "array", but if it were, I think that would be the right way to suppress the analysis. Is the comment that I added in v2 not enough here? Peter