Re: BUG due to mm-instrumentation

Jan Kiszka wrote:
> The second point is that I didn't want tracing for this build at all.
> But looking at the disassembly,
> 
> ffffffff802c78f1:       e8 ba 15 f7 ff          callq  ffffffff80238eb0 <printk>
> ffffffff802c78f6:       e8 ac 67 f4 ff          callq  ffffffff8020e0a7 <dump_stack>
> ffffffff802c78fb:       e8 ef d1 f5 ff          callq  ffffffff80224aef <show_mem>
> ffffffff802c7900:       48 8b 7d b0             mov    -0x50(%rbp),%rdi
> ffffffff802c7904:       e8 63 d3 ff ff          callq  ffffffff802c4c6c <page_to_pfn>
> ffffffff802c7909:       48 8b 45 b0             mov    -0x50(%rbp),%rax
> ffffffff802c790d:       48 83 c4 58             add    $0x58,%rsp
> ffffffff802c7911:       5b                      pop    %rbx
> ffffffff802c7912:       41 5c                   pop    %r12
> ffffffff802c7914:       41 5d                   pop    %r13
> ffffffff802c7916:       41 5e                   pop    %r14
> ffffffff802c7918:       41 5f                   pop    %r15
> ffffffff802c791a:       c9                      leaveq
> ffffffff802c791b:       c3                      retq
> 
> we see a useless page_to_pfn call. Is this is due to
> __mark_check_format, trying to match format against arguments even
> without CONFIG_MARKERS? Compiler issue?

Actually, this is nothing to blame the compiler for: page_to_pfn may
have side-effects, so simply not calling it would be wrong. Hmm...

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux