Forum | Documentation | Website | Blog

Skip to content
Snippets Groups Projects
  1. Nov 12, 2021
  2. Nov 10, 2021
  3. Nov 01, 2021
  4. Oct 29, 2021
  5. Oct 28, 2021
  6. Oct 27, 2021
    • Robin H. Johnson's avatar
      tracing: Increase PERF_MAX_TRACE_SIZE to handle Sentinel1 and docker together · e531e90b
      Robin H. Johnson authored
      Running endpoint security solutions like Sentinel1 that use perf-based
      tracing heavily lead to this repeated dump complaining about dockerd.
      The default value of 2048 is nowhere near not large enough.
      
      Using the prior patch "tracing: show size of requested buffer", we get
      "perf buffer not large enough, wanted 6644, have 6144", after repeated
      up-sizing (I did 2/4/6/8K). With 8K, the problem doesn't occur at all,
      so below is the trace for 6K.
      
      I'm wondering if this value should be selectable at boot time, but this
      is a good starting point.
      
      ```
      ------------[ cut here ]------------
      perf buffer not large enough, wanted 6644, have 6144
      WARNING: CPU: 1 PID: 4997 at kernel/trace/trace_event_perf.c:402 perf_trace_buf_alloc+0x8c/0xa0
      Modules linked in: [..]
      CPU: 1 PID: 4997 Comm: sh Tainted: G                T 5.13.13-x86_64-00039-gb3959163488e #63
      Hardware name: LENOVO 20KH002JUS/20KH002JUS, BIOS N23ET66W (1.41 ) 09/02/2019
      RIP: 0010:perf_trace_buf_alloc+0x8c/0xa0
      Code: 80 3d 43 97 d0 01 00 74 07 31 c0 5b 5d 41 5c c3 ba 00 18 00 00 89 ee 48 c7 c7 00 82 7d 91 c6 05 25 97 d0 01 01 e8 22 ee bc 00 <0f> 0b 31 c0 eb db 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 55 89
      RSP: 0018:ffffb922026b7d58 EFLAGS: 00010282
      RAX: 0000000000000000 RBX: ffff9da5ee012000 RCX: 0000000000000027
      RDX: ffff9da881657828 RSI: 0000000000000001 RDI: ffff9da881657820
      RBP: 00000000000019f4 R08: 0000000000000000 R09: ffffb922026b7b80
      R10: ffffb922026b7b78 R11: ffffffff91dda688 R12: 000000000000000f
      R13: ffff9da5ee012108 R14: ffff9da8816570a0 R15: ffffb922026b7e30
      FS:  00007f420db1a080(0000) GS:ffff9da881640000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000060 CR3: 00000002504a8006 CR4: 00000000003706e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       kprobe_perf_func+0x11e/0x270
       ? do_execveat_common.isra.0+0x1/0x1c0
       ? do_execveat_common.isra.0+0x5/0x1c0
       kprobe_ftrace_handler+0x10e/0x1d0
       0xffffffffc03aa0c8
       ? do_execveat_common.isra.0+0x1/0x1c0
       do_execveat_common.isra.0+0x5/0x1c0
       __x64_sys_execve+0x33/0x40
       do_syscall_64+0x6b/0xc0
       ? do_syscall_64+0x11/0xc0
       entry_SYSCALL_64_after_hwframe+0x44/0xae
      RIP: 0033:0x7f420dc1db37
      Code: ff ff 76 e7 f7 d8 64 41 89 00 eb df 0f 1f 80 00 00 00 00 f7 d8 64 41 89 00 eb dc 0f 1f 84 00 00 00 00 00 b8 3b 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 01 43 0f 00 f7 d8 64 89 01 48
      RSP: 002b:00007ffd4e8b4e38 EFLAGS: 00000246 ORIG_RAX: 000000000000003b
      RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f420dc1db37
      RDX: 0000564338d1e740 RSI: 0000564338d32d50 RDI: 0000564338d28f00
      RBP: 0000564338d28f00 R08: 0000564338d32d50 R09: 0000000000000020
      R10: 00000000000001b6 R11: 0000000000000246 R12: 0000564338d28f00
      R13: 0000564338d32d50 R14: 0000564338d1e740 R15: 0000564338d28c60
      ---[ end trace 83ab3e8e16275e49 ]---
      ```
      
      Link: https://lkml.kernel.org/r/20210831043723.13481-2-robbat2@gentoo.org
      
      
      
      Signed-off-by: default avatarRobin H. Johnson <robbat2@gentoo.org>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      e531e90b
    • Robin H. Johnson's avatar
      tracing: Show size of requested perf buffer · a90afe8d
      Robin H. Johnson authored
      If the perf buffer isn't large enough, provide a hint about how large it
      needs to be for whatever is running.
      
      Link: https://lkml.kernel.org/r/20210831043723.13481-1-robbat2@gentoo.org
      
      
      
      Signed-off-by: default avatarRobin H. Johnson <robbat2@gentoo.org>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      a90afe8d
    • Steven Rostedt (VMware)'s avatar
      bootconfig: Initialize ret in xbc_parse_tree() · 39d9c1c1
      Steven Rostedt (VMware) authored
      The do while loop continues while ret is zero, but ret is never
      initialized. The check for ret in the loop at the while should always be
      initialized, but if an empty string were to be passed in, q would be NULL
      and p would be '\0', and it would break out of the loop without ever
      setting ret.
      
      Set ret to zero, and then xbc_verify_tree() would be called and catch that
      it is an empty tree and report the proper error.
      
      Link: https://lkml.kernel.org/r/20211027105753.6ab9da5f@gandalf.local.home
      
      Fixes: bdac5c2b
      
       ("bootconfig: Allocate xbc_data inside xbc_init()")
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Reported-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Acked-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      39d9c1c1
    • 王贇's avatar
      ftrace: do CPU checking after preemption disabled · d33cc657
      王贇 authored
      With CONFIG_DEBUG_PREEMPT we observed reports like:
      
        BUG: using smp_processor_id() in preemptible
        caller is perf_ftrace_function_call+0x6f/0x2e0
        CPU: 1 PID: 680 Comm: a.out Not tainted
        Call Trace:
         <TASK>
         dump_stack_lvl+0x8d/0xcf
         check_preemption_disabled+0x104/0x110
         ? optimize_nops.isra.7+0x230/0x230
         ? text_poke_bp_batch+0x9f/0x310
         perf_ftrace_function_call+0x6f/0x2e0
         ...
         __text_poke+0x5/0x620
         text_poke_bp_batch+0x9f/0x310
      
      This telling us the CPU could be changed after task is preempted, and
      the checking on CPU before preemption will be invalid.
      
      Since now ftrace_test_recursion_trylock() will help to disable the
      preemption, this patch just do the checking after trylock() to address
      the issue.
      
      Link: https://lkml.kernel.org/r/54880691-5fe2-33e7-d12f-1fa6136f5183@linux.alibaba.com
      
      
      
      CC: Steven Rostedt <rostedt@goodmis.org>
      Cc: Guo Ren <guoren@kernel.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
      Cc: Helge Deller <deller@gmx.de>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Paul Walmsley <paul.walmsley@sifive.com>
      Cc: Palmer Dabbelt <palmer@dabbelt.com>
      Cc: Albert Ou <aou@eecs.berkeley.edu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Jiri Kosina <jikos@kernel.org>
      Cc: Miroslav Benes <mbenes@suse.cz>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Joe Lawrence <joe.lawrence@redhat.com>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Cc: Jisheng Zhang <jszhang@kernel.org>
      Reported-by: default avatarAbaci <abaci@linux.alibaba.com>
      Signed-off-by: default avatarMichael Wang <yun.wang@linux.alibaba.com>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      d33cc657
    • 王贇's avatar
      ftrace: disable preemption when recursion locked · ce5e4803
      王贇 authored
      As the documentation explained, ftrace_test_recursion_trylock()
      and ftrace_test_recursion_unlock() were supposed to disable and
      enable preemption properly, however currently this work is done
      outside of the function, which could be missing by mistake.
      
      And since the internal using of trace_test_and_set_recursion()
      and trace_clear_recursion() also require preemption disabled, we
      can just merge the logical.
      
      This patch will make sure the preemption has been disabled when
      trace_test_and_set_recursion() return bit >= 0, and
      trace_clear_recursion() will enable the preemption if previously
      enabled.
      
      Link: https://lkml.kernel.org/r/13bde807-779c-aa4c-0672-20515ae365ea@linux.alibaba.com
      
      
      
      CC: Petr Mladek <pmladek@suse.com>
      Cc: Guo Ren <guoren@kernel.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
      Cc: Helge Deller <deller@gmx.de>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Paul Walmsley <paul.walmsley@sifive.com>
      Cc: Palmer Dabbelt <palmer@dabbelt.com>
      Cc: Albert Ou <aou@eecs.berkeley.edu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Jiri Kosina <jikos@kernel.org>
      Cc: Joe Lawrence <joe.lawrence@redhat.com>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Cc: Jisheng Zhang <jszhang@kernel.org>
      CC: Steven Rostedt <rostedt@goodmis.org>
      CC: Miroslav Benes <mbenes@suse.cz>
      Reported-by: default avatarAbaci <abaci@linux.alibaba.com>
      Suggested-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarMichael Wang <yun.wang@linux.alibaba.com>
      [ Removed extra line in comment - SDR ]
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      ce5e4803
  7. Oct 26, 2021