Hi developers,
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.
In contrast to that, the insert and remove operations to any of these
lists are protected by that lock.
Can you please tell me why that lock is not used at line 464 and 561?
Thanks in advance!
Regards,
Alex
--
Technische Universität Dortmund
Alexander Lochmann PGP key: 0xBC3EF6FD
Otto-Hahn-Str. 16 phone: +49.231.7556141
D-44227 Dortmund fax: +49.231.7556116
http://ess.cs.tu-dortmund.de/Staff/al
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 <[email protected]>
SUSE Labs, CR