standard/storage.hh: use linux memory barrier when building the linux module

I found that in certain circumstances, skbs can be recycled fast enough
for click to trigger an access to an out-of-date L1 cache entry.

A problem manifested on a a dual-core ARM 9 platform. I could regularly
reproduce a crash with a linux module click config of:

FromDevice(eth0) -> Discard;

While RXing a gigabit of traffic from eth0. Somewhat unique to this
scenario is the fact that the click task and the eth0 irq were pinned to
different CPUs, so every packet going through FromDevice was being
handed off between cores.

I believe what is happening in my case is that an skb is handed off
between the cores fast enough that L1 cache snooping can't keep up, so
in some instances click is seeing bogus/invalid data when accessing
members of the struct sk_buff, ie the following scenario occurs:

Core0: click frees an skb
Core1: enet driver allocates that skb
Core1: fills in data for skb, hands back to click
Core0: from device accesses skb members, but their data is out of date

Injecting a hardware memory barrier made my issues go away. I believe
the hardware barrier is ensuring that cache snooping occurs during
packet hand-off between the cores.