1. 23 Jan, 2020 26 commits
  2. 22 Jan, 2020 10 commits
  3. 21 Jan, 2020 2 commits
    • Jeff Layton's avatar
      ceph: hold extra reference to r_parent over life of request · 9c1c2b35
      Jeff Layton authored
      Currently, we just assume that it will stick around by virtue of the
      submitter's reference, but later patches will allow the syscall to
      return early and we can't rely on that reference at that point.
      
      While I'm not aware of any reports of it, Xiubo pointed out that this
      may fix a use-after-free.  If the wait for a reply times out or is
      canceled via signal, and then the reply comes in after the syscall
      returns, the client can end up trying to access r_parent without a
      reference.
      
      Take an extra reference to the inode when setting r_parent and release
      it when releasing the request.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJeff Layton <jlayton@kernel.org>
      Reviewed-by: default avatar"Yan, Zheng" <zyan@redhat.com>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      9c1c2b35
    • Eugene Syromiatnikov's avatar
      io_uring: fix compat for IORING_REGISTER_FILES_UPDATE · 1292e972
      Eugene Syromiatnikov authored
      fds field of struct io_uring_files_update is problematic with regards
      to compat user space, as pointer size is different in 32-bit, 32-on-64-bit,
      and 64-bit user space.  In order to avoid custom handling of compat in
      the syscall implementation, make fds __u64 and use u64_to_user_ptr in
      order to retrieve it.  Also, align the field naturally and check that
      no garbage is passed there.
      
      Fixes: c3a31e60 ("io_uring: add support for IORING_REGISTER_FILES_UPDATE")
      Signed-off-by: default avatarEugene Syromiatnikov <esyr@redhat.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      1292e972
  4. 20 Jan, 2020 2 commits
    • Masami Ichikawa's avatar
      tracing: Do not set trace clock if tracefs lockdown is in effect · bf24daac
      Masami Ichikawa authored
      When trace_clock option is not set and unstable clcok detected,
      tracing_set_default_clock() sets trace_clock(ThinkPad A285 is one of
      case). In that case, if lockdown is in effect, null pointer
      dereference error happens in ring_buffer_set_clock().
      
      Link: http://lkml.kernel.org/r/20200116131236.3866925-1-masami256@gmail.com
      
      Cc: stable@vger.kernel.org
      Fixes: 17911ff3 ("tracing: Add locked_down checks to the open calls of files created for tracefs")
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1788488Signed-off-by: default avatarMasami Ichikawa <masami256@gmail.com>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      bf24daac
    • Steven Rostedt (VMware)'s avatar
      tracing: Fix histogram code when expression has same var as value · 8bcebc77
      Steven Rostedt (VMware) authored
      While working on a tool to convert SQL syntex into the histogram language of
      the kernel, I discovered the following bug:
      
       # echo 'first u64 start_time u64 end_time pid_t pid u64 delta' >> synthetic_events
       # echo 'hist:keys=pid:start=common_timestamp' > events/sched/sched_waking/trigger
       # echo 'hist:keys=next_pid:delta=common_timestamp-$start,start2=$start:onmatch(sched.sched_waking).trace(first,$start2,common_timestamp,next_pid,$delta)' > events/sched/sched_switch/trigger
      
      Would not display any histograms in the sched_switch histogram side.
      
      But if I were to swap the location of
      
        "delta=common_timestamp-$start" with "start2=$start"
      
      Such that the last line had:
      
       # echo 'hist:keys=next_pid:start2=$start,delta=common_timestamp-$start:onmatch(sched.sched_waking).trace(first,$start2,common_timestamp,next_pid,$delta)' > events/sched/sched_switch/trigger
      
      The histogram works as expected.
      
      What I found out is that the expressions clear out the value once it is
      resolved. As the variables are resolved in the order listed, when
      processing:
      
        delta=common_timestamp-$start
      
      The $start is cleared. When it gets to "start2=$start", it errors out with
      "unresolved symbol" (which is silent as this happens at the location of the
      trace), and the histogram is dropped.
      
      When processing the histogram for variable references, instead of adding a
      new reference for a variable used twice, use the same reference. That way,
      not only is it more efficient, but the order will no longer matter in
      processing of the variables.
      
      From Tom Zanussi:
      
       "Just to clarify some more about what the problem was is that without
        your patch, we would have two separate references to the same variable,
        and during resolve_var_refs(), they'd both want to be resolved
        separately, so in this case, since the first reference to start wasn't
        part of an expression, it wouldn't get the read-once flag set, so would
        be read normally, and then the second reference would do the read-once
        read and also be read but using read-once.  So everything worked and
        you didn't see a problem:
      
         from: start2=$start,delta=common_timestamp-$start
      
        In the second case, when you switched them around, the first reference
        would be resolved by doing the read-once, and following that the second
        reference would try to resolve and see that the variable had already
        been read, so failed as unset, which caused it to short-circuit out and
        not do the trigger action to generate the synthetic event:
      
         to: delta=common_timestamp-$start,start2=$start
      
        With your patch, we only have the single resolution which happens
        correctly the one time it's resolved, so this can't happen."
      
      Link: https://lore.kernel.org/r/20200116154216.58ca08eb@gandalf.local.home
      
      Cc: stable@vger.kernel.org
      Fixes: 067fe038 ("tracing: Add variable reference handling to hist triggers")
      Reviewed-by: default avatarTom Zanuss <zanussi@kernel.org>
      Tested-by: default avatarTom Zanussi <zanussi@kernel.org>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      8bcebc77