On Thu 11-02-21 10:53:51, Alexander Lochmann wrote: > > > On 11.02.21 10:30, Jan Kara wrote: > > > */ > > > 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. > Mhm I see. > What about '[..., no locks needed for jbd2 thread]'? Sounds good to me. > How do the others wait for the commit to be finished? Well, usually they just don't touch buffers belonging to the committing transation, they just store in b_next_transaction that after commit is done, buffer should be added to the currently running transaction. There are some exceptions though - e.g. jbd2_journal_invalidatepage() (called from truncate code) which returns EBUSY in some rare cases and we use jbd2_log_wait_commit() in ext4_wait_for_tail_page_commit() to wait for commit to be done before we know it is safe to destroy the buffer. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
