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=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, 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 D355FC43331 for ; Mon, 11 Nov 2019 18:05:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 94E98206C3 for ; Mon, 11 Nov 2019 18:05:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1573495517; bh=D4j7yAa9xAY9us41sVbrmAc7dvEFhURazhNLhVZqnww=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=122w3nF5qDYrMQ1uzjqndllqHzDrvA1geXYhWFzdJC2Xg1yOLH0NfRxFhByIYpZWM eaeKjW05+o1IZBeAujNnMdUkOwgsQTJ4ZFH7Y3L5EYJiyq/JLbaqfp2nLC3Rob+pNS p7UYYtn6MknQeuoiY0kAURs/rqoUpVsNEQYeLc+o= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726879AbfKKSFR (ORCPT ); Mon, 11 Nov 2019 13:05:17 -0500 Received: from mail-lf1-f66.google.com ([209.85.167.66]:43063 "EHLO mail-lf1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726763AbfKKSFR (ORCPT ); Mon, 11 Nov 2019 13:05:17 -0500 Received: by mail-lf1-f66.google.com with SMTP id q5so4569201lfo.10 for ; Mon, 11 Nov 2019 10:05:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NvHuArWQZSt4FAfTL9KeJpBsocvaDQs9zK3jRy53Tcc=; b=ag0ij2l3tpP9oh4bJbAnRGep+63OugvYZJhjMCwlauwgfrGQ7pqUmJvv8qj0uakSts ZDSkRSJFWChbxsuYWUpcogXRNaLW+mnwqdTCozn5LsyQqxp2G8J+ESzbHFLEaLpk8fc1 Wny6vPFLNuEJ1jLedmt1cN279S4odF0GC9reA= 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=NvHuArWQZSt4FAfTL9KeJpBsocvaDQs9zK3jRy53Tcc=; b=FlIjXjPUl55Muq4XKwX1swD207kU7/d+YUqBtrDJ3riuQBZ+F2506Y/eIOtwgynOWr /WZFPK5aAO4Pt6xUcBzhrz0Owu9IMEOXF5NKdRZHYJcfgh7/1S3R9WgrXbC+j2AV0HJ1 PNvY6nFMt4Wf0QRQrvb4e50HUwvnaByYCA9fE8BG+yuvJ4U7T18te+A7qa+7DCRPlv10 ibPy0OhNVFzbd7UuFfamk+XF2WH+MUvBb8bGRlcppyYGusdS1WqgHXtBIXj66unn8OFs OX7yoHoS8DbepBfvjNTLbpjLSsDgvM1xgPIybXEvP84jii83NP31fa96OmshRYB18hBE x04A== X-Gm-Message-State: APjAAAV8TrBrLf85LpGEyH+OBvU3tORqSVfMMwR1aBsgX1U4rdcsbK+Q avoSL1tzQEkt9BsMhRoyhL28Z1xrUz4= X-Google-Smtp-Source: APXvYqw3FzfS5dv+qlk2SIig/a5F0Frx0mdPxH2VUu0ADwega0KDxJYmpzU2pX2DgFKDScaIbgaFrw== X-Received: by 2002:ac2:46d7:: with SMTP id p23mr16194278lfo.104.1573495514487; Mon, 11 Nov 2019 10:05:14 -0800 (PST) Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com. [209.85.167.43]) by smtp.gmail.com with ESMTPSA id p14sm7216505ljc.8.2019.11.11.10.05.11 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Nov 2019 10:05:11 -0800 (PST) Received: by mail-lf1-f43.google.com with SMTP id j14so10583661lfb.8 for ; Mon, 11 Nov 2019 10:05:11 -0800 (PST) X-Received: by 2002:ac2:498a:: with SMTP id f10mr4549583lfl.170.1573495511138; Mon, 11 Nov 2019 10:05:11 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Linus Torvalds Date: Mon, 11 Nov 2019 10:04:54 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: KCSAN: data-race in __alloc_file / __alloc_file To: Eric Dumazet Cc: Alan Stern , Marco Elver , 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, Nov 11, 2019 at 9:52 AM Eric Dumazet wrote: > > Now I wonder what to do with the ~400 KCSAN reports sitting in > pre-moderation queue. So regular KASAN reports are fairly easy to deal with: they report actual bugs. They may be hard to hit, but generally there's no question about something like a use-after-free or whatever. The problem with KCSAN is that it's not clear how many of the reports have been actual real honest-to-goodness bugs that could cause problems, and how many of them are "this isn't actually a bug, but an annotation will shut up KCSAN". My gut feeling would be that it would be best to ignore the ones that are "an annotation will shut up KCSAN", and look at the ones that are real bugs. Is there a pattern to those real bugs? Is there perhaps a way to make KCSAN notice _that_ pattern in particular, and suppress the ones that are "we can shut these up with annotations that don't really change the code"? I think it would be much better for the kernel - and much better for KCSAN - if the problem reports KCSAN reports are real problems that can actually be triggered as problems, and that it behaves much more like KASAN in that respect. Yes, yes, then once the *real* problems have been handled, maybe we can expand the search to be "stylistic issues" and "in theory, this could cause problems with a compiler that did X" issues. But I think the "just annotate" thing makes people more likely to dismiss KCSAN issues, and I don't think it's healthy. Linus