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=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,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 AF5ABC17441 for ; Mon, 11 Nov 2019 19:00:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 872AB20659 for ; Mon, 11 Nov 2019 19:00:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="RVbyU4ES" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726845AbfKKTAE (ORCPT ); Mon, 11 Nov 2019 14:00:04 -0500 Received: from mail-oi1-f193.google.com ([209.85.167.193]:40380 "EHLO mail-oi1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729538AbfKKTAE (ORCPT ); Mon, 11 Nov 2019 14:00:04 -0500 Received: by mail-oi1-f193.google.com with SMTP id 22so12442499oip.7 for ; Mon, 11 Nov 2019 11:00:03 -0800 (PST) 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=Hij9WRW9jexaTExPnUz0qaTqt1chIxl/l165TeSCuFk=; b=RVbyU4ESVWlXQ8T3vJoN/oZeBZzpoGo5ihXG901x+xkoVGygn+QUOW8Q+wh00/DvOP giok/SgrwR70kYfkO45hsvOAP+WhHiPqYwDj0dHHMkve8fY461e4iJtlRNi7eR1DhAnr msvmqz3cgRr9WTZZh2vG1SNXT9gxsC4kYzoWV5sLY5uoS7y7h9f1x7peNvMd98iVG6e6 HxL1ITDDClLoV1YB9+VYGF7sapY8UPo3CA5UJHCfPI+qLRQi3yfO44XttBTSfdrQ6EaD 7jEOcmSiHHrw/5DNMhwm1YzJ+xQTSjO1kZJk+T45B0zkAzCPjVfZEJtuP1V0O9Lh2wbP Pj6A== 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=Hij9WRW9jexaTExPnUz0qaTqt1chIxl/l165TeSCuFk=; b=EUYgyTuE/uQOes2OBJ3rE/XsRbK7ljaZCrP5/AIq7ah1sU7MDOjMW/UWSK0wGk3bz8 A6Srh4Rh4TfqUANIxWnsFb1H6HxUhpH4sOjW0XWj9ctR2PSxKf6zCchcX73Wapsp2geZ yu60tlxPBhh3B+sJcoR0yDx6rHhRF1Mqi7avzRP8RjlyB8X5oP37qw/JccweUPtRIXLk 2Cmkeiq+ts/DyU9+7vD2Ly0scP3vAIofuwyqeSxtix2GuZAuqI++45XC9oriKR3Jj0Bk iLm01is3D6gZHPxmNoAoYL7n0Hkr30QkxRLlV2Kci5FffOA7fEMDDSKzqaK2lnQZsIyX WTdA== X-Gm-Message-State: APjAAAUoaAypiTtdNqER/wjLsDw+Ao9ma9cca511eF/Unf9dcNRmPmYr cv6BomWFIhLsOaV/u38URBBMOYedJxc1RDa45Mk+Rw== X-Google-Smtp-Source: APXvYqwuLe2W6zNidCS4fhh7tulT13NX4MB6+vyTZa/nE+xFjVDnEnM6AgSgW+nAjTQsXtyrboaM6eqO5Q/xA8t81gM= X-Received: by 2002:aca:5413:: with SMTP id i19mr388074oib.121.1573498802654; Mon, 11 Nov 2019 11:00:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Marco Elver Date: Mon, 11 Nov 2019 19:59:50 +0100 Message-ID: Subject: Re: KCSAN: data-race in __alloc_file / __alloc_file To: Linus Torvalds Cc: Eric Dumazet , Alan Stern , Eric Dumazet , syzbot , linux-fsdevel , Linux Kernel Mailing List , syzkaller-bugs , Al Viro , Andrea Parri , "Paul E. McKenney" , LKMM Maintainers -- Akira Yokosawa Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Mon, 11 Nov 2019 at 19:50, Linus Torvalds wrote: > > On Mon, Nov 11, 2019 at 10:31 AM Eric Dumazet wrote: > > > > Problem is that KASAN/KCSAN stops as soon as one issue is hit, > > regardless of it being a false positive or not. > > So mayb e that - together with the known huge base of false positives > - just means that KCSAN needs some more work before it can be used as > a basis for sending out patches. > > Maybe the reporting needs to create a hash of the location, and report > once per location? Or something like that. > > Maybe KCSAN needs a way to filter out known false positives on a KCSAN > side, without having to change the source for a tool that gives too > much noise? > > > If we do not annotate the false positive, the real issues might be > > hidden for years. > > I don't think "change the kernel source for a tool that isn't good > enough" is the solution. > > > There is no pattern really, only a lot of noise (small ' bugs' that > > have no real impact) > > Yeah, if it hasn't shown any real bugs so far, that just strengthens > the "it needs much fewer false positives to be useful". > > KASAN and lockdep can afford to stop after the first problem, because > the problems they report - and the additional annotations you might > want to add - are quality problems and annotations. There is a fundamental limitation here. As I understand, in an ideal world we'd only find true logic bugs, *race conditions*, first, and *data races* later. Some data races are also race conditions, which a tool like KCSAN can report. However, not all race conditions are data races and vice-versa. The intent is to report data races according to the LKMM. KCSAN currently does that. On syzbot, we do not even report all data races because we use a very conservative config, to filter things like data races between plain and ONCE/atomic accesses, etc. A data race detector can only work at the memory model/language level. Deeper analysis, to find only race conditions, requires conveying the intended logic and patterns to a tool. This requires 1) the developer either writing a spec or model of their code, and then 2) the tool verifying that the implementation matches. People have done this for small bits of code using model checkers (and other formal methods), but this just doesn't scale! KCSAN finds real problems today. Maybe not all of them are race conditions, but they are data races. We already have several options to filter data races, and will keep adding more. However, a tool that magically proves that there are no concurrency related logic bugs is an entirely different beast. Thanks, -- Marco