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
Attachment:
signature.asc
Description: OpenPGP digital signature