linux-ext4 - Re: [QUESTION] Locking for the transaction buffers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20180104162108.GD2170@quack2.suse.cz>
Date:   Thu, 4 Jan 2018 17:21:08 +0100
From:   Jan Kara <jack@...e.cz>
To:     Alexander Lochmann <alexander.lochmann@...dortmund.de>
Cc:     linux-ext4@...r.kernel.org,
        Horst Schirmeier <horst.schirmeier@...dortmund.de>
Subject: Re: [QUESTION] Locking for the transaction buffers

Hi,

On Mon 18-12-17 18:08:34, Alexander Lochmann wrote:
> I'm studying the locking in the JBD2 subsystem (v4.15-rc4). Doing so, I
> came across the jbd2_journal_commit_transaction function
> where severals lists, e.g., t_forget or t_buffers, are flushed in a
> while loop.
> According to the documentation in inlcude/linux/jbd2.h, the j_list_lock
> lock is the appropriate lock.
> However, it is only used in one out of three cases:
> In fs/jbd2/commit.c:903, the while loop is protected using the
> j_list_lock lock. Whereas it is not used at line 464 and 561.

We are in a situation where all updates to the transaction have finished
and we are starting to commit the transaction. In such situation nobody
should be touching transaction's t_reserved_list or t_buffers_list. OTOH
transaction's t_forget list can still be modified as buffers can be
attached to that list even while transaction is committing (usually those
are buffers that can be discarded once the transaction commits).

> In contrast to that, the insert and remove operations to any of these
> lists are protected by that lock.

Yes, they need to serialize against each other.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR