Re: [PATCH]snmp6 64-bit counter support in proc.c

[Krishna Kumar <kumarkr@xxxxxxxxxx>]

Dave,

Isn't memory barrier used to stop re-ordering of instructions and needs to be present
in both reader as well as writer to have synchronization since mb is for the CPU on
which it is executing ? In this case : suppose stat is getting incremented from
00000000 FFFFFFFF to 00000001 00000000, and stat was read after the low word was
incremented to 0 (with overflow set), then low1 = 0 and low2 can get executed before the
low2 is incremented on the other processor, so low2 is still zero. We return zero, when
the value should be 4G. That why I felt that we need to read second after making sure
the writer is over, that doesn't assume that writer is faster than reader and works in all
cases.

Am I wrong here ?

thanks,

- KK

"David S. Miller" <davem@xxxxxxxxxx>

"David S. Miller" <davem@xxxxxxxxxx> Sent by: netdev-bounce@xxxxxxxxxxx 01/22/2004 02:10 PM

To: Krishna Kumar/Beaverton/IBM@IBMUS cc: kuznet@xxxxxxxxxxxxx, mashirle@xxxxxxxxxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx, netdev-bounce@xxxxxxxxxxx, Shirley Ma/Beaverton/IBM@IBMUS Subject: Re: [PATCH]snmp6 64-bit counter support in proc.c

The most portable and simple algorithm to solve this on the reader
side is (and I recommend we don't special case this on 64-bit platforms
just to get wider testing):

u32 high, low1, low2;

do {
low1 = stat & 0xffffffff;
rmb();
high = stat >> 32;
rmb();
low2 = stat & 0xffffffff;
} while (low2 < low1);

Something like that. The idea is to sample the lower 32-bit twice
and if it overflows resample both high and low halfs.