linux-kernel - Re: BUG report about ipt_do

lists.openwall.net		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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 10 Oct 2013 15:18:41 +0100
From:	Will Deacon <will.deacon@....com>
To:	"Wang, Yalin" <Yalin.Wang@...ymobile.com>
Cc:	"'linux-arm-msm-owner@...r.kernel.org'" 
	<linux-arm-msm-owner@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Peng, Arthur" <Arthur.Peng@...ymobile.com>,
	"Zhang, Bojie" <Bojie.Zhang@...ymobile.com>,
	"Gu, Youcai 1 (EXT)" <Youcai1.Gu@...ymobile.com>,
	"Alevoor, Raghavendra 2" <Raghavendra.Alevoor@...ymobile.com>
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/