@@ -5,6 +5,7 @@
* Very small subset of simple string routines
*/
+#include <linux/compiler_attributes.h>
#include <linux/types.h>
void *memcpy(void *dest, const void *src, size_t n)
@@ -27,3 +28,19 @@ void *memset(void *s, int c, size_t n)
ss[i] = c;
return s;
}
+
+void * __weak memmove(void *dest, const void *src, size_t n)
+{
+ unsigned int i;
+ const char *s = src;
+ char *d = dest;
+
+ if ((uintptr_t)dest < (uintptr_t)src) {
+ for (i = 0; i < n; i++)
+ d[i] = s[i];
+ } else {
+ for (i = n; i > 0; i--)
+ d[i - 1] = s[i - 1];
+ }
+ return dest;
+}
This is _not_ an upstream commit and just for 5.4.y only. kernel test robot reported a 5.4.y build issue found by randconfig [1] after backporting commit 89b158635ad7 ("lib/lz4: explicitly support in-place decompression"") due to "undefined reference to `memmove'". However, upstream and 5.10 LTS seem fine. After digging further, I found commit a510b616131f ("MIPS: Add support for ZSTD-compressed kernels") introduced memmove() occasionally and it has been included since v5.10. This partially cherry-picks the memmove() part of commit a510b616131f to fix the reported build regression since we don't need the whole patch for 5.4 LTS at all. [1] https://lore.kernel.org/r/202107070120.6dOj1kB7-lkp@intel.com/ Fixes: defcc2b5e54a ("lib/lz4: explicitly support in-place decompression") # 5.4.y Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com> --- v2: "just submit the fix and say _why_ this is not an upstream commit, do not attempt to emulate an upstream commit like your change did." as Greg suggested... arch/mips/boot/compressed/string.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)