1. 31 Aug, 2019 23 commits
  2. 30 Aug, 2019 3 commits
    • Naveen N. Rao's avatar
      ftrace: Check for successful allocation of hash · 5b0022dd
      Naveen N. Rao authored
      In register_ftrace_function_probe(), we are not checking the return
      value of alloc_and_copy_ftrace_hash(). The subsequent call to
      ftrace_match_records() may end up dereferencing the same. Add a check to
      ensure this doesn't happen.
      
      Link: http://lkml.kernel.org/r/26e92574f25ad23e7cafa3cf5f7a819de1832cbe.1562249521.git.naveen.n.rao@linux.vnet.ibm.com
      
      Cc: stable@vger.kernel.org
      Fixes: 1ec3a81a ("ftrace: Have each function probe use its own ftrace_ops")
      Signed-off-by: default avatarNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      5b0022dd
    • Steven Rostedt (VMware)'s avatar
      ftrace: Check for empty hash and comment the race with registering probes · 372e0d01
      Steven Rostedt (VMware) authored
      The race between adding a function probe and reading the probes that exist
      is very subtle. It needs a comment. Also, the issue can also happen if the
      probe has has the EMPTY_HASH as its func_hash.
      
      Cc: stable@vger.kernel.org
      Fixes: 7b60f3d8 ("ftrace: Dynamically create the probe ftrace_ops for the trace_array")
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      372e0d01
    • Naveen N. Rao's avatar
      ftrace: Fix NULL pointer dereference in t_probe_next() · 7bd46644
      Naveen N. Rao authored
      LTP testsuite on powerpc results in the below crash:
      
        Unable to handle kernel paging request for data at address 0x00000000
        Faulting instruction address: 0xc00000000029d800
        Oops: Kernel access of bad area, sig: 11 [#1]
        LE SMP NR_CPUS=2048 NUMA PowerNV
        ...
        CPU: 68 PID: 96584 Comm: cat Kdump: loaded Tainted: G        W
        NIP:  c00000000029d800 LR: c00000000029dac4 CTR: c0000000001e6ad0
        REGS: c0002017fae8ba10 TRAP: 0300   Tainted: G        W
        MSR:  9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE>  CR: 28022422  XER: 20040000
        CFAR: c00000000029d90c DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 0
        ...
        NIP [c00000000029d800] t_probe_next+0x60/0x180
        LR [c00000000029dac4] t_mod_start+0x1a4/0x1f0
        Call Trace:
        [c0002017fae8bc90] [c000000000cdbc40] _cond_resched+0x10/0xb0 (unreliable)
        [c0002017fae8bce0] [c0000000002a15b0] t_start+0xf0/0x1c0
        [c0002017fae8bd30] [c0000000004ec2b4] seq_read+0x184/0x640
        [c0002017fae8bdd0] [c0000000004a57bc] sys_read+0x10c/0x300
        [c0002017fae8be30] [c00000000000b388] system_call+0x5c/0x70
      
      The test (ftrace_set_ftrace_filter.sh) is part of ftrace stress tests
      and the crash happens when the test does 'cat
      $TRACING_PATH/set_ftrace_filter'.
      
      The address points to the second line below, in t_probe_next(), where
      filter_hash is dereferenced:
        hash = iter->probe->ops.func_hash->filter_hash;
        size = 1 << hash->size_bits;
      
      This happens due to a race with register_ftrace_function_probe(). A new
      ftrace_func_probe is created and added into the func_probes list in
      trace_array under ftrace_lock. However, before initializing the filter,
      we drop ftrace_lock, and re-acquire it after acquiring regex_lock. If
      another process is trying to read set_ftrace_filter, it will be able to
      acquire ftrace_lock during this window and it will end up seeing a NULL
      filter_hash.
      
      Fix this by just checking for a NULL filter_hash in t_probe_next(). If
      the filter_hash is NULL, then this probe is just being added and we can
      simply return from here.
      
      Link: http://lkml.kernel.org/r/05e021f757625cbbb006fad41380323dbe4e3b43.1562249521.git.naveen.n.rao@linux.vnet.ibm.com
      
      Cc: stable@vger.kernel.org
      Fixes: 7b60f3d8 ("ftrace: Dynamically create the probe ftrace_ops for the trace_array")
      Signed-off-by: default avatarNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      7bd46644
  3. 25 Aug, 2019 14 commits