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 1DF2FC43331 for ; Mon, 11 Nov 2019 19:00:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EAEF420659 for ; Mon, 11 Nov 2019 19:00:09 +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 S1730207AbfKKTAJ (ORCPT ); Mon, 11 Nov 2019 14:00:09 -0500 Received: from mail-oi1-f193.google.com ([209.85.167.193]:38428 "EHLO mail-oi1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729568AbfKKTAD (ORCPT ); Mon, 11 Nov 2019 14:00:03 -0500 Received: by mail-oi1-f193.google.com with SMTP id a14so12441308oid.5 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=Xa94xmyENAyoOa9lHifA4GeBi3VvWNdNmAlnug4Ds5Se7crI5TGRij9lVxrA7V8mPw r/nR5qY6+8ciYLJNwuJmIgNIIZFEAFeJEkRITPj3jL8kiAe977Gndl3SPk7ZhJnG7R2A ja0gFP341qndZcPKabLr29sBTi3Q+gd+ip8ExGROMsCeg467U6sTvT8G7NdQ5f4zvqfY FuT2FzQB1qXaec+z8JgUg7zHOMW1XU41BeN3SjVCEgTqFQH9rMaP4/6ct/G/5HADThI6 cd4wSma3kWeYo0qIaZ7qtmk6N8/qnMoYbI614ak23rdh+5iHDGFri7LW39J9lcE4LXQa lVeA== X-Gm-Message-State: APjAAAW7AlFfBiHj1SBr0hhj/PPr6s/+IwdvKJHe5hfLKrEssKwy1jPz HrVOCNjJ2o6h4dijMkMorEAcgt5FPHS/deSADgtueA== 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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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