On Tue, Dec 8, 2020 at 11:21 PM Jiri Slaby wrote: > > On 09. 12. 20, 8:20, Jiri Slaby wrote: > > On 09. 12. 20, 1:12, Nick Desaulniers wrote: > >> Dear stable kernel maintainers, > >> Please consider accepting the following backport to 5.4 and 4.19 of > >> commit 4d6ffa27b8e5 ("x86/lib: Change .weak to SYM_FUNC_START_WEAK for > >> arch/x86/lib/mem*_64.S"), attached. Also, first landed in v5.10-rc3. Exists in v5.9.7 as 305da744c138487864a46b2fb0bd7cf54e1e03b4. > >> > >> The patch to 5.4 had a conflict due to 5.4 missing upstream commit > >> e9b9d020c487 ("x86/asm: Annotate aliases") which first landed in > >> v5.5-rc1. > >> > >> The patch to 4.19 had a conflict due to 4.19 missing the above commit > >> and ffedeeb780dc ("linkage: Introduce new macros for assembler > >> symbols") which also first landed in v5.5-rc1 but was backported to > >> linux-5.4.y as commit 840d8c9b3e5f ("linkage: Introduce new macros for > >> assembler symbols") which shipped in v5.4.76. > >> > >> This patch fixes a build error from clang's assembler when building > >> with Clang-12, which now errors when symbols are redeclared with > >> different bindings. We're using clang's assembler in Android and > >> ChromeOS for 4.19+. > >> > >> Jiri, would you mind reviewing the 4.19 patch (or both)? It simply > >> open codes what the upstream macros would expand to; this can be and > >> was observed from running: > > > > You don't have to touch (expand) __memcpy, __memmove, and __memset, right? Sure, attached a v2. It's actually a little cleaner (smaller diffstat) that way. > > Also, no need for doubled p2align. eh, maybe, but 1. it's what SYM_FUNC_START expands to precisely; removing it would be (too) different from what upstream is doing IMO. 2. it's obviously doubled when in v1 I was expanding the __ prefixed symbols as well; not so obvious in v2. 3. the order of __ prefixed symbols differs between these three; I'd rather not rely on the order or have to reorder them to get the initial symbol realigned; specifying the alignment for both seems safer to me. So I haven't included that suggestion in v2, but please feel free to convince me otherwise if you feel strongly. Thanks for taking the time to review. I appreciate it. -- Thanks, ~Nick Desaulniers