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=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS 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 5DB22C43387 for ; Fri, 11 Jan 2019 12:46:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 37D7620872 for ; Fri, 11 Jan 2019 12:46:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731598AbfAKMqo (ORCPT ); Fri, 11 Jan 2019 07:46:44 -0500 Received: from www262.sakura.ne.jp ([202.181.97.72]:47386 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728122AbfAKMqn (ORCPT ); Fri, 11 Jan 2019 07:46:43 -0500 Received: from fsav107.sakura.ne.jp (fsav107.sakura.ne.jp [27.133.134.234]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id x0BCkWcf054428; Fri, 11 Jan 2019 21:46:32 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav107.sakura.ne.jp (F-Secure/fsigk_smtp/530/fsav107.sakura.ne.jp); Fri, 11 Jan 2019 21:46:32 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/530/fsav107.sakura.ne.jp) Received: from [192.168.1.8] (softbank126126163036.bbtec.net [126.126.163.36]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id x0BCkWvQ054422 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NO); Fri, 11 Jan 2019 21:46:32 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Subject: Re: [PATCH] fs: ratelimit __find_get_block_slow() failure message. To: Dmitry Vyukov References: <1547201433-10231-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> <04c6d87c-fc26-b994-3b34-947414984abe@i-love.sakura.ne.jp> Cc: Jan Kara , Al Viro , linux-fsdevel From: Tetsuo Handa Message-ID: <54b68f21-c8b5-7074-74e0-06e3d7ee4003@i-love.sakura.ne.jp> Date: Fri, 11 Jan 2019 21:46:32 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On 2019/01/11 19:48, Dmitry Vyukov wrote: >> 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). > I still cannot catch. Read/write of sizeof(long) bytes at naturally aligned address is atomic, isn't it? I'm not using increments etc. Therefore, in the worst case, some threads see outdated value. But outdated values affect only time_in_range() test, which does not cause severe problems like crash.