lkml.org 
[lkml]   [2013]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRE: BUG report about ipt_do_table( )
Hi  Will,

Maybe I know your meaning ,
If it use spinlock to protected the shared data,
The bug will not happen, because spinlock will
Use DSB( ) to sync .
Unluckily, here, it use a special seqcount_t( ) (see get_counters( ) function)
To make sure there is no others using the old data,
Before release the old data, this is much like RCU
Work, but RCU use rcu_assign_pointer( ) -->
Which use smp_wmb( ) , so it's safe, am I right ?

In my patch, I use mb( ), because this macro
Is DSB( ) , while smp_wmb( ) is DMS( ),
I just think DSB is much strict than DMS,
mmm.. so , DSM( ) or DMS ( ) are both ok ?



The whitepaper I use is here:
https://www.google.com/#q=cortex+a15+microarchitecture

the first: [PDF] Exploring the Design of the Cortex-A15 Processor - ARM

I just search in Google, and you know that qcom don't release
Much document about its krait cpu's micro architecture details,
I just use cortex-a15 for a reference, I am not sure if their
pipeline ( load/store unit) are the same,
if you have cortex-a15 micro architecture details document,
I am very appreciated that you can share to me . :)

Thanks




-----Original Message-----
From: Will Deacon [mailto:will.deacon@arm.com]
Sent: Thursday, October 10, 2013 10:19 PM
To: Wang, Yalin
Cc: 'linux-arm-msm-owner@vger.kernel.org'; linux-kernel@vger.kernel.org; Peng, Arthur; Zhang, Bojie; Gu, Youcai 1 (EXT); Alevoor, Raghavendra 2
Subject: Re: BUG report about ipt_do_table( )

On Thu, Oct 10, 2013 at 12:26:38PM +0100, Wang, Yalin wrote:
> Hi Will ,

Hello,

> Seems your patch is better than mine,
> It make sure newinfo->initial_entries update is Seen by others .
>
> I will test by your patches , and update to you ASAP .

Thanks.

> I have another questions about this BUG, Since all shared data will
> have this problem especially Shared between different CPUs,
>
> This means all shared data need a smp_wmb() , after One CPU update it
> ?

Only if the ordering of observability matters and isn't enforced by other mechanisms (e.g. locks).

> But I see not all shared data are updated by this way, And kernel
> works well . Why ?? a little curious .

Again, the barriers tend to be hidden inside things like locking primitives, atomics, I/O accessors etc.

> Another is that , I read cortex-a15 whitepaper , It says :
>
> Load/Store cluster
> § All Load/Store, data transfers and cache maintenance operations §
> Partially out-of-order, 1 Load and 1 Store executed per cycle § Load
> cannot bypass a Store, Store cannot bypass a Store

It's hard to interpret this out of context. Please can you point me at the whitepaper? Also, I was talking from the perspective of the architecture and you're not using an A15 afaik.

> !! Store can't bypass store !! , but in this BUG , it seems later store can
> Be wrote into cache even before the earlier store completed !
> Am I right ?

The architecture requires stores to be observed in program order from the perspective of the CPU issuing them, but there aren't ordering guarantees for stores to different locations when observed by a different CPU.

Will
\
 
 \ /
  Last update: 2013-10-11 04:21    [W:0.048 / U:0.312 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site