Hi Ted, hi Jack, have you had the chance to review our results? Cheers, Alex On 15.10.20 15:56, Alexander Lochmann wrote: > Hi folks, > > when comparing our generated locking documentation with the current > documentation > located in include/linux/jbd2.h, I found some inconsistencies. (Our > approach: https://dl.acm.org/doi/10.1145/3302424.3303948) > According to the official documentation, the following members should be > read using a lock: > journal_t > - j_flags: j_state_lock > - j_barrier_count: j_state_lock > - j_running_transaction: j_state_lock > - j_commit_sequence: j_state_lock > - j_commit_request: j_state_lock > transactiont_t > - t_nr_buffers: j_list_lock > - t_buffers: j_list_lock > - t_reserved_list: j_list_lock > - t_shadow_list: j_list_lock > jbd2_inode > - i_transaction: j_list_lock > - i_next_transaction: j_list_lock > - i_flags: j_list_lock > - i_dirty_start: j_list_lock > - i_dirty_start: j_list_lock > > However, our results say that no locks are needed at all for *reading* > those members. > From what I know, it is common wisdom that word-sized data types can be > read without any lock in the Linux kernel. > All of the above members have word size, i.e., int, long, or ptr. > Is it therefore safe to split the locking documentation as follows? > @j_flags: General journaling state flags [r:nolocks, w:j_state_lock] > > The following members are not word-sizes. Our results also suggest that > no locks are needed. > Can the proposed change be applied to them as well? > transaction_t > - t_chp_stats: j_checkpoint_sem > jbd2_inode: > - i_list: j_list_lock > > Cheers, > 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
