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] [day] [month] [year] [list]
Message-ID: <f33570e2-a67d-b0cf-f127-040ccd9e5da9@gmail.com>
Date:   Wed, 8 Sep 2021 11:52:33 +0800
From:   Weizhao Ouyang <o451686892@...il.com>
To:     LEROY Christophe <christophe.leroy@...roup.eu>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ingo Molnar <mingo@...hat.com>
Cc:     Rich Felker <dalias@...c.org>,
        "linux-ia64@...r.kernel.org" <linux-ia64@...r.kernel.org>,
        "linux-sh@...r.kernel.org" <linux-sh@...r.kernel.org>,
        "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
        "James E.J. Bottomley" <James.Bottomley@...senPartnership.com>,
        Guo Ren <guoren@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
        "sparclinux@...r.kernel.org" <sparclinux@...r.kernel.org>,
        "linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
        Vincent Chen <deanbo422@...il.com>,
        Will Deacon <will@...nel.org>,
        "linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
        Yoshinori Sato <ysato@...rs.sourceforge.jp>,
        Helge Deller <deller@....de>,
        "x86@...nel.org" <x86@...nel.org>,
        Russell King <linux@...linux.org.uk>,
        "linux-csky@...r.kernel.org" <linux-csky@...r.kernel.org>,
        Christian Borntraeger <borntraeger@...ibm.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Vasily Gorbik <gor@...ux.ibm.com>,
        Heiko Carstens <hca@...ux.ibm.com>,
        Borislav Petkov <bp@...en8.de>,
        Greentime Hu <green.hu@...il.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Michal Simek <monstr@...str.eu>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        "linux-parisc@...r.kernel.org" <linux-parisc@...r.kernel.org>,
        Nick Hu <nickhu@...estech.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Palmer Dabbelt <palmer@...belt.com>,
        Paul Mackerras <paulus@...ba.org>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH v3] ftrace: Cleanup ftrace_dyn_arch_init()

Thanks for reply.

On 2021/9/7 23:55, LEROY Christophe wrote:
>
>> -----Message d'origine-----
>> De : Linuxppc-dev <linuxppc-dev-
>> bounces+christophe.leroy=csgroup.eu@...ts.ozlabs.org> De la part de Weizhao
>> Ouyang
>>
>> Most of ARCHs use empty ftrace_dyn_arch_init(), introduce a weak common
>> ftrace_dyn_arch_init() to cleanup them.
>>
>> Signed-off-by: Weizhao Ouyang <o451686892@...il.com>
>> Acked-by: Heiko Carstens <hca@...ux.ibm.com> (s390)
>> Acked-by: Helge Deller <deller@....de> (parisc)
>>
>> ---
>> Changes in v3:
>> -- fix unrecognized opcode on PowerPC
>>
>> Changes in v2:
>> -- correct CONFIG_DYNAMIC_FTRACE on PowerPC
>> -- add Acked-by tag
>>
>> ---
>>  arch/arm/kernel/ftrace.c          | 5 -----
>>  arch/arm64/kernel/ftrace.c        | 5 -----
>>  arch/csky/kernel/ftrace.c         | 5 -----
>>  arch/ia64/kernel/ftrace.c         | 6 ------
>>  arch/microblaze/kernel/ftrace.c   | 5 -----
>>  arch/mips/include/asm/ftrace.h    | 2 ++
>>  arch/nds32/kernel/ftrace.c        | 5 -----
>>  arch/parisc/kernel/ftrace.c       | 5 -----
>>  arch/powerpc/include/asm/ftrace.h | 4 ++++
>>  arch/riscv/kernel/ftrace.c        | 5 -----
>>  arch/s390/kernel/ftrace.c         | 5 -----
>>  arch/sh/kernel/ftrace.c           | 5 -----
>>  arch/sparc/kernel/ftrace.c        | 5 -----
>>  arch/x86/kernel/ftrace.c          | 5 -----
>>  include/linux/ftrace.h            | 1 -
>>  kernel/trace/ftrace.c             | 5 +++++
>>  16 files changed, 11 insertions(+), 62 deletions(-)
>>
>> diff --git a/arch/mips/include/asm/ftrace.h b/arch/mips/include/asm/ftrace.h
>> index b463f2aa5a61..ed013e767390 100644
>> --- a/arch/mips/include/asm/ftrace.h
>> +++ b/arch/mips/include/asm/ftrace.h
>> @@ -76,6 +76,8 @@ do {                                                \
>>
>>
>>  #ifdef CONFIG_DYNAMIC_FTRACE
>> +int __init ftrace_dyn_arch_init(void);
>> +
> Why ?
>
>
>>  static inline unsigned long ftrace_call_adjust(unsigned long addr)
>>  {
>>       return addr;
>> diff --git a/arch/powerpc/include/asm/ftrace.h
>> b/arch/powerpc/include/asm/ftrace.h
>> index debe8c4f7062..b05c43f13a4d 100644
>> --- a/arch/powerpc/include/asm/ftrace.h
>> +++ b/arch/powerpc/include/asm/ftrace.h
>> @@ -126,6 +126,10 @@ static inline void this_cpu_enable_ftrace(void) { }
>>  static inline void this_cpu_set_ftrace_enabled(u8 ftrace_enabled) { }
>>  static inline u8 this_cpu_get_ftrace_enabled(void) { return 1; }
>>  #endif /* CONFIG_PPC64 */
>> +
>> +#ifdef CONFIG_DYNAMIC_FTRACE
>> +int __init ftrace_dyn_arch_init(void);
>> +#endif /* CONFIG_DYNAMIC_FTRACE */
> Why ?
>
>>  #endif /* !__ASSEMBLY__ */
>>
>>  #endif /* _ASM_POWERPC_FTRACE */
>> diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
>> index 832e65f06754..f1eca123d89d 100644
>> --- a/include/linux/ftrace.h
>> +++ b/include/linux/ftrace.h
>> @@ -573,7 +573,6 @@ ftrace_set_early_filter(struct ftrace_ops *ops, char
>> *buf, int enable);
>>
>>  /* defined in arch */
>>  extern int ftrace_ip_converted(unsigned long ip);
>> -extern int ftrace_dyn_arch_init(void);
> Why removing that ?
>
> Have you tried to build kernel/trace/ftrace.o with C=2 ? It will likely tell you that the function is not declared and that it should be static

Yes I missed this check. Under the situation, the function should be static.

> We could eventually consider that in the past, this generic declaration was unrelevant because the definitions where in the arch specific sections.
> Now that you are implementing a generic weak version of this function, it would make sense to have a generic declaration as well.
>
> I really don't see the point in duplicating the declaration of the function in the arch specific headers.

I use declaration in arch specific headers in tend to clarify the arch has implement ftrace_dyn_arch_init().
Anyway, it maybe pointless, a generic declaration is enough. Will update it later.

>>  extern void ftrace_replace_code(int enable);
>>  extern int ftrace_update_ftrace_func(ftrace_func_t func);
>>  extern void ftrace_caller(void);
> Christophe
>
> CS Group - Document Interne

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ