Thread (13 messages) 13 messages, 5 authors, 2012-10-19

Re: [PATCH] percpu-rwsem: use barrier in unlock path

From: Lai Jiangshan <hidden>
Date: 2012-10-17 05:55:27
Also in: lkml

On 10/17/2012 10:23 AM, Linus Torvalds wrote:
[ Architecture people, note the potential new SMP barrier! ]

On Tue, Oct 16, 2012 at 4:30 PM, Mikulas Patocka [off-list ref] wrote:
quoted
+       /*
+        * The lock is considered unlocked when p->locked is set to false.
+        * Use barrier prevent reordering of operations around p->locked.
+        */
+#if defined(CONFIG_X86) && (!defined(CONFIG_X86_PPRO_FENCE) && !defined(CONFIG_X86_OOSTORE))
+       barrier();
+#else
+       smp_mb();
+#endif
        p->locked = false;
Ugh. The #if is too ugly to live.
Even the previous patch is applied, percpu_down_read() still
needs mb() to pair with it.
This is a classic case of "people who write their own serialization
primitives invariably get them wrong". And this fix is just horrible,
and code like this should not be allowed.
One of the most major problems of 62ac665ff9fc07497ca524bd20d6a96893d11071 is that
it is merged without Ackeds or Revieweds from Paul or Peter or someone else
who are expert at synchronization/arch memory models.

I suggest any new synchronization should stay in -tip for 2 or more cycles
before merged to mainline.

Thanks,
Lai
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help