linux-kernel - Re: [PATCH 0/2] tools/memory-model: remove ACCESS

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: <20180702185415.GR3593@linux.vnet.ibm.com>
Date:   Mon, 2 Jul 2018 11:54:15 -0700
From:   "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:     Andrea Parri <andrea.parri@...rulasolutions.com>
Cc:     Mark Rutland <mark.rutland@....com>, linux-kernel@...r.kernel.org,
        akiyks@...il.com, boqun.feng@...il.com, dhowells@...hat.com,
        j.alglave@....ac.uk, luc.maranget@...ia.fr, npiggin@...il.com,
        peterz@...radead.org, stern@...land.harvard.edu,
        will.deacon@....com
Subject: Re: [PATCH 0/2] tools/memory-model: remove ACCESS_ONCE()

On Thu, Jun 28, 2018 at 06:51:11PM +0200, Andrea Parri wrote:
> > 1bc179880fba docs: atomic_ops: Describe atomic_set as a write operation
> > 
> > 	The above patches need at least one additional Acked-by
> > 	or Reviewed-by.  If any of you gets a chance, please do
> > 	look them over.
> 
> Glad this came out. ;-)
> 
> No objection to the patch: feel free to add my Reviewed-by: tag.

Done, thank you!

> (BTW, atomic_set() would be better mapped to WRITE_ONCE()... in fact, to
>  be fair, some archs do it the __asm__ __volatile__() way).
> 
> I do however have some suggestions concerning "the process":  searching
> LKML for the patch and the related discussion, I could only find:
> 
>   [PATCH] docs: atomic_ops: atomic_set is a write (not read) operation
> 
> and I realize that none of the person Cc:-ed in this thread, except you,
> were Cc:-ed in that discussion (in compliance with get_maintainer.pl).
> 
> My suggestions:
> 
>   1) Merge the file touched by that patch into (the recently created):
>   
>         Documentation/atomic_t.txt
> 
>      (FWIW, queued in my TODO list).

Some consolidation of documentation would be good.  ;-)

Thoughts from others?

>   2) Add the entry:
> 
> 	F: Documentation/atomic_t.txt
> 
>      to the "ATOMIC INFRASTRUCTURE" subsystem in the MAINTAINERS file so
>      that developers can easily find (the intended?) reviewers for their
>      patch. (Of course, this will need ACK from the ATOMIC people).

If the merging will take awhile, it might also be good to put
Documentation/core-api/atomic_ops.rst somewhere as well.

							Thanx, Paul