1. 15 9月, 2016 1 次提交
    • J
      cfg80211: allow connect keys only with default (TX) key · f1c1f17a
      Johannes Berg 提交于
      There's no point in allowing connect keys when one of them
      isn't also configured as the TX key, it would just confuse
      drivers and probably cause them to pick something for TX.
      Disallow this confusing and erroneous configuration.
      
      As wpa_supplicant will always send NL80211_ATTR_KEYS, even
      when there are no keys inside, allow that and treat it as
      though the attribute isn't present at all.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      f1c1f17a
  2. 14 9月, 2016 6 次提交
  3. 13 9月, 2016 3 次提交
  4. 12 9月, 2016 8 次提交
  5. 11 9月, 2016 21 次提交
  6. 10 9月, 2016 1 次提交
    • D
      bpf: add BPF_CALL_x macros for declaring helpers · f3694e00
      Daniel Borkmann 提交于
      This work adds BPF_CALL_<n>() macros and converts all the eBPF helper functions
      to use them, in a similar fashion like we do with SYSCALL_DEFINE<n>() macros
      that are used today. Motivation for this is to hide all the register handling
      and all necessary casts from the user, so that it is done automatically in the
      background when adding a BPF_CALL_<n>() call.
      
      This makes current helpers easier to review, eases to write future helpers,
      avoids getting the casting mess wrong, and allows for extending all helpers at
      once (f.e. build time checks, etc). It also helps detecting more easily in
      code reviews that unused registers are not instrumented in the code by accident,
      breaking compatibility with existing programs.
      
      BPF_CALL_<n>() internals are quite similar to SYSCALL_DEFINE<n>() ones with some
      fundamental differences, for example, for generating the actual helper function
      that carries all u64 regs, we need to fill unused regs, so that we always end up
      with 5 u64 regs as an argument.
      
      I reviewed several 0-5 generated BPF_CALL_<n>() variants of the .i results and
      they look all as expected. No sparse issue spotted. We let this also sit for a
      few days with Fengguang's kbuild test robot, and there were no issues seen. On
      s390, it barked on the "uses dynamic stack allocation" notice, which is an old
      one from bpf_perf_event_output{,_tp}() reappearing here due to the conversion
      to the call wrapper, just telling that the perf raw record/frag sits on stack
      (gcc with s390's -mwarn-dynamicstack), but that's all. Did various runtime tests
      and they were fine as well. All eBPF helpers are now converted to use these
      macros, getting rid of a good chunk of all the raw castings.
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f3694e00