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.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=ham 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 4087FCA9EB6 for ; Wed, 23 Oct 2019 12:32:36 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D9A5F21906 for ; Wed, 23 Oct 2019 12:32:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="C5bfrMkM" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D9A5F21906 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 3D5DC6B0003; Wed, 23 Oct 2019 08:32:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 361136B0006; Wed, 23 Oct 2019 08:32:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 225F26B0007; Wed, 23 Oct 2019 08:32:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0216.hostedemail.com [216.40.44.216]) by kanga.kvack.org (Postfix) with ESMTP id EE2F16B0003 for ; Wed, 23 Oct 2019 08:32:34 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id 9502C824999B for ; Wed, 23 Oct 2019 12:32:34 +0000 (UTC) X-FDA: 76074987828.01.leg93_8ad80c3a7a14c X-HE-Tag: leg93_8ad80c3a7a14c X-Filterd-Recvd-Size: 6378 Received: from mail-qk1-f193.google.com (mail-qk1-f193.google.com [209.85.222.193]) by imf06.hostedemail.com (Postfix) with ESMTP for ; Wed, 23 Oct 2019 12:32:33 +0000 (UTC) Received: by mail-qk1-f193.google.com with SMTP id u22so19519618qkk.11 for ; Wed, 23 Oct 2019 05:32:33 -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=B49NIMe9Qp45m4n7j4yBsM/w0U/Y5dSRw5y61/jmg/U=; b=C5bfrMkMZwSNBuaqGvLHQGLvu+WkV3TTh3kdpyy/ob6oFoN9VqPr039NiJ7r8PbBbp i0Ndg1H1PKsVMYNLuBizaGICaR2zwIKJFqesGKj+GHlL+Yo7/uZxSHFBqJi57C5+6WAI yLSx35vCO8IkEpJmYZU0KyQ+UhKSimD8bpgLouFa3SPiviAOlFtIK3olMU0e4mYzxTR6 ri4W3JAkTNY7BOh/AjMrLXlT8nx0TKh2nckATUVkPDUkUMcBXJfpfUlMUYgruercaW4W n/Sm5BbGsBp0U3XPBitQSLz/RMcCyWyqI4R/8ctXEjE0kHygx5YEq/GvmIVT0pEhi0Wm Wq5A== 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=B49NIMe9Qp45m4n7j4yBsM/w0U/Y5dSRw5y61/jmg/U=; b=NWJv2vE1pabzWpGvwz4Gv/ruRStH3/LwbBCE+CCohKKCwspUfyQOSy55U9qQX5PKwP z4I3qWOSU5YwLZN62lHtIn2kVRIY2ZSoDAYCRW6f+s7ryFrfX/Y1lkqsVl4rvekreGGV +rqzPDQenk0ZU6Q84dPGjNTCSCkVcuLHcPXss6KAtyRDB91+NVi7VfVClf+cVepu1DE4 mGALuBMmnbZ8UssJ1mAWFwRxZlBCwT0R0ftbNoGMwRJ4YvlkD5h8O3A1JojaPzrqZjyN tjCMSBPTs70v8bOwnMDnHMDXOST2fnIFDjMrVveq38lKsR3ZPbDDIPZTzYwO62kUX1ba NW0A== X-Gm-Message-State: APjAAAV2Fdsl5dtHmTu08wFS1QudUTKF8dxWhuIuCn8CWPPTMyqwOmJJ bmiGj9o9GnrHSmGsBXATzSkQvx03g6JyYa9LTrxong== X-Google-Smtp-Source: APXvYqyFsU3H6xRYNHrGvBpnk/VOnsx+BN6kQrGuH12Dr1Igjr36aWMR0sDz8pvAXcYyvaIX66eDRdizKnR8UEqoIeQ= X-Received: by 2002:a37:4a87:: with SMTP id x129mr7970246qka.43.1571833952687; Wed, 23 Oct 2019 05:32:32 -0700 (PDT) MIME-Version: 1.0 References: <20191017141305.146193-1-elver@google.com> <20191017141305.146193-2-elver@google.com> In-Reply-To: <20191017141305.146193-2-elver@google.com> From: Dmitry Vyukov Date: Wed, 23 Oct 2019 14:32:20 +0200 Message-ID: Subject: Re: [PATCH v2 1/8] kcsan: Add Kernel Concurrency Sanitizer infrastructure To: Marco Elver Cc: LKMM Maintainers -- Akira Yokosawa , Alan Stern , Alexander Potapenko , Andrea Parri , Andrey Konovalov , Andy Lutomirski , Ard Biesheuvel , Arnd Bergmann , Boqun Feng , Borislav Petkov , Daniel Axtens , Daniel Lustig , Dave Hansen , David Howells , "H. Peter Anvin" , Ingo Molnar , Jade Alglave , Joel Fernandes , Jonathan Corbet , Josh Poimboeuf , Luc Maranget , Mark Rutland , Nicholas Piggin , "Paul E. McKenney" , Peter Zijlstra , Thomas Gleixner , Will Deacon , kasan-dev , linux-arch , "open list:DOCUMENTATION" , linux-efi@vger.kernel.org, "open list:KERNEL BUILD + fi..." , LKML , Linux-MM , "the arch/x86 maintainers" Content-Type: text/plain; charset="UTF-8" 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, Oct 17, 2019 at 4:13 PM Marco Elver wrote: > > Kernel Concurrency Sanitizer (KCSAN) is a dynamic data-race detector for > kernel space. KCSAN is a sampling watchpoint-based data-race detector. > See the included Documentation/dev-tools/kcsan.rst for more details. I think there is some significant potential for improving performance. Currently we have __tsan_read8 do 2 function calls, push/pop, the second call is on unpredicted slow path. Then __kcsan_check_watchpoint and __kcsan_setup_watchpoint do full load of spills and lots of loads and checks that are not strictly necessary or can be avoided. Additionally __kcsan_setup_watchpoint calls non-inlined kcsan_is_atomic. I think we need to try to structure it around the fast path as follows: __tsan_read8 does no function calls and no spills on fast path for both checking existing watchpoints and checking if a new watchpoint need to be setup. If it discovers a race with existing watchpoint or needs to setup a new one, that should be non-inlined tail calls to the corresponding slow paths. In particular, global enable/disable can be replaced with occupying/freeing all watchpoints. Per cpu disabled check should be removed from fast path somehow, it's only used around debugging checks or during reporting. There should be a way to check it on a slower path. user_access_save should be removed from fast path, we needed it only if we setup a watchpoint. But I am not sure why we need it at all, we should not be reading any user addresses. should_watch should be restructured to decrement kcsan_skip first, if it hits zero (with unlikely hint), we go to slow path. The slow path resets kcsan_skip to something random. The comment mentions prandom_u32 is too expensive, do I understand it correctly that you tried to call it on the fast path? I would expect it is fine for slow path and will give us better randomness. At this point we should return from __tsan_read8. To measure performance we could either do some synthetic in-kernel benchmarks (e.g. writing something to the debugfs file, which will do a number of memory accesses in a loop). Or you may try these user-space benchmarks: https://github.com/google/sanitizers/blob/master/address-sanitizer/kernel_buildbot/slave/bench_readv.c https://github.com/google/sanitizers/blob/master/address-sanitizer/kernel_buildbot/slave/bench_pipes.c