lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 5 Feb 2021 16:31:54 +0100
From:   Alexander Lochmann <alexander.lochmann@...dortmund.de>
To:     tytso@....edu, Jan Kara <jack@...e.com>
Cc:     Horst Schirmeier <horst.schirmeier@...dortmund.de>,
        linux-ext4@...r.kernel.org
Subject: Re: [RFC] Fine-grained locking documentation for jbd2 data structures

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

Powered by blists - more mailing lists