Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2199830yba; Sun, 7 Apr 2019 11:29:29 -0700 (PDT) X-Google-Smtp-Source: APXvYqxru6NZNl7j3CdPgJHiN2EpWpbtcqlIMqS7zp7cBacQssY5Y3UFTKGentWlc8RYufZknaB6 X-Received: by 2002:a17:902:4681:: with SMTP id p1mr25613674pld.42.1554661769294; Sun, 07 Apr 2019 11:29:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554661769; cv=none; d=google.com; s=arc-20160816; b=G7bTn+yzRyYtexvCmlrIlaphlt4C6j71trg2VLcW0lAgxpksrz7f0LDyfR2sHgjSaG TndOkG/BPMJaYnAlQ1DF679BXm4jn2173t5G0xzyTPjuoNRHi3BYLs6BC4Pq/+dMs8XU SGGjgDT6DOSngU4jU+P42hmakgBT1VY+cUi1DJm9ktG/jCtxXh9LbntV/WUR30wxPcAm u2kZPkKERffGqG3FbslmSu0MjG+mfwaaMvAFNtjiwkqh7JOcntAgKeVVunjllmjYD/FQ NQ9s0iOsLpaB9/mnPEUeH70dUBPk2kbcAv6+nJyZh29ZP9mHpNpujuJXXgLWCLZkcRGc hTcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:mail-followup-to :message-id:subject:cc:to:from:date; bh=t43oCHSdpJMc208gJhRCG3FhBzC7j4929ADQGQeViVs=; b=dtKIJeuQ4ZZ9Wvw6qd7LXrjU8nde5eh/32pNolVDx6utf0LeB71ECT4lAC5vKkggts EUh5S46EU0sv8ZmdHo1C7cxeGy8MI5lXCRthcGPirC0ckZrzLw835OtP+mCtMInZCdF2 FuiTeWY0vEYwfW9pNkzs9U2L9Xg1tYyBP2KD6/vf8/oElqwKGuhiexhHQXkkDZiqT+H3 RpiQ+KXnIl1faq9c8RCDLrEns6jFF3C9/2yjnGd59JdbbPxzUE5FboNXcRV7cWJSk7zj umb8IVuZuvv0hWsCCUCFBfkCC5EGQzqjiWHPbD+WSaTL8YUo+aMHB0DdOjVleNYif4+H F1AQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f11si23980338pgf.406.2019.04.07.11.29.13; Sun, 07 Apr 2019 11:29:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726510AbfDGS0j (ORCPT + 99 others); Sun, 7 Apr 2019 14:26:39 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:44662 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726362AbfDGS0j (ORCPT ); Sun, 7 Apr 2019 14:26:39 -0400 Received: from callcc.thunk.org (177.sub-174-222-154.myvzw.com [174.222.154.177]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x37IQPcg012621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 7 Apr 2019 14:26:29 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id F166C421A0D; Sun, 7 Apr 2019 12:52:06 -0400 (EDT) Date: Sun, 7 Apr 2019 12:52:06 -0400 From: "Theodore Ts'o" To: Alexander Lochmann Cc: Horst Schirmeier , Jan Kara , linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [v2] Updated locking documentation for transaction_t Message-ID: <20190407165206.GA11370@mit.edu> Mail-Followup-To: Theodore Ts'o , Alexander Lochmann , Horst Schirmeier , Jan Kara , linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org References: <20190318184237.20677-1-alexander.lochmann@tu-dortmund.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190318184237.20677-1-alexander.lochmann@tu-dortmund.de> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 18, 2019 at 07:42:37PM +0100, Alexander Lochmann wrote: > /*t > - * Where in the log does this transaction's commit start? [no locking] > + * Where in the log does this transaction's commit start? > + * [journal_t.j_state_lock] > */ > unsigned long t_log_start; Well, technically, that's not quite right. It's only assigned in one location, and we hold j_state_lock, yes. But that's because we need to access journal->j_head. At the point where we set t_log_start, the transaction has already been locked down (transaction->t_state > T_LOCKED). Similarly, we happen to be holding j_state where it is currently being accessed, but it's not because we needed the lock in order to access t_log_start safely. > /* > - * When transaction started > + * When transaction started [journal_t.j_state_lock] > */ > unsigned long t_start; And again, not really. The primary place where t_start is set is when the transaction is firstt created, before it's visible anywhere else. after that, it is used exclusively by the commit thread, and so no locking is necessary. It's true that in the places where it is used, j_state_lock happens to be taken, but it's strictly not necessary. > > /* > - * When commit was requested > + * When commit was requested [journal_t.j_state_lock] > */ > unsigned long t_requested; Yes, that appears to be correct. > > /* > - * Checkpointing stats [j_checkpoint_sem] > + * Checkpointing stats [journal_t.j_list_lock] > */ > struct transaction_chp_stats_s t_chp_stats; > This appears to be correct. - Ted