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.6 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_PASS,URIBL_BLOCKED,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 0B72FC43387 for ; Fri, 11 Jan 2019 10:49:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C803820872 for ; Fri, 11 Jan 2019 10:49:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="rLukQ8I+" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729482AbfAKKtB (ORCPT ); Fri, 11 Jan 2019 05:49:01 -0500 Received: from mail-it1-f195.google.com ([209.85.166.195]:50807 "EHLO mail-it1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725790AbfAKKtB (ORCPT ); Fri, 11 Jan 2019 05:49:01 -0500 Received: by mail-it1-f195.google.com with SMTP id z7so1756331iti.0 for ; Fri, 11 Jan 2019 02:48:59 -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; bh=bCxrD7V36hAa+pknIiEzAT4nyRtr9eGheePdm61sfKI=; b=rLukQ8I+q5dFR0Rk0j3baA6+EGGCKA11s/zaapiF9a3w7KHonnzgXPKSIesFT7al7d PEZW4kustayb/ylGwaXL9V80Ybc4FaZde6fItjcU6l92lBn5LwvYwoc7Tc1eCBAgzSd/ eXLbr6fhr/IPN07dDNdmVo/SVz4F1GuV9tde+mxnaa7V9wZ097O/y4JnfdbGMAkrSlla BYbC+VgxtzcLpwYYg32hDup849x1yyGuwoeLZ+5knK7wl/zBgl4JkzRFuHF8gR9/QIAc T0YGpPhz4L0+3wJCTBNq0+YMPyYtZwF41Z2fUys85V/cCSVclzmN1RT6KV7RPWwYgwUl 6bPA== 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; bh=bCxrD7V36hAa+pknIiEzAT4nyRtr9eGheePdm61sfKI=; b=JMbNOw/6xrqd666CAi87rYpsP5yeIBpwTrGPeOQWcvLjiWQezph6RZYrrbc8d2EAOp HuXNEohDJ2+Tu6/jbhy2HHyOArCP77hjEiPYbVDLWcSWxUSuT4UMHBoJrMiWcdtR7dvl tyj+zk6hHGpbPF/Nqv1NaY0wnsmVgZFCRzpBtlV9FoUSlVM+h4UAxB3BpQ+TzUu9O/hY Bo7fE3QjW+SKL0aqKVjzaNVxme5/CQqqPbUnmkmAdSL8fNDalpU6AcL50GwbniMX8KqR tl5QxBVxYlFqBNiSuDDZQgHfY0lhVyUpsdrraIM+XlJNqEQj0bBNcNL3zkKLP4dii6TK TPWA== X-Gm-Message-State: AJcUukdzXpHw2YGMzyVFos2R4MPbJTjJeORnc7odR9QVgRGXACClzoHF gygqUJryDc+hhpVJhWVD0tu3UCc7G8khg9Uvb6kucA== X-Google-Smtp-Source: ALg8bN6wadNdbWp1yaEVnQDQDwq++1dtJ2e1oUR/yaL7EdtNbWfYvnLcr4eJzrm/FWlKHxbFHYO1KXfd0dXPt65PpCQ= X-Received: by 2002:a24:6511:: with SMTP id u17mr825720itb.12.1547203738600; Fri, 11 Jan 2019 02:48:58 -0800 (PST) MIME-Version: 1.0 References: <1547201433-10231-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> <04c6d87c-fc26-b994-3b34-947414984abe@i-love.sakura.ne.jp> In-Reply-To: From: Dmitry Vyukov Date: Fri, 11 Jan 2019 11:48:47 +0100 Message-ID: Subject: Re: [PATCH] fs: ratelimit __find_get_block_slow() failure message. To: Tetsuo Handa , Jan Kara , Al Viro , linux-fsdevel 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 Fri, Jan 11, 2019 at 11:40 AM Dmitry Vyukov wrote: > > On Fri, Jan 11, 2019 at 11:28 AM Tetsuo Handa > wrote: > > > > On 2019/01/11 19:19, Dmitry Vyukov wrote: > > >> @@ -200,6 +200,7 @@ void end_buffer_write_sync(struct buffer_head *bh, int uptodate) > > >> struct buffer_head *head; > > >> struct page *page; > > >> int all_mapped = 1; > > >> + static unsigned long last; > > > > > > /\/\/\/\/\/\ > > > > > > We will have to re-fix this when we start testing with KTSAN, data > > > race detector. > > > > What's wrong? This race is harmless. > > How did you arrive to the conclusion that it is harmless? > There is only one relevant standard covering this, which is the C > language standard, and it is very clear on this -- this has Undefined > Behavior, that is the same as, for example, reading/writing random > pointers. > > Check out this on how any race that you might think is benign can be > badly miscompiled and lead to arbitrary program behavior: > https://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong Also there is no other practical definition of data race for automatic data race detectors than: two conflicting non-atomic concurrent accesses. Which this code is. Which means that if we continue writing such code we are not getting data race detection and don't detect thousands of races in kernel code that one may consider more harmful than this one the easy way. And instead will spent large amounts of time to fix some of then the hard way, and leave the rest as just too hard to debug so let the kernel continue crashing from time to time (I believe a portion of currently open syzbot bugs that developers just left as "I don't see how this can happen" are due to such races).