Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp453544pxf; Thu, 11 Mar 2021 07:31:40 -0800 (PST) X-Google-Smtp-Source: ABdhPJzDJ3lwqZaGaTkyk3syqumtz+C//MHrBcFzoea2PYSyokAuCgn2VHyKTrCzpwI7N0Z3vbGC X-Received: by 2002:a50:82c5:: with SMTP id 63mr9001126edg.97.1615476700455; Thu, 11 Mar 2021 07:31:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615476700; cv=none; d=google.com; s=arc-20160816; b=OJAhOQiYF5NT7UkUMtq2WVZQtppC/bhTziWGz8tydKU4RUgR2TUM4YOkR+CZwgcAwS VH9gbeTJ6vbYCbqKIoNb+Oo1d0nJOfiaRQKFAtebY6j+BNl67JXusB32aO96VWL49wDW Zn3qF1xS5ypQjakM6xbbkcdR6kgwrG0jAbmrDUOSjEDtYPnhvx2KBAHElb1fGROUhAuq dR1dWyxmAR77iFkZBjY6uPZzQXruV5iArmZ4gI3sSxFXZGmcLYjISG+kZ49QxJQZNvsQ v7m7eYR+mtQCGX0u34RIupUVls+1acDFsRWXtQstUlz+adXlxvS59IwaCu6H7Y/A3gVs VKNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=82ny4N3uDgTOJXfrKvcYqBDkPm49otSU2ZYoaQARg+k=; b=TqjYFzsxBSJCv6wPbv843dUsNv8aIS4CVb/Xz/m6JoUJWL90LL6u+37i7hZ1WS9XRX lXOK5EFYvmbSnavRZrCs/aOznbROm8YnDRk6GX61HdwIj2PfvFjQwtFPgO+KXuAj5XHN aohcpMJAaCToP8UC1m6VPf+amXp4j66lKb6ZxbX+7uOZMdXznsqdq3q1bOHwvBB/kwm0 uPYtM5kpLLooD2cO0pbigCyWxgBtVHL54WquWV7ZVQPhFNecY8Lr5IWF8G3x5fem3jmD qmnv2w50RHXGxnMbQWqQPXZbTJ8mQVbH11R+gBI2ggoctvW+Y2lBYFfweOoRbqCdFQNz LjKg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id zn8si1847023ejb.621.2021.03.11.07.31.14; Thu, 11 Mar 2021 07:31:40 -0800 (PST) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234089AbhCKPam (ORCPT + 99 others); Thu, 11 Mar 2021 10:30:42 -0500 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:45146 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S234121AbhCKPaW (ORCPT ); Thu, 11 Mar 2021 10:30:22 -0500 Received: from cwcc.thunk.org (pool-72-74-133-215.bstnma.fios.verizon.net [72.74.133.215]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 12BFU9qp025815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Mar 2021 10:30:09 -0500 Received: by cwcc.thunk.org (Postfix, from userid 15806) id 3FF5615C3AA0; Thu, 11 Mar 2021 10:30:09 -0500 (EST) Date: Thu, 11 Mar 2021 10:30:09 -0500 From: "Theodore Ts'o" To: Marco Elver Cc: Dmitry Vyukov , Jan Kara , Tetsuo Handa , syzbot , Jan Kara , linux-ext4@vger.kernel.org, LKML , syzkaller-bugs Subject: Re: [syzbot] KCSAN: data-race in start_this_handle / start_this_handle Message-ID: References: <0000000000008de88005bd40ac36@google.com> <20210311142503.GA31816@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Thu, Mar 11, 2021 at 04:08:30PM +0100, Marco Elver wrote: > If the outcome of the check does not affect correctness and the code is > entirely fault tolerant to the precise value being read, then a > data_race(!journal->j_running_transaction) marking here would be fine. So a very common coding pattern is to check a value w/o the lock, and if it looks like we might need to check *with* a lock, we'll grab the lock and recheck. Does KCSAN understand that this sort of thing is safe automatically? In thie particular case, it's a bit more complicated than that; we're checking a value, and then allocating memory, grabbing the spin lock, and then re-checking the value, so we don't have to drop the spinlock, allocate the memory, grab the lock again, and then rechecking the value. So even if KCSAN catches the simpler case as described above, we still might need to explicitly mark the data_race explicitly. But the more we could have the compiler automatically figure out things without needing an explicit tag, it would seem to me that this would be better, since manual tagging is going to be more error-prone. Cheers, - Ted