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  linux-cve-announce  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]
Message-ID: <Pine.LNX.4.44L0.1809041503470.17060-100000@netrider.rowland.org>
Date:   Tue, 4 Sep 2018 15:09:49 -0400 (EDT)
From:   Alan Stern <stern@...land.harvard.edu>
To:     Andrea Parri <andrea.parri@...rulasolutions.com>
cc:     Will Deacon <will.deacon@....com>,
        "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
        <linux-kernel@...r.kernel.org>, <linux-arch@...r.kernel.org>,
        <mingo@...nel.org>, <peterz@...radead.org>, <boqun.feng@...il.com>,
        <npiggin@...il.com>, <dhowells@...hat.com>, <j.alglave@....ac.uk>,
        <luc.maranget@...ia.fr>, <akiyks@...il.com>
Subject: Re: [PATCH RFC LKMM 1/7] tools/memory-model: Add extra ordering for
 locks and remove it for ordinary release/acquire

On Tue, 4 Sep 2018, Andrea Parri wrote:
> Heh, your confusion might be the reflection of mine... ;-)  That was
> indeed a long and not conclusive discussion (meaning there're pending
> issues); and I cannot claim to find "arguments" such as:
> 
>   "More than one kernel developer has expressed the opinion that
>    the LKMM should enforce ordering of writes by locking."
> 
> particularly helpful (I do tend to be convinced by arguments rather
> than by opinions).  In fact, you can take the following as my only
> current "constructive argument" against the patch [1,2]:
> 
>   THE COMMIT MESSAGE IS RIDICULOUS; PLEASE EXPAND ON IT, AND DO
>   SO BY LEVERAGING BOTH PROS AND CONS OF THE APPLIED CHANGES

Do you have any concrete suggestions (i.e., some actual text) for 
improvements to the patch description?  Earlier in your message you 
mentioned that Will's comment:

	LKMM offers stronger guarantees that can portably be relied upon
	in the codebase.

would make a good addition.  Suitably edited, it could be added to the
description.  I can think of a few other things myself, but I'd like to 
hear your thoughts.  Anything else?

Alan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ