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
| ||
|
Date: Thu, 3 Dec 2020 15:39:15 -0500 From: "Theodore Y. Ts'o" <tytso@....edu> To: Alexander Lochmann <alexander.lochmann@...dortmund.de> Cc: Horst Schirmeier <horst.schirmeier@...dortmund.de>, Jan Kara <jack@...e.com>, linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH v3] Updated locking documentation for transaction_t On Thu, Dec 03, 2020 at 03:38:40PM +0100, Alexander Lochmann wrote: > > > On 03.12.20 15:04, Theodore Y. Ts'o wrote: > > On Thu, Oct 15, 2020 at 03:26:28PM +0200, Alexander Lochmann wrote: > > > Hi folks, > > > > > > I've updated the lock documentation according to our finding for > > > transaction_t. > > > Does this patch look good to you? > > > > I updated the annotations to match with the local usage, e.g: > > > > * When commit was requested [journal_t.j_state_lock] > > > > became: > > > > * When commit was requested [j_state_lock]What do you mean by local usage? > The annotations of other members of transaction_t? Yes, I'd like the annotations of the other objects to be consistent, and just use j_state_lock, j_list_lock, etc., for the other annotations. > Shouldn't the annotation look like this? > [t_journal->j_state_lock] > It would be more precise. It's more precise, but it's also unnecessary in this case, since all of the elements of the journal have a j_ prefix, elements of a transaction_t have a t_ prefix, etc. There is also no other structure element which has a j_state_lock name *other* than in journal_t. Cheers, - Ted
Powered by blists - more mailing lists