On 11.02.21 10:30, Jan Kara wrote: >> diff --git a/include/linux/jbd2.h b/include/linux/jbd2.h >> index 99d3cd051ac3..18f77d9b1745 100644 >> --- a/include/linux/jbd2.h >> +++ b/include/linux/jbd2.h >> @@ -594,18 +594,18 @@ struct transaction_s >> */ >> unsigned long t_log_start; >> >> - /* Number of buffers on the t_buffers list [j_list_lock] */ >> + /* Number of buffers on the t_buffers list [j_list_lock, no lock for >> quick racy checks] */ >> int t_nr_buffers; > > So this case is actually somewhat different now that I audited the uses. > There are two types of users - commit code (fs/jbd2/commit.c) and others. > Other users properly use j_list_lock to access t_nr_buffers. Commit code > does not use any locks because committing transaction is fully in > ownership of the jbd2 thread and all other users need to check & wait for > commit to be finished before doing anything with the transaction's buffers.
I'm still trying understand how thinks work: Accesses to transaction_t might occur from different contexts. Thus, locks are necessary. If it comes to the commit phase, every other context has to wait until jbd2 thread has done its work. Therefore, jbd2 thread does not need any locks to access a transaction_t (or just parts of it?) during commit phase. Is that correct? If so: I was thinking whether it make sense to ignore all memory accesses to a transaction_t (or parts of it) that happen in the commit phase. They deliberately ignore the locking policy, and would confuse our approach. Is the commit phase performed by jbd2_journal_commit_transaction()? We would add this function to our blacklist for transaction_t. - 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
