linux-kernel - Re: [PATCH] x86/kernel: Fix more -Wmissing-prototypes warnings

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: <20181208145658.4de9cfedcd265bcba4b252d0@kernel.org>
Date:   Sat, 8 Dec 2018 14:56:58 +0900
From:   Masami Hiramatsu <mhiramat@...nel.org>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Ingo Molnar <mingo@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Andrew Banman <andrew.banman@....com>,
        Dimitri Sivanich <dimitri.sivanich@....com>,
        "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
        Mike Travis <mike.travis@....com>,
        "Steven Rostedt (VMware)" <rostedt@...dmis.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Yi Wang <wang.yi59@....com.cn>, linux-acpi@...r.kernel.org
Subject: Re: [PATCH] x86/kernel: Fix more -Wmissing-prototypes warnings

On Fri, 7 Dec 2018 20:48:47 +0100
Borislav Petkov <bp@...en8.de> wrote:

> On Fri, Dec 07, 2018 at 11:42:10PM +0900, Masami Hiramatsu wrote:
> > Hmm, I just thought that the symbol only referred from inline asm should
> > be visible. But if it is OK for any version of supported gcc and clang,
> > I'm good to remove it. :-) (IOW, I just concerned about older gcc)
> 
> I just tried two gcc versions: 8.2 and 4.8.5. Both asms looks good:
> 
> ffffffff81044690 <kretprobe_trampoline>:
> ...
> 
> 
> ffffffff810446ab:       41 57                   push   %r15
> ffffffff810446ad:       48 89 e7                mov    %rsp,%rdi
> ffffffff810446b0:       e8 db 01 00 00          callq  ffffffff81044890 <trampoline_handler>
> 
> there's the CALL...
> 
> ffffffff810446b5:       48 89 84 24 98 00 00    mov    %rax,0x98(%rsp)
> ffffffff810446bc:       00
> 
> ... and the handler is at the expected address.
> 
> ffffffff81044890 <trampoline_handler>:
> ffffffff81044890:       e8 ab c9 7b 00          callq  ffffffff81801240 <__fentry__>
> ffffffff81044895:       41 57                   push   %r15
> ffffffff81044897:       41 56                   push   %r14
> ffffffff81044899:       41 55                   push   %r13
> ffffffff8104489b:       49 89 fd                mov    %rdi,%r13
> 
> Dunno, if you feel like there might be some trouble with some compilers,
> I can keep the hunk below as a separate patch and revert it when it
> explodes somewhere...?

OK, then please remove it. :-) Even if any problem occurs, which must be
build error, so we can revert it in that case.

Thank you!

> 
> > Reviewed-by: Masami Hiramatsu <mhiramat@...nel.org>
> > 
> > Thank you,
> > 
> > > 
> > > ---
> > > diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
> > > index 6480056d370f..308bf103cc73 100644
> > > --- a/arch/x86/kernel/kprobes/core.c
> > > +++ b/arch/x86/kernel/kprobes/core.c
> > > @@ -66,8 +66,6 @@
> > >  
> > >  #include "common.h"
> > >  
> > > -void *trampoline_handler(struct pt_regs *regs);
> > > -
> > >  DEFINE_PER_CPU(struct kprobe *, current_kprobe) = NULL;
> > >  DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
> > >  
> > > @@ -753,7 +751,7 @@ STACK_FRAME_NON_STANDARD(kretprobe_trampoline);
> > >  /*
> > >   * Called from kretprobe_trampoline
> > >   */
> > > -__visible __used void *trampoline_handler(struct pt_regs *regs)
> > > +static __used void *trampoline_handler(struct pt_regs *regs)
> > >  {
> > >  	struct kretprobe_instance *ri = NULL;
> > >  	struct hlist_head *head, empty_rp;
> > > 
> > > -- 
> > > Regards/Gruss,
> > >     Boris.
> > > 
> > > Good mailing practices for 400: avoid top-posting and trim the reply.
> > 
> > 
> > -- 
> > Masami Hiramatsu <mhiramat@...nel.org>
> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> Good mailing practices for 400: avoid top-posting and trim the reply.


-- 
Masami Hiramatsu <mhiramat@...nel.org>