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.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable 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 B3D0DC5ACD6 for ; Wed, 18 Mar 2020 08:51:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 566E82076D for ; Wed, 18 Mar 2020 08:51:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 566E82076D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B4FF56B000A; Wed, 18 Mar 2020 04:51:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AD9206B000C; Wed, 18 Mar 2020 04:51:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9C7EF6B000D; Wed, 18 Mar 2020 04:51:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0206.hostedemail.com [216.40.44.206]) by kanga.kvack.org (Postfix) with ESMTP id 80F186B000A for ; Wed, 18 Mar 2020 04:51:10 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 5C25A180AD81D for ; Wed, 18 Mar 2020 08:51:10 +0000 (UTC) X-FDA: 76607863500.05.front08_4462e40c95c51 X-HE-Tag: front08_4462e40c95c51 X-Filterd-Recvd-Size: 2682 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf26.hostedemail.com (Postfix) with ESMTP for ; Wed, 18 Mar 2020 08:51:09 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D166131B; Wed, 18 Mar 2020 01:51:08 -0700 (PDT) Received: from mbp (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 079D03F52E; Wed, 18 Mar 2020 01:51:07 -0700 (PDT) Date: Wed, 18 Mar 2020 08:51:05 +0000 From: Catalin Marinas To: Qian Cai Cc: akpm@linux-foundation.org, elver@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/kmemleak: silence KCSAN splats in checksum Message-ID: <20200318085105.GQ3005@mbp> References: <20200317182754.2180-1-cai@lca.pw> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200317182754.2180-1-cai@lca.pw> User-Agent: Mutt/1.10.1 (2018-07-13) 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 Tue, Mar 17, 2020 at 02:27:54PM -0400, Qian Cai wrote: > Even if KCSAN is disabled for kmemleak, update_checksum() could still > call crc32() (which is outside of kmemleak.c) to dereference > object->pointer. Thus, the value of object->pointer could be accessed > concurrently as noticed by KCSAN, > > BUG: KCSAN: data-race in crc32_le_base / do_raw_spin_lock > > write to 0xffffb0ea683a7d50 of 4 bytes by task 23575 on cpu 12: > do_raw_spin_lock+0x114/0x200 > debug_spin_lock_after at kernel/locking/spinlock_debug.c:91 > (inlined by) do_raw_spin_lock at kernel/locking/spinlock_debug.c:115 > _raw_spin_lock+0x40/0x50 > __handle_mm_fault+0xa9e/0xd00 > handle_mm_fault+0xfc/0x2f0 > do_page_fault+0x263/0x6f9 > page_fault+0x34/0x40 > > read to 0xffffb0ea683a7d50 of 4 bytes by task 839 on cpu 60: > crc32_le_base+0x67/0x350 > crc32_le_base+0x67/0x350: > crc32_body at lib/crc32.c:106 > (inlined by) crc32_le_generic at lib/crc32.c:179 > (inlined by) crc32_le at lib/crc32.c:197 > kmemleak_scan+0x528/0xd90 > update_checksum at mm/kmemleak.c:1172 > (inlined by) kmemleak_scan at mm/kmemleak.c:1497 > kmemleak_scan_thread+0xcc/0xfa > kthread+0x1e0/0x200 > ret_from_fork+0x27/0x50 > > If a shattered value was returned due to a data race, it will be > corrected in the next scan. Thus, let KCSAN ignore all reads in the > region to silence KCSAN in case the write side is non-atomic. > > Suggested-by: Marco Elver > Signed-off-by: Qian Cai Acked-by: Catalin Marinas