On Fri 26-03-21 09:18:45, Alexander Lochmann wrote: > 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? Yes, that is 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. Yes, commit phase is implemented by jbd2_journal_commit_transaction() and the functions it calls. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
