• David S. Miller's avatar
    sparc64: Fix several bugs in memmove(). · f27d9c41
    David S. Miller authored
    commit 2077cef4 upstream.
    
    Firstly, handle zero length calls properly.  Believe it or not there
    are a few of these happening during early boot.
    
    Next, we can't just drop to a memcpy() call in the forward copy case
    where dst <= src.  The reason is that the cache initializing stores
    used in the Niagara memcpy() implementations can end up clearing out
    cache lines before we've sourced their original contents completely.
    
    For example, considering NG4memcpy, the main unrolled loop begins like
    this:
    
         load   src + 0x00
         load   src + 0x08
         load   src + 0x10
         load   src + 0x18
         load   src + 0x20
         store  dst + 0x00
    
    Assume dst is 64 byte aligned and let's say that dst is src - 8 for
    this memcpy() call.  That store at the end there is the one to the
    first line in the cache line, thus clearing the whole line, which thus
    clobbers "src + 0x28" before it even gets loaded.
    
    To avoid this, just fall through to a simple copy only mildly
    optimized for the case where src and dst are 8 byte aligned and the
    length is a multiple of 8 as well.  We could get fancy and call
    GENmemcpy() but this is good enough for how this thing is actually
    used.
    Reported-by: default avatarDavid Ahern <david.ahern@oracle.com>
    Reported-by: default avatarBob Picco <bpicco@meloft.net>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
    f27d9c41
memmove.S 1.17 KB