Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

Glibc change exposing bugs

Posted Nov 15, 2010 9:47 UTC (Mon) by mpr22 (subscriber, #60784)
In reply to: Glibc change exposing bugs by Wol
Parent article: Glibc change exposing bugs

I must confess to being utterly boggled by the notion of a backwards block copy (decrementing address) being faster than the forward (incrementing address) version. I mean, doesn't backward copying break the memory controller prefetch?

(Log in to post comments)

Posted Nov 15, 2010 11:50 UTC (Mon) by cladisch (✭ supporter ✭, #50193) [Link]

Backward copying avoids cache address aliasing effects on these processors:
http://lists.freedesktop.org/archives/pixman/2010-August/...

Glibc change exposing bugs

Posted Nov 15, 2010 12:15 UTC (Mon) by slashdot (guest, #22014) [Link]

That rationale seems a bit dubious.

In particular, won't just doing all reads before all writes ensure no aliasing regardless of CPU operation?
I think there are enough callee-clobbered registers on x86-64 to allow that.

That is, do this:
movq (%rsi), %rax
movq 8(%rsi), %rdx
movq %rax, (%rdi)
movq %rdx, 8(%rdi)

Also, their backward copy obviously aliases if rsi is 0xf00c instead of 0xf004. I'm not sure why either of these cases should be intrinsically more frequent.