Re: [RFC] Fine-grained locking documentation for jbd2 data structures

[Alexander Lochmann <alexander.lochmann@tu-dortmund.de>]

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