From d72f73405044c0bb2beaba83e035162d26a24a0f Mon Sep 17 00:00:00 2001 From: Patrick Farrell Date: Fri, 7 Apr 2023 14:15:43 -0400 Subject: [PATCH] LU-16510 build: include unsafe_memcpy definition The original LU-16510 missed a key part of the unsafe_memcpy code from the upstream kernel, and so we weren't actually defining unsafe_memcpy() as intended. Thanks to Aurelien Degremont for pointing this out. Fixes: 5099a3b7 ("LU-16510 build: fortified memcpy from linux 6.1") Signed-off-by: Patrick Farrell Change-Id: Ib9e2d56ed0b3691f1ab9fcd25403fa86ac784b6d Reviewed-on: https://review.whamcloud.com/c/ex/lustre-release/+/50574 Tested-by: jenkins Tested-by: Andreas Dilger Reviewed-by: Andreas Dilger --- libcfs/include/libcfs/linux/linux-fortify-string.h | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/libcfs/include/libcfs/linux/linux-fortify-string.h b/libcfs/include/libcfs/linux/linux-fortify-string.h index bf03e0e..aeed8c5 100644 --- a/libcfs/include/libcfs/linux/linux-fortify-string.h +++ b/libcfs/include/libcfs/linux/linux-fortify-string.h @@ -80,6 +80,22 @@ extern char *__underlying_strncpy(char *p, const char *q, __kernel_size_t size) #define __underlying_strncpy __builtin_strncpy #endif +/** + * unsafe_memcpy - memcpy implementation with no FORTIFY bounds checking + * + * @dst: Destination memory address to write to + * @src: Source memory address to read from + * @bytes: How many bytes to write to @dst from @src + * @justification: Free-form text or comment describing why the use is needed + * + * This should be used for corner cases where the compiler cannot do the + * right thing, or during transitions between APIs, etc. It should be used + * very rarely, and includes a place for justification detailing where bounds + * checking has happened, and why existing solutions cannot be employed. + */ +#define unsafe_memcpy(dst, src, bytes, justification) \ + __underlying_memcpy(dst, src, bytes) + /* * Clang's use of __builtin_*object_size() within inlines needs hinting via * __pass_*object_size(). The preference is to only ever use type 1 (member -- 1.8.3.1