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] [day] [month] [year] [list]
Date:   Fri, 3 Nov 2017 08:19:27 +0000
From:   "Reshetova, Elena" <>
To:     Dave Chinner <>,
        Peter Zijlstra <>
CC:     "" <>,
        "" <>,
        "" <>,
        "" <>
Subject: RE: [PATCH 0/5] xfs refcount conversions

> [I missed this followup, other stuff]
> On Mon, Oct 23, 2017 at 03:41:49PM +0200, Peter Zijlstra wrote:
> > On Sat, Oct 21, 2017 at 10:21:11AM +1100, Dave Chinner wrote:
> > > On Fri, Oct 20, 2017 at 02:07:53PM +0300, Elena Reshetova wrote:
> > > IMO, that makes it way too hard to review sanely for code that:
> > >
> > > 	a) we already know works correctly
> >
> > But how do you know if you have unknown ordering requirements?
> Because back when it was converted to atomic-based object reference
> counts, I went through all the memory-barriers.txt stuff to make
> sure it was OK. That was years ago, and I've forgotten it all and
> the life-cycle constaints that lead us to use atomics in this
> manner.
> Now, I've got to go determine what the difference between atomic and
> refcounts are and work them out myself because nobody has documented
> it. And I have to go look at all the commit logs to work out in that
> has any effect on the objects using the atomics, because that's no
> longer in my head. There probably isn't an issue here, but such
> changes are not done without review, and that's what is needed to
> review the change.
> That's the problem here - I have to work out what the differences in
> ordering constraints between refcounts and atomics are myself
> because it's not actually documented anywhere for reviewiers to
> understand.  That's a significant burden to put on a reviewer for
> what is supposed to be a "no-op" change.

The memory ordering changes are currently documented in refcount.c
file itself, but I agree that we should try to provide more information. 
That's why we are having this separate thread now going and searching
for suitable examples and more elaborate explanation. 

So, hopefully very soon we will end up with having what you are asking for. 

Best Regards,

> Cheers,
> Dave.
> --
> Dave Chinner

Powered by blists - more mailing lists