RE: [RFC] consistent_sync and non L1 cache line aligned buffers

[Darin.Johnson@nokia.com]

> invalidate_dcache_range works in L1_CACHE_LINE chunks, so if
> start and/or
> end of the buffer are not aligned we may corrupt data located
> in the same
> cache line (usually stack variable(s) declared before or after buffer
> declaration).

I had noticed this a long time ago when looking to see how PowerPC
Linux had solved this problem, but discovered that it just sidestepped
the problem.

I solved the problem (in a non-Linux system) by just flushing the first
and last lines in the requested range, and invalidating the rest.  The
very slight performance hit is probably less than testing to see if the
buffer is unaligned.

> To be safe I think it's better to modify consistent_sync to
> handle such
> "bad" buffers.

"Bad" is the wrong word to use, in my opinion.  If the function is
not called "invalidate_aligned_dcache_range", or is not otherwise
clearly and unambiguously documented (in an easy to locate place)
that there are severe restrictions on the input parameters, then
the function itself is "bad".  The "principle of least astonishment"
implies that a function should do just what its name implies without
hidden surprises.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/