1. 12 7月, 2017 5 次提交
  2. 09 7月, 2017 1 次提交
  3. 08 7月, 2017 1 次提交
  4. 07 7月, 2017 3 次提交
  5. 06 7月, 2017 1 次提交
  6. 05 7月, 2017 1 次提交
  7. 03 7月, 2017 2 次提交
    • J
      bpf: extend bpf_trace_printk to support %i · 7bda4b40
      John Fastabend 提交于
      Currently, bpf_trace_printk does not support common formatting
      symbol '%i' however vsprintf does and is what eventually gets
      called by bpf helper. If users are used to '%i' and currently
      make use of it, then bpf_trace_printk will just return with
      error without dumping anything to the trace pipe, so just add
      support for '%i' to the helper.
      Signed-off-by: NJohn Fastabend <john.fastabend@gmail.com>
      Acked-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7bda4b40
    • D
      bpf: simplify narrower ctx access · f96da094
      Daniel Borkmann 提交于
      This work tries to make the semantics and code around the
      narrower ctx access a bit easier to follow. Right now
      everything is done inside the .is_valid_access(). Offset
      matching is done differently for read/write types, meaning
      writes don't support narrower access and thus matching only
      on offsetof(struct foo, bar) is enough whereas for read
      case that supports narrower access we must check for
      offsetof(struct foo, bar) + offsetof(struct foo, bar) +
      sizeof(<bar>) - 1 for each of the cases. For read cases of
      individual members that don't support narrower access (like
      packet pointers or skb->cb[] case which has its own narrow
      access logic), we check as usual only offsetof(struct foo,
      bar) like in write case. Then, for the case where narrower
      access is allowed, we also need to set the aux info for the
      access. Meaning, ctx_field_size and converted_op_size have
      to be set. First is the original field size e.g. sizeof(<bar>)
      as in above example from the user facing ctx, and latter
      one is the target size after actual rewrite happened, thus
      for the kernel facing ctx. Also here we need the range match
      and we need to keep track changing convert_ctx_access() and
      converted_op_size from is_valid_access() as both are not at
      the same location.
      
      We can simplify the code a bit: check_ctx_access() becomes
      simpler in that we only store ctx_field_size as a meta data
      and later in convert_ctx_accesses() we fetch the target_size
      right from the location where we do convert. Should the verifier
      be misconfigured we do reject for BPF_WRITE cases or target_size
      that are not provided. For the subsystems, we always work on
      ranges in is_valid_access() and add small helpers for ranges
      and narrow access, convert_ctx_accesses() sets target_size
      for the relevant instruction.
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NJohn Fastabend <john.fastabend@gmail.com>
      Cc: Yonghong Song <yhs@fb.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f96da094
  8. 30 6月, 2017 1 次提交
  9. 29 6月, 2017 1 次提交
    • S
      ftrace: Fix regression with module command in stack_trace_filter · 0f179765
      Steven Rostedt (VMware) 提交于
      When doing the following command:
      
       # echo ":mod:kvm_intel" > /sys/kernel/tracing/stack_trace_filter
      
      it triggered a crash.
      
      This happened with the clean up of probes. It required all callers to the
      regex function (doing ftrace filtering) to have ops->private be a pointer to
      a trace_array. But for the stack tracer, that is not the case.
      
      Allow for the ops->private to be NULL, and change the function command
      callbacks to handle the trace_array pointer being NULL as well.
      
      Fixes: d2afd57a ("tracing/ftrace: Allow instances to have their own function probes")
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      0f179765
  10. 28 6月, 2017 6 次提交
  11. 26 6月, 2017 4 次提交
    • S
      ftrace: Have cached module filters be an active filter · 8c08f0d5
      Steven Rostedt (VMware) 提交于
      When a module filter is added to set_ftrace_filter, if the module is not
      loaded, it is cached. This should be considered an active filter, and
      function tracing should be filtered by this. That is, if a cached module
      filter is the only filter set, then no function tracing should be happening,
      as all the functions available will be filtered out.
      
      This makes sense, as the reason to add a cached module filter, is to trace
      the module when you load it. There shouldn't be any other tracing happening
      until then.
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      8c08f0d5
    • S
      ftrace: Implement cached modules tracing on module load · d7fbf8df
      Steven Rostedt (VMware) 提交于
      If a module is cached in the set_ftrace_filter, and that module is loaded,
      then enable tracing on that module as if the cached module text was written
      into set_ftrace_filter just as the module is loaded.
      
        # echo ":mod:kvm_intel" >
        # cat /sys/kernel/tracing/set_ftrace_filter
       #### all functions enabled ####
       :mod:kvm_intel
        # modprobe kvm_intel
        # cat /sys/kernel/tracing/set_ftrace_filter
       vmx_get_rflags [kvm_intel]
       vmx_get_pkru [kvm_intel]
       vmx_get_interrupt_shadow [kvm_intel]
       vmx_rdtscp_supported [kvm_intel]
       vmx_invpcid_supported [kvm_intel]
       [..]
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      d7fbf8df
    • S
      ftrace: Have the cached module list show in set_ftrace_filter · 5985ea8b
      Steven Rostedt (VMware) 提交于
      When writing in a module filter into set_ftrace_filter for a module that is
      not yet loaded, it it cached, and will be executed when the module is loaded
      (although that is not implemented yet at this commit). Display the list of
      cached modules to be traced.
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      5985ea8b
    • S
      ftrace: Add :mod: caching infrastructure to trace_array · 673feb9d
      Steven Rostedt (VMware) 提交于
      This is the start of the infrastructure work to allow for tracing module
      functions before it is loaded.
      
      Currently the following command:
      
        # echo :mod:some-mod > set_ftrace_filter
      
      will enable tracing of all functions within the module "some-mod" if it is
      loaded. What we want, is if the module is not loaded, that line will be
      saved. When the module is loaded, then the "some-mod" will have that line
      executed on it, so that the functions within it starts being traced.
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      673feb9d
  12. 24 6月, 2017 1 次提交
    • Y
      bpf: possibly avoid extra masking for narrower load in verifier · 23994631
      Yonghong Song 提交于
      Commit 31fd8581 ("bpf: permits narrower load from bpf program
      context fields") permits narrower load for certain ctx fields.
      The commit however will already generate a masking even if
      the prog-specific ctx conversion produces the result with
      narrower size.
      
      For example, for __sk_buff->protocol, the ctx conversion
      loads the data into register with 2-byte load.
      A narrower 2-byte load should not generate masking.
      For __sk_buff->vlan_present, the conversion function
      set the result as either 0 or 1, essentially a byte.
      The narrower 2-byte or 1-byte load should not generate masking.
      
      To avoid unnecessary masking, prog-specific *_is_valid_access
      now passes converted_op_size back to verifier, which indicates
      the valid data width after perceived future conversion.
      Based on this information, verifier is able to avoid
      unnecessary marking.
      
      Since we want more information back from prog-specific
      *_is_valid_access checking, all of them are packed into
      one data structure for more clarity.
      Acked-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      23994631
  13. 23 6月, 2017 1 次提交
    • S
      tracing: Show address when function names are not found · feaf1283
      Steven Rostedt (VMware) 提交于
      Currently, when a function is not found in kallsyms, instead of simply
      showing the function address, it shows nothing at all:
      
       # echo ':mod:kvm_intel' > /sys/kernel/tracing/set_ftrace_filter
       # echo function > /sys/kernel/tracing/set_ftrace_filter
       # qemu -enable-kvm /home/my-qemu-image
         <Ctrl-C>
       # rmmod kvm_intel
       # cat /sys/kernel/tracing/trace
       qemu-system-x86-2408  [001] d..2   135.013238:  <-kvm_arch_hardware_enable
       qemu-system-x86-2408  [001] ....   135.014574:  <-kvm_arch_vm_ioctl
       qemu-system-x86-2408  [001] ....   135.015420:  <-kvm_vm_ioctl_check_extension
       qemu-system-x86-2408  [001] ....   135.045411:  <-__do_cpuid_ent
       qemu-system-x86-2408  [001] ....   135.045412:  <-__do_cpuid_ent
       qemu-system-x86-2408  [001] ....   135.045412:  <-__do_cpuid_ent
       qemu-system-x86-2408  [001] ....   135.045412:  <-__do_cpuid_ent
       qemu-system-x86-2408  [001] ...1   135.045413:  <-__do_cpuid_ent
       qemu-system-x86-2408  [001] ....   135.045413:  <-__do_cpuid_ent
      
      When it should show:
      
       qemu-system-x86-2408  [001] d..2   135.013238: 0xffffffffa02a39f0 <-kvm_arch_hardware_enable
       qemu-system-x86-2408  [001] ....   135.014574: 0xffffffffa02a2ba0 <-kvm_arch_vm_ioctl
       qemu-system-x86-2408  [001] ....   135.015420: 0xffffffffa029e4e0 <-kvm_vm_ioctl_check_extension
       qemu-system-x86-2408  [001] ....   135.045411: 0xffffffffa02a1380 <-__do_cpuid_ent
       qemu-system-x86-2408  [001] ....   135.045412: 0xffffffffa029e160 <-__do_cpuid_ent
       qemu-system-x86-2408  [001] ....   135.045412: 0xffffffffa029e180 <-__do_cpuid_ent
       qemu-system-x86-2408  [001] ....   135.045412: 0xffffffffa029e520 <-__do_cpuid_ent
       qemu-system-x86-2408  [001] ...1   135.045413: 0xffffffffa02a13b0 <-__do_cpuid_ent
       qemu-system-x86-2408  [001] ....   135.045413: 0xffffffffa02a1380 <-__do_cpuid_ent
      
      instead.
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      feaf1283
  14. 15 6月, 2017 1 次提交
    • Y
      bpf: permits narrower load from bpf program context fields · 31fd8581
      Yonghong Song 提交于
      Currently, verifier will reject a program if it contains an
      narrower load from the bpf context structure. For example,
              __u8 h = __sk_buff->hash, or
              __u16 p = __sk_buff->protocol
              __u32 sample_period = bpf_perf_event_data->sample_period
      which are narrower loads of 4-byte or 8-byte field.
      
      This patch solves the issue by:
        . Introduce a new parameter ctx_field_size to carry the
          field size of narrower load from prog type
          specific *__is_valid_access validator back to verifier.
        . The non-zero ctx_field_size for a memory access indicates
          (1). underlying prog type specific convert_ctx_accesses
               supporting non-whole-field access
          (2). the current insn is a narrower or whole field access.
        . In verifier, for such loads where load memory size is
          less than ctx_field_size, verifier transforms it
          to a full field load followed by proper masking.
        . Currently, __sk_buff and bpf_perf_event_data->sample_period
          are supporting narrowing loads.
        . Narrower stores are still not allowed as typical ctx stores
          are just normal stores.
      
      Because of this change, some tests in verifier will fail and
      these tests are removed. As a bonus, rename some out of bound
      __sk_buff->cb access to proper field name and remove two
      redundant "skb cb oob" tests.
      Acked-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      31fd8581
  15. 14 6月, 2017 9 次提交
  16. 13 6月, 2017 1 次提交
  17. 11 6月, 2017 1 次提交