1. 09 Sep, 2017 16 commits
    • Daniel Borkmann's avatar
      bpf: make error reporting in bpf_warn_invalid_xdp_action more clear · 9beb8bed
      Daniel Borkmann authored
      Differ between illegal XDP action code and just driver
      unsupported one to provide better feedback when we throw
      a one-time warning here. Reason is that with 814abfab
      ("xdp: add bpf_redirect helper function") not all drivers
      support the new XDP return code yet and thus they will
      fall into their 'default' case when checking for return
      codes after program return, which then triggers a
      bpf_warn_invalid_xdp_action() stating that the return
      code is illegal, but from XDP perspective it's not.
      I decided not to place something like a XDP_ACT_MAX define
      into uapi i) given we don't have this either for all other
      program types, ii) future action codes could have further
      encoding there, which would render such define unsuitable
      and we wouldn't be able to rip it out again, and iii) we
      rarely add new action codes.
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Florian Fainelli's avatar
      Revert "mdio_bus: Remove unneeded gpiod NULL check" · a010a2f6
      Florian Fainelli authored
      This reverts commit 95b80bf3 ("mdio_bus:
      Remove unneeded gpiod NULL check"), this commit assumed that GPIOLIB
      checks for NULL descriptors, so it's safe to drop them, but it is not
      when CONFIG_GPIOLIB is disabled in the kernel. If we do call
      gpiod_set_value_cansleep() on a GPIO descriptor we will issue warnings
      coming from the inline stubs declared in include/linux/gpio/consumer.h.
      Fixes: 95b80bf3
       ("mdio_bus: Remove unneeded gpiod NULL check")
      Reported-by: default avatarWoojung Huh <Woojung.Huh@microchip.com>
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Acked-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • David S. Miller's avatar
      Merge branch 'xdp-bpf-fixes' · a7bc5774
      David S. Miller authored
      John Fastabend says:
      net: Fixes for XDP/BPF
      The following fixes, UAPI updates, and small improvement,
      i. XDP needs to be called inside RCU with preempt disabled.
      ii. Not strictly a bug fix but we have an attach command in the
      sockmap UAPI already to avoid having a single kernel released with
      only the attach and not the detach I'm pushing this into net branch.
      Its early in the RC cycle so I think this is OK (not ideal but better
      than supporting a UAPI with a missing detach forever).
      iii. Final patch replace cpu_relax with cond_resched in devmap.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • John Fastabend's avatar
      bpf: devmap, use cond_resched instead of cpu_relax · 374fb014
      John Fastabend authored
      Be a bit more friendly about waiting for flush bits to complete.
      Replace the cpu_relax() with a cond_resched().
      Suggested-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • John Fastabend's avatar
      bpf: add support for sockmap detach programs · 5a67da2a
      John Fastabend authored
      The bpf map sockmap supports adding programs via attach commands. This
      patch adds the detach command to keep the API symmetric and allow
      users to remove previously added programs. Otherwise the user would
      have to delete the map and re-add it to get in this state.
      This also adds a series of additional tests to capture detach operation
      and also attaching/detaching invalid prog types.
      API note: socks will run (or not run) programs depending on the state
      of the map at the time the sock is added. We do not for example walk
      the map and remove programs from previously attached socks.
      Acked-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • John Fastabend's avatar
      net: rcu lock and preempt disable missing around generic xdp · bbbe211c
      John Fastabend authored
      do_xdp_generic must be called inside rcu critical section with preempt
      disabled to ensure BPF programs are valid and per-cpu variables used
      for redirect operations are consistent. This patch ensures this is true
      and fixes the splat below.
      The netif_receive_skb_internal() code path is now broken into two rcu
      critical sections. I decided it was better to limit the preempt_enable/disable
      block to just the xdp static key portion and the fallout is more
      rcu_read_lock/unlock calls. Seems like the best option to me.
      [  607.596901] =============================
      [  607.596906] WARNING: suspicious RCU usage
      [  607.596912] 4.13.0-rc4+ #570 Not tainted
      [  607.596917] -----------------------------
      [  607.596923] net/core/dev.c:3948 suspicious rcu_dereference_check() usage!
      [  607.596927]
      [  607.596927] other info that might help us debug this:
      [  607.596927]
      [  607.596933]
      [  607.596933] rcu_scheduler_active = 2, debug_locks = 1
      [  607.596938] 2 locks held by pool/14624:
      [  607.596943]  #0:  (rcu_read_lock_bh){......}, at: [<ffffffff95445ffd>] ip_finish_output2+0x14d/0x890
      [  607.596973]  #1:  (rcu_read_lock_bh){......}, at: [<ffffffff953c8e3a>] __dev_queue_xmit+0x14a/0xfd0
      [  607.597000]
      [  607.597000] stack backtrace:
      [  607.597006] CPU: 5 PID: 14624 Comm: pool Not tainted 4.13.0-rc4+ #570
      [  607.597011] Hardware name: Dell Inc. Precision Tower 5810/0HHV7N, BIOS A17 03/01/2017
      [  607.597016] Call Trace:
      [  607.597027]  dump_stack+0x67/0x92
      [  607.597040]  lockdep_rcu_suspicious+0xdd/0x110
      [  607.597054]  do_xdp_generic+0x313/0xa50
      [  607.597068]  ? time_hardirqs_on+0x5b/0x150
      [  607.597076]  ? mark_held_locks+0x6b/0xc0
      [  607.597088]  ? netdev_pick_tx+0x150/0x150
      [  607.597117]  netif_rx_internal+0x205/0x3f0
      [  607.597127]  ? do_xdp_generic+0xa50/0xa50
      [  607.597144]  ? lock_downgrade+0x2b0/0x2b0
      [  607.597158]  ? __lock_is_held+0x93/0x100
      [  607.597187]  netif_rx+0x119/0x190
      [  607.597202]  loopback_xmit+0xfd/0x1b0
      [  607.597214]  dev_hard_start_xmit+0x127/0x4e0
      Fixes: d4455169 ("net: xdp: support xdp generic on virtual devices")
      Fixes: b5cdae32
       ("net: Generic XDP")
      Acked-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Daniel Borkmann's avatar
      bpf: don't select potentially stale ri->map from buggy xdp progs · 109980b8
      Daniel Borkmann authored
      We can potentially run into a couple of issues with the XDP
      bpf_redirect_map() helper. The ri->map in the per CPU storage
      can become stale in several ways, mostly due to misuse, where
      we can then trigger a use after free on the map:
      i) prog A is calling bpf_redirect_map(), returning XDP_REDIRECT
      and running on a driver not supporting XDP_REDIRECT yet. The
      ri->map on that CPU becomes stale when the XDP program is unloaded
      on the driver, and a prog B loaded on a different driver which
      supports XDP_REDIRECT return code. prog B would have to omit
      calling to bpf_redirect_map() and just return XDP_REDIRECT, which
      would then access the freed map in xdp_do_redirect() since not
      cleared for that CPU.
      ii) prog A is calling bpf_redirect_map(), returning a code other
      than XDP_REDIRECT. prog A is then detached, which triggers release
      of the map. prog B is attached which, similarly as in i), would
      just return XDP_REDIRECT without having called bpf_redirect_map()
      and thus be accessing the freed map in xdp_do_redirect() since
      not cleared for that CPU.
      iii) prog A is attached to generic XDP, calling the bpf_redirect_map()
      helper and returning XDP_REDIRECT. xdp_do_generic_redirect() is
      currently not handling ri->map (will be fixed by Jesper), so it's
      not being reset. Later loading a e.g. native prog B which would,
      say, call bpf_xdp_redirect() and then returns XDP_REDIRECT would
      find in xdp_do_redirect() that a map was set and uses that causing
      use after free on map access.
      Fix thus needs to avoid accessing stale ri->map pointers, naive
      way would be to call a BPF function from drivers that just resets
      it to NULL for all XDP return codes but XDP_REDIRECT and including
      XDP_REDIRECT for drivers not supporting it yet (and let ri->map
      being handled in xdp_do_generic_redirect()). There is a less
      intrusive way w/o letting drivers call a reset for each BPF run.
      The verifier knows we're calling into bpf_xdp_redirect_map()
      helper, so it can do a small insn rewrite transparent to the prog
      itself in the sense that it fills R4 with a pointer to the own
      bpf_prog. We have that pointer at verification time anyway and
      R4 is allowed to be used as per calling convention we scratch
      R0 to R5 anyway, so they become inaccessible and program cannot
      read them prior to a write. Then, the helper would store the prog
      pointer in the current CPUs struct redirect_info. Later in
      xdp_do_*_redirect() we check whether the redirect_info's prog
      pointer is the same as passed xdp_prog pointer, and if that's
      the case then all good, since the prog holds a ref on the map
      anyway, so it is always valid at that point in time and must
      have a reference count of at least 1. If in the unlikely case
      they are not equal, it means we got a stale pointer, so we clear
      and bail out right there. Also do reset map and the owning prog
      in bpf_xdp_redirect(), so that bpf_xdp_redirect_map() and
      bpf_xdp_redirect() won't get mixed up, only the last call should
      take precedence. A tc bpf_redirect() doesn't use map anywhere
      yet, so no need to clear it there since never accessed in that
      Note that in case the prog is released, and thus the map as
      well we're still under RCU read critical section at that time
      and have preemption disabled as well. Once we commit with the
      __dev_map_insert_ctx() from xdp_do_redirect_map() and set the
      map to ri->map_to_flush, we still wait for a xdp_do_flush_map()
      to finish in devmap dismantle time once flush_needed bit is set,
      so that is fine.
      Fixes: 97f91a7c
       ("bpf: add bpf_redirect_map helper routine")
      Reported-by: default avatarJesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Kees Cook's avatar
      net: tulip: Constify tulip_tbl · 9a486c9d
      Kees Cook authored
      It looks like all users of tulip_tbl are reads, so mark this table
      as read-only.
      $ git grep tulip_tbl  # edited to avoid line-wraps...
      interrupt.c: iowrite32(tulip_tbl[tp->chip_id].valid_intrs, ...
      interrupt.c: iowrite32(tulip_tbl[tp->chip_id].valid_intrs&~RxPollInt, ...
      interrupt.c: iowrite32(tulip_tbl[tp->chip_id].valid_intrs, ...
      interrupt.c: iowrite32(tulip_tbl[tp->chip_id].valid_intrs | TimerInt,
      pnic.c:      iowrite32(tulip_tbl[tp->chip_id].valid_intrs, ioaddr + CSR7);
      tulip.h:     extern struct tulip_chip_table tulip_tbl[];
      tulip_core.c:struct tulip_chip_table tulip_tbl[] = {
      tulip_core.c:iowrite32(tulip_tbl[tp->chip_id].valid_intrs, ioaddr + CSR5);
      tulip_core.c:iowrite32(tulip_tbl[tp->chip_id].valid_intrs, ioaddr + CSR7);
      tulip_core.c:setup_timer(&tp->timer, tulip_tbl[tp->chip_id].media_timer,
      tulip_core.c:const char *chip_name = tulip_tbl[chip_idx].chip_name;
      tulip_core.c:if (pci_resource_len (pdev, 0) < tulip_tbl[chip_idx].io_size)
      tulip_core.c:ioaddr =  pci_iomap(..., tulip_tbl[chip_idx].io_size);
      tulip_core.c:tp->flags = tulip_tbl[chip_idx].flags;
      tulip_core.c:setup_timer(&tp->timer, tulip_tbl[tp->chip_id].media_timer,
      tulip_core.c:INIT_WORK(&tp->media_work, tulip_tbl[tp->chip_id].media_task);
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jarod Wilson <jarod@redhat.com>
      Cc: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
      Cc: netdev@vger.kernel.org
      Cc: linux-parisc@vger.kernel.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Ivan Khoronzhuk's avatar
      net: ethernet: ti: netcp_core: no need in netif_napi_del · e333ac1f
      Ivan Khoronzhuk authored
      Don't remove rx_napi specifically just before free_netdev(),
      it's supposed to be done in it and is confusing w/o tx_napi deletion.
      Signed-off-by: default avatarIvan Khoronzhuk <ivan.khoronzhuk@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Mathieu Malaterre's avatar
      davicom: Display proper debug level up to 6 · 0fdbedc7
      Mathieu Malaterre authored
      This will make it explicit some messages are of the form:
      dm9000_dbg(db, 5, ...
      Signed-off-by: default avatarMathieu Malaterre <malat@debian.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Baruch Siach's avatar
      net: phy: sfp: rename dt properties to match the binding · 25ee0793
      Baruch Siach authored
      Make the Rx rate select control gpio property name match the documented
      binding. This would make the addition of 'rate-select1-gpios' for SFP+
      support more natural.
      Also, make the MOD-DEF0 gpio property name match the documentation.
      Signed-off-by: default avatarBaruch Siach <baruch@tkos.co.il>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Baruch Siach's avatar
      dt-binding: net: sfp binding documentation · 3ef37140
      Baruch Siach authored
      Add device-tree binding documentation SFP transceivers. Support for SFP
      transceivers has been recently introduced (drivers/net/phy/sfp.c).
      Signed-off-by: default avatarBaruch Siach <baruch@tkos.co.il>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Baruch Siach's avatar
    • Baruch Siach's avatar
      dt-bindings: net: don't confuse with generic PHY property · c43593d8
      Baruch Siach authored
      This complements commit 9a94b3a4
       (dt-binding: phy: don't confuse with
      Ethernet phy properties).
      The generic PHY 'phys' property sometime appears in the same node with
      the Ethernet PHY 'phy' or 'phy-handle' properties. Add a warning in
      ethernet.txt to reduce confusion.
      Signed-off-by: default avatarBaruch Siach <baruch@tkos.co.il>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Haishuang Yan's avatar
      ip6_tunnel: fix setting hop_limit value for ipv6 tunnel · 18e1173d
      Haishuang Yan authored
      Similar to vxlan/geneve tunnel, if hop_limit is zero, it should fall
      back to ip6_dst_hoplimt().
      Signed-off-by: default avatarHaishuang Yan <yanhaishuang@cmss.chinamobile.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Haishuang Yan's avatar
      ip_tunnel: fix setting ttl and tos value in collect_md mode · 0f693f19
      Haishuang Yan authored
      ttl and tos variables are declared and assigned, but are not used in
      iptunnel_xmit() function.
      Fixes: cfc7381b
       ("ip_tunnel: add collect_md mode to IPIP tunnel")
      Cc: Alexei Starovoitov <ast@fb.com>
      Signed-off-by: default avatarHaishuang Yan <yanhaishuang@cmss.chinamobile.com>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  2. 08 Sep, 2017 21 commits
  3. 07 Sep, 2017 3 commits
    • David S. Miller's avatar
      Merge tag 'mac80211-for-davem-2017-09-07' of... · 0f2be423
      David S. Miller authored
      Merge tag 'mac80211-for-davem-2017-09-07' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
      Johannes Berg says:
      Back from a long absence, so we have a number of things:
       * a remain-on-channel fix from Avi
       * hwsim TX power fix from Beni
       * null-PTR dereference with iTXQ in some rare configurations (Chunho)
       * 40 MHz custom regdomain fixes (Emmanuel)
       * look at right place in HT/VHT capability parsing (Igor)
       * complete A-MPDU teardown properly (Ilan)
       * Mesh ID Element ordering fix (Liad)
       * avoid tracing warning in ht_dbg() (Sharon)
       * fix print of assoc/reassoc (Simon)
       * fix encrypted VLAN with iTXQ (myself)
       * fix calling context of TX queue wake (myself)
       * fix a deadlock with ath10k aggregation (myself)
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Luca Coelho's avatar
      iwlwifi: mvm: only send LEDS_CMD when the FW supports it · 2eabc84d
      Luca Coelho authored
      The LEDS_CMD command is only supported in some newer FW versions
      (e.g. iwlwifi-8000C-31.ucode), so we can't send it to older versions
      (such as iwlwifi-8000C-27.ucode).
      To fix this, check for a new bit in the FW capabilities TLV that tells
      when the command is supported.
      Note that the current version of -31.ucode in linux-firmware.git
      (31.532993.0) does not have this capability bit set, so the LED won't
      work, even though this version should support it.  But we will update
      this firmware soon, so it won't be a problem anymore.
      Fixes: 7089ae63
       ("iwlwifi: mvm: use firmware LED command where applicable")
      Reported-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
    • Larry Finger's avatar
      rtlwifi: btcoexist: Fix antenna selection code · 6d622692
      Larry Finger authored
      In commit 87d8a9f3 ("rtlwifi: btcoex: call bind to setup btcoex"),
      the code turns on a call to exhalbtc_bind_bt_coex_withadapter(). This
      routine contains a bug that causes incorrect antenna selection for those
      HP laptops with only one antenna and an incorrectly programmed EFUSE.
      These boxes are the ones that need the ant_sel module parameter.
      Fixes: 87d8a9f3
       ("rtlwifi: btcoex: call bind to setup btcoex")
      Signed-off-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Cc: Ping-Ke Shih <pkshih@realtek.com>
      Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
      Cc: Birming Chiu <birming@realtek.com>
      Cc: Shaofu <shaofu@realtek.com>
      Cc: Steven Ting <steventing@realtek.com>
      Cc: Stable <stable@vger.kernel.org> # 4.13+
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>