From: "John Stoffel" <john@xxxxxxxxxxx> Date: Mon, 23 Mar 2015 15:56:02 -0400 >>>>>> "David" == David Miller <davem@xxxxxxxxxxxxx> writes: > > David> From: "John Stoffel" <john@xxxxxxxxxxx> > David> Date: Mon, 23 Mar 2015 12:51:03 -0400 > >>> Would it make sense to have some memmove()/memcopy() tests on bootup >>> to catch problems like this? I know this is a strange case, and >>> probably not too common, but how hard would it be to wire up tests >>> that go through 1 to 128 byte memmove() on bootup to make sure things >>> work properly? >>> >>> This seems like one of those critical, but subtle things to be >>> checked. And doing it only on bootup wouldn't slow anything down and >>> would (ideally) automatically get us coverage when people add new >>> archs or update the code. > > David> One of two things is already happening. > > David> There have been assembler memcpy/memset development test harnesses > David> around that most arch developers are using, and those test things > David> rather extensively. > > David> Also, the memcpy/memset routines on sparc in particular are completely > David> shared with glibc, we use the same exact code in both trees. So it's > David> getting tested there too. > > Thats' good to know. I wasn't sure. > > David> memmove() is just not handled this way. > > Bummers. So why isn't this covered by the glibc tests too? Because the kernel's memmove() is different from the one we use in glibc on sparc. In fact, we use the generic C version in glibc which expands to forward and backward word copies. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
