On Thu, Dec 10, 2020 at 01:15:29PM -0800, Nick Desaulniers wrote:
> On Tue, Dec 8, 2020 at 11:21 PM Jiri Slaby <jirislaby@xxxxxxxxxx> 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.
Applied, thanks.
greg k-h
