linux-kernel - Re: [RFC PATCH 0/6] linkage: better symbol aliasing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Ybm0Rl6TxdgA0tsB@FVFF77S0Q05N>
Date:   Wed, 15 Dec 2021 09:24:22 +0000
From:   Mark Rutland <mark.rutland@....com>
To:     Catalin Marinas <catalin.marinas@....com>
Cc:     linux-kernel@...r.kernel.org, Borislav Petkov <bp@...en8.de>,
        Jiri Slaby <jslaby@...e.cz>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>, ardb@...nel.org,
        broonie@...nel.org, dave.hansen@...ux.intel.com,
        linux-arm-kernel@...ts.infradead.org, maz@...nel.org,
        mingo@...hat.com, tabba@...gle.com, tglx@...utronix.de,
        will@...nel.org
Subject: Re: [RFC PATCH 0/6] linkage: better symbol aliasing

On Fri, Dec 10, 2021 at 03:04:45PM +0000, Catalin Marinas wrote:
> On Mon, Dec 06, 2021 at 12:47:09PM +0000, Mark Rutland wrote:
> > This series aims to make symbol aliasing simpler and more consistent.
> > The basic idea is to replace SYM_FUNC_START_ALIAS(alias) and
> > SYM_FUNC_END_ALIAS(alias) with a new SYM_FUNC_ALIAS(alias, name), so
> > that e.g.
> > 
> >     SYM_FUNC_START(func)
> >     SYM_FUNC_START_ALIAS(alias1)
> >     SYM_FUNC_START_ALIAS(alias2)
> >         ... asm insns ...
> >     SYM_FUNC_END(func)
> >     SYM_FUNC_END_ALIAS(alias1)
> >     SYM_FUNC_END_ALIAS(alias2)
> >     EXPORT_SYMBOL(alias1)
> >     EXPORT_SYMBOL(alias2)
> > 
> > ... can become:
> > 
> >     SYM_FUNC_START(name)
> >         ... asm insns ...
> >     SYM_FUNC_END(name)
> > 
> >     SYM_FUNC_ALIAS(alias1, func)
> >     EXPORT_SYMBOL(alias1)
> > 
> >     SYM_FUNC_ALIAS(alias2, func)
> >     EXPORT_SYMBOL(alias2)
> > 
> > This avoids repetition and hopefully make it easier to ensure
> > consistency (e.g. so each function has a single canonical name and
> > associated metadata).
> > 
> > I'm sending this as an RFC since I want to check:
> > 
> > a) People are happy with the idea in principle.
> > 
> > b) People are happy with the implementation within <linux/linkage.h>.
> > 
> > ... and I haven't yet converted the headers under tools/, which is
> > largely a copy+paste job.
> 
> I'm happy with the approach and acked the arm64 patches for the record.
> Not sure how/when this series will get into mainline.

Thanks!

As to "when", I think I'm going to rework the series atop v5.17-rc1, so for now
would you be happy to pick patch 3 ("arm64: remove __dma_*_area() aliases"):

  https://lore.kernel.org/linux-arm-kernel/20211206124715.4101571-4-mark.rutland@arm.com/

... into the arm64 tree? That'a a pure cleanup with no dependency on the rest
of the series.

For the rest of the series I still need to to the mechanical work for tools/,
there's a token-pasting issue on 32-bit arm, and I'd like to give this a long
soak in -next, so earlier in the next window seems like a better bet.

As for "how", I assume the core linkage bits will go via the tip tree, so I
think it'd make sense for the (remaining) arch bits to go that way too.

Thanks,
Mark.