David Miller wrote: [Sun Mar 22 2015, 01:36:03PM EDT] > From: Linus Torvalds <[email protected]> > Date: Sat, 21 Mar 2015 11:49:12 -0700 > > > Davem? I don't read sparc assembly, so I'm *really* not going to try > > to verify that (a) all the memcpy implementations always copy > > low-to-high and (b) that I even read the address comparisons in > > memmove.S right. > > All of the sparc memcpy implementations copy from low to high. > I'll eat my hat if they don't. :-) > > The guard tests at the beginning of memmove() are saying: > > if (dst <= src) > memcpy(...); > if (src + len <= dst) > memcpy(...); > > And then the reverse copy loop (and we do have to copy in reverse for > correctness) is basically: > > src = (src + len - 1); > dst = (dst + len - 1); > > 1: tmp = *(u8 *)src; > len -= 1; > src -= 1; > *(u8 *)dst = tmp; > dst -= 1; > if (len != 0) > goto 1b; > > And then we return the original 'dst' pointer. > > So at first glance it looks at least correct. > > memmove() is a good idea to look into though, as SLAB and SLUB are the > only really heavy users of it, and they do so with overlapping > contents. > > And they end up using that byte-at-a-time code, since SLAB and SLUB > do mmemove() calls of the form: > > memmove(X + N, X, LEN); > > In which case neither of the memcpy() guard tests will pass. > > Maybe there is some subtle bug in there I just don't see right now. My original pursuit of this issue focused on transfers to and from the shared array. Basically substituting memcpy-s with a primitive unsigned long memory mover. This might have been incorrect.
There were substantial doubts because of large modifications to 2.6.39 too. Unstabile hardware cause(d|s) issue too. Eliminating the shared array functions correctly. Though this removal changes performance and timing dramatically. This afternoon I included modification of two memmove-s and no issue thus far. The issue APPEARS to come from memmove-s within cache_flusharray() and/or drain_array(). Now we are covering moves within an array_cache. The above was done on 2.6.39. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
