From: Alexander Lochmann <alexander.lochmann@tu-dortmund.de>
To: tytso@mit.edu, Jan Kara <jack@suse.com>
Cc: Horst Schirmeier <horst.schirmeier@tu-dortmund.de>,
linux-ext4@vger.kernel.org
Subject: [RFC] Fine-grained locking documentation for jbd2 data structures
Date: Thu, 15 Oct 2020 15:56:27 +0200 [thread overview]
Message-ID: <7827d153-f75c-89a2-1890-86e85f86c704@tu-dortmund.de> (raw)
In-Reply-To: <20190408083500.66759-1-alexander.lochmann@tu-dortmund.de>
[-- Attachment #1.1: Type: text/plain, Size: 1709 bytes --]
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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-10-15 13:56 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-08 8:35 [PATCH v3] Updated locking documentation for transaction_t Alexander Lochmann
2019-06-20 20:45 ` Alexander Lochmann
2020-10-15 13:26 ` Alexander Lochmann
2020-12-03 14:04 ` Theodore Y. Ts'o
2020-12-03 14:38 ` Alexander Lochmann
2020-12-03 20:39 ` Theodore Y. Ts'o
2020-10-15 13:56 ` Alexander Lochmann [this message]
2021-02-05 15:31 ` [RFC] Fine-grained locking documentation for jbd2 data structures Alexander Lochmann
2021-02-08 15:27 ` Jan Kara
2021-02-09 9:58 ` Alexander Lochmann
2021-02-09 12:00 ` Jan Kara
2021-02-09 13:47 ` Alexander Lochmann
2021-02-09 16:48 ` Jan Kara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7827d153-f75c-89a2-1890-86e85f86c704@tu-dortmund.de \
--to=alexander.lochmann@tu-dortmund.de \
--cc=horst.schirmeier@tu-dortmund.de \
--cc=jack@suse.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.