[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171103002305.GZ5858@dastard>
Date: Fri, 3 Nov 2017 11:23:05 +1100
From: Dave Chinner <david@...morbit.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Elena Reshetova <elena.reshetova@...el.com>,
darrick.wong@...cle.com, linux-kernel@...r.kernel.org,
linux-xfs@...r.kernel.org, keescook@...omium.org
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.
Cheers,
Dave.
--
Dave Chinner
david@...morbit.com
Powered by blists - more mailing lists