linux-kernel - Re: ftrace: function radeon

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: <20200511193028.3551d838@oasis.local.home>
Date:   Mon, 11 May 2020 19:30:28 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Paul Menzel <pmenzel@...gen.mpg.de>
Cc:     Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: ftrace: function radeon_init not traceable

On Tue, 12 May 2020 01:07:44 +0200
Paul Menzel <pmenzel@...gen.mpg.de> wrote:

> >>
> >>       initcall_debug log_buf_len=32M trace_buf_size=57074K trace_clock=global trace_options=nooverwrite,funcgraph-abstime,funcgraph-cpu,funcgraph-duration,funcgraph-proc,funcgraph-tail,nofuncgraph-overhead,context-info,graph-time ftrace=function_graph ftrace_graph_max_depth=1 ftrace_graph_filter=radeon_init
> >>
> >> But ftrace “rejects” that:
> >>
> >>       [    0.075538] ftrace: allocating 30958 entries in 61 pages
> >>       [    0.084542] ftrace: allocated 61 pages with 5 groups
> >>       [    0.094184] ftrace: function radeon_init not traceable
> >>
> >> I believe it worked in the past. Is there a way to trace that init function?  
> > 
> > Did it every work for modules? radeon_init() isn't in the symbol table at
> > boot up.
> > 
> > [   15.066951] systemd-journald[124]: Successfully sent stream file descriptor to service manager.
> > [   15.098265] hub 1-0:1.0: USB hub found
> > [   15.104006] systemd-journald[124]: Successfully sent stream file descriptor to service manager.
> > [   15.112965] hub 1-0:1.0: 2 ports detected
> > [   15.118116] probe of 1-0:1.0 returned 1 after 19873 usecs
> > [   15.124007] calling  radeon_init+0x0/0x1000 [radeon] @ 133
> > 
> > The radeon_init is called after systemd is running, so it is definitely
> > from a module.
> > 
> > Perhaps you had it built in before?  
> 
> You are right. Probably I did. Can you suggest how to set up ftrace to 
> trace a module?

In recent kernels there was a feature to function trace modules before
they are loaded, but that feature isn't yet available on mainline. I
could add it when I get a chance, but that wont be in the near future.

Also, the function graph wont work for that either, as that isn't set
up to preload before functions. But since you have
ftrace_graph_max_depth of one, you don't need the graph, the limiting
of the function (set_ftrace_filter) is good enough. But again, that
only works after boot up.

> > 
> > Probably because the filtering failed, so there is no filter.  
> 
> Is that the intended behavior? Or should nothing be traced?

Well, it's just like writing something not acceptable in the filter
functions. If it fails, it does not filter. So yes, it is expected
behavior.

-- Steve