On 04.06.2019 13:48, Greg KH wrote: > On Tue, Jun 04, 2019 at 11:21:59AM +0200, Stefan Agner wrote: >> From: Miguel Ojeda <miguel.ojeda.sandonis@xxxxxxxxx> >> >> [ Upstream commit c0d9782f5b6d7157635ae2fd782a4b27d55a6013 >> >> >From the GCC manual: >> >> copy >> copy(function) >> >> The copy attribute applies the set of attributes with which function >> has been declared to the declaration of the function to which >> the attribute is applied. The attribute is designed for libraries >> that define aliases or function resolvers that are expected >> to specify the same set of attributes as their targets. The copy >> attribute can be used with functions, variables, or types. However, >> the kind of symbol to which the attribute is applied (either >> function or variable) must match the kind of symbol to which >> the argument refers. The copy attribute copies only syntactic and >> semantic attributes but not attributes that affect a symbol’s >> linkage or visibility such as alias, visibility, or weak. >> The deprecated attribute is also not copied. >> >> https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html >> >> The upcoming GCC 9 release extends the -Wmissing-attributes warnings >> (enabled by -Wall) to C and aliases: it warns when particular function >> attributes are missing in the aliases but not in their target, e.g.: >> >> void __cold f(void) {} >> void __alias("f") g(void); >> >> diagnoses: >> >> warning: 'g' specifies less restrictive attribute than >> its target 'f': 'cold' [-Wmissing-attributes] >> >> Using __copy(f) we can copy the __cold attribute from f to g: >> >> void __cold f(void) {} >> void __copy(f) __alias("f") g(void); >> >> This attribute is most useful to deal with situations where an alias >> is declared but we don't know the exact attributes the target has. >> >> For instance, in the kernel, the widely used module_init/exit macros >> define the init/cleanup_module aliases, but those cannot be marked >> always as __init/__exit since some modules do not have their >> functions marked as such. >> >> Cc: <stable@xxxxxxxxxxxxxxx> # 4.14+ >> Suggested-by: Martin Sebor <msebor@xxxxxxxxxxx> >> Reviewed-by: Nick Desaulniers <ndesaulniers@xxxxxxxxxx> >> Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@xxxxxxxxx> >> Signed-off-by: Stefan Agner <stefan@xxxxxxxx> >> --- >> include/linux/compiler-gcc.h | 4 ++++ >> include/linux/compiler_types.h | 4 ++++ >> 2 files changed, 8 insertions(+) > > Can I get a series of these for 4.19.y as well? I don't want to apply > anything to 4.14 that will regress moving to 4.19. Make sense, will create a backport for 4.19 too. -- Stefan
