Re: [BUGFIX PATCH 1/4] perf probe: Skip end-of-sequence and non statement lines

[Masami Hiramatsu]

Hi Tommi,

Thank you for reporting!

On Fri, 10 Jan 2020 09:29:22 +0000
"Rantala, Tommi T. (Nokia - FI/Espoo)" <tommi.t.rantala@xxxxxxxxx> wrote:

> 
> Hello,
> 
> I'm getting perf test failures after this patch hit mainline and LTS
> kernels.
> 
> With v5.5-rc5 (x86_64 gcc-9.2.1) I get:
> 
>  # perf test
>  ...
>  69: Add vfs_getname probe to get syscall args filenames   : FAILED!
>  71: Use vfs_getname probe to get syscall args filenames   : FAILED!
>  73: Check open filename arg using perf trace + vfs_getname: FAILED!
> 
> Reason is that it's no longer possible to add probe in getname_flags()
> line "result->uptr = filename;", and this is causing the perf tests to
> fail:
> 
> # perf probe -L getname_flags
> <getname_flags@/root/linux-core2/fs/namei.c:0>
>       0  getname_flags(const char __user *filename, int flags, int *empty)
>          {
> ...
>      61         result->refcnt = 1;
>                 /* The empty path is special. */
>      63         if (unlikely(!len)) {
>      64                 if (empty)
>      65                         *empty = 1;
>      66                 if (!(flags & LOOKUP_EMPTY)) {
>      67                         putname(result);
>      68                         return ERR_PTR(-ENOENT);
>                         }
>                 }
>          
>                 result->uptr = filename;
>      73         result->aname = NULL;
>                 audit_getname(result);
>                 return result;
>          }
> 
> 
> I can reproduce it locally with a kernel config change (with attached KVM
> guest config): when kernel is built with CONFIG_MCORE2=y the issue
> reproduces. When switching to CONFIG_GENERIC_CPU=y it's again possible to
> add the probe to the source line and the tests pass.
> 
> Diffing the disassembly of fs/namei.o between CONFIG_MCORE2=y and
> CONFIG_GENERIC_CPU=y, all instructions in getname_flags() are the same,
> but there are some changes in the instruction ordering.
> 
> Any ideas what's going wrong here...?
> Something wrong in the dwarf data?

Hmm, I guess gcc's dwarf generator gets some effects from the optimizer.
Maybe since the optimizer reordering the insturction, the dwarf generator
might lose the line statement information. For example, if instructions
from different lines are mixed, it is hard to say "this is the begining
of a line".

> 
> In 4.19.y it's enough to revert this patch ("perf probe: Skip end-of-
> sequence and non statement lines") to fix this (assuming it's bug...), but
> in v5.5-rc5 it's not enough (switching to v5.4 perf fixed it).

I think perf test should be fixed to use more stable lines.
(But I'm not sure why it uses this line...)

Thank you,


-- 
Masami Hiramatsu <mhiramat@xxxxxxxxxx>