[PATCH 05/10] staging: erofs: add a full barrier in erofs_workgroup_unfreeze
gaoxiang25 at huawei.com
Fri Nov 23 02:51:33 UTC 2018
On 2018/11/23 2:50, Andrea Parri wrote:
> On Thu, Nov 22, 2018 at 06:56:32PM +0800, Gao Xiang wrote:
>> Hi Greg,
>> On 2018/11/22 18:22, Greg Kroah-Hartman wrote:
>>> Please document this memory barrier. It does not make much sense to
>> Because we need to make the other observers noticing the latest values modified
>> in this locking period before unfreezing the whole workgroup, one way is to use
>> a memory barrier and the other way is to use ACQUIRE and RELEASE. we selected
>> the first one.
>> Hmmm...ok, I will add a simple message to explain this, but I think that is
>> plain enough for a lock...
> Sympathizing with Greg's request, let me add some specific suggestions:
> 1. It wouldn't hurt to indicate a pair of memory accesses which are
> intended to be "ordered" by the memory barrier in question (yes,
> this pair might not be unique, but you should be able to provide
> an example).
> 2. Memory barriers always come matched by other memory barriers, or
> dependencies (it really does not make sense to talk about a full
> barrier "in isolation"): please also indicate (an instance of) a
> matching barrier or the matching barriers.
> 3. How do the hardware threads communicate? In the acquire/release
> pattern you mentioned above, the load-acquire *reads from* a/the
> previous store-release, a memory access that follows the acquire
> somehow communicate with a memory access preceding the release...
> 4. It is a good practice to include the above information within an
> (inline) comment accompanying the added memory barrier (in fact,
> IIRC, checkpatch.pl gives you a "memory barrier without comment"
> warning when you omit to do so); not just in the commit message.
> Hope this helps. Please let me know if something I wrote is unclear,
Thanks for taking time on the detailed explanation. I think it is helpful for me. :)
And you are right, barriers should be in pairs, and I think I need to explain more:
255 static inline bool erofs_workgroup_get(struct erofs_workgroup *grp, int *ocnt)
257 int o;
260 o = erofs_wait_on_workgroup_freezed(grp);
262 if (unlikely(o <= 0))
263 return -1;
265 if (unlikely(atomic_cmpxchg(&grp->refcount, o, o + 1) != o)) <- *
266 goto repeat;
imply a memory barrier here
268 *ocnt = o;
269 return 0;
I think atomic_cmpxchg implies a memory barrier semantics when the value comparison (*) succeeds...
I don't know whether my understanding is correct, If I am wrong..please correct me, or
I need to add more detailed code comments to explain in the code?
>> Gao Xiang
>>> greg k-h
More information about the devel