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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS 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 217B2C433ED for ; Sun, 9 May 2021 00:30:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 791B261157 for ; Sun, 9 May 2021 00:30:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 791B261157 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id AF9376B0071; Sat, 8 May 2021 20:30:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AA7F96B0073; Sat, 8 May 2021 20:30:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 96EE66B0074; Sat, 8 May 2021 20:30:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0225.hostedemail.com [216.40.44.225]) by kanga.kvack.org (Postfix) with ESMTP id 7776B6B0071 for ; Sat, 8 May 2021 20:30:13 -0400 (EDT) Received: from smtpin39.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 97FB2A759 for ; Sun, 9 May 2021 00:30:11 +0000 (UTC) X-FDA: 78119810622.39.A4C41C6 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf17.hostedemail.com (Postfix) with ESMTP id 3DEEE40002D6 for ; Sun, 9 May 2021 00:30:06 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id EF3FC6108B; Sun, 9 May 2021 00:30:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1620520210; bh=c5rUftDWSwnr3jESMzj+4uzHzyLwnacoQCDOZWGMj+E=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=CL3Pk8Qd3dvcw9eux0aYiqw53B6Q4DuK2/NCRmp+F+PkjUs+nRAXky3kLXLqX17HU pHEk0FawoTvXSVF8xADuR+KEHlQ5eAFlOAV6wB11S3uGoEbemSGacsSgNiPO0Y4d1T Y9gRld4EnGp1p83hRA28EYqKyYfDV0Vw+CxorWMw= Date: Sat, 8 May 2021 17:30:09 -0700 From: Andrew Morton To: Peter Collingbourne Cc: Andrey Konovalov , Alexander Potapenko , George Popescu , Elena Petrova , Evgenii Stepanov , linux-mm@kvack.org, stable@vger.kernel.org Subject: Re: [PATCH] kasan: fix unit tests with CONFIG_UBSAN_LOCAL_BOUNDS enabled Message-Id: <20210508173009.781b8a401fefc2ab71cb3907@linux-foundation.org> In-Reply-To: <20210506212025.815380-1-pcc@google.com> References: <20210506212025.815380-1-pcc@google.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=CL3Pk8Qd; dmarc=none; spf=pass (imf17.hostedemail.com: domain of akpm@linux-foundation.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org X-Stat-Signature: nzoazhm38t5wzwwy7fwwb145hd1tgc8z X-Rspamd-Queue-Id: 3DEEE40002D6 X-Rspamd-Server: rspam05 Received-SPF: none (linux-foundation.org>: No applicable sender policy available) receiver=imf17; identity=mailfrom; envelope-from=""; helo=mail.kernel.org; client-ip=198.145.29.99 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1620520206-958557 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 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.