1. 03 Sep, 2018 4 commits
    • Emmanuel Grumbach's avatar
      mac80211: fix a race between restart and CSA flows · f3ffb6c3
      Emmanuel Grumbach authored
      We hit a problem with iwlwifi that was caused by a bug in
      mac80211. A bug in iwlwifi caused the firwmare to crash in
      certain cases in channel switch. Because of that bug,
      drv_pre_channel_switch would fail and trigger the restart
      flow.
      Now we had the hw restart worker which runs on the system's
      workqueue and the csa_connection_drop_work worker that runs
      on mac80211's workqueue that can run together. This is
      obviously problematic since the restart work wants to
      reconfigure the connection, while the csa_connection_drop_work
      worker does the exact opposite: it tries to disconnect.
      
      Fix this by cancelling the csa_connection_drop_work worker
      in the restart worker.
      
      Note that this can sound racy: we could have:
      
      driver   iface_work   CSA_work   restart_work
      +++++++++++++++++++++++++++++++++++++++++++++
                    |
       <--drv_cs ---|
      <FW CRASH!>
      -CS FAILED-->
                    |                       |
                    |                 cancel_work(CSA)
                 schedule                   |
                 CSA work                   |
                               |            |
                              Race between those 2
      
      But this is not possible because we flush the workqueue
      in the restart worker before we cancel the CSA worker.
      That would be bullet proof if we could guarantee that
      we schedule the CSA worker only from the iface_work
      which runs on the workqueue (and not on the system's
      workqueue), but unfortunately we do have an instance
      in which we schedule the CSA work outside the context
      of the workqueue (ieee80211_chswitch_done).
      
      Note also that we should probably cancel other workers
      like beacon_connection_loss_work and possibly others
      for different types of interfaces, at the very least,
      IBSS should suffer from the exact same problem, but for
      now, do the minimum to fix the actual bug that was actually
      experienced and reproduced.
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      f3ffb6c3
    • Dreyfuss, Haim's avatar
      mac80211: fix WMM TXOP calculation · abd76d25
      Dreyfuss, Haim authored
      In commit 9236c4523e5b ("mac80211: limit wmm params to comply
      with ETSI requirements"), we have limited the WMM parameters to
      comply with 802.11 and ETSI standard.  Mistakenly the TXOP value
      was caluclated wrong.  Fix it by taking the minimum between
      802.11 to ETSI to make sure we are not violating both.
      
      Fixes: e552af05 ("mac80211: limit wmm params to comply with ETSI requirements")
      Signed-off-by: default avatarHaim Dreyfuss <haim.dreyfuss@intel.com>
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      abd76d25
    • Dan Carpenter's avatar
      cfg80211: fix a type issue in ieee80211_chandef_to_operating_class() · 8442938c
      Dan Carpenter authored
      The "chandef->center_freq1" variable is a u32 but "freq" is a u16 so we
      are truncating away the high bits.  I noticed this bug because in commit
      9cf0a0b4 ("cfg80211: Add support for 60GHz band channels 5 and 6")
      we made "freq <= 56160 + 2160 * 6" a valid requency when before it was
      only "freq <= 56160 + 2160 * 4" that was valid.  It introduces a static
      checker warning:
      
          net/wireless/util.c:1571 ieee80211_chandef_to_operating_class()
          warn: always true condition '(freq <= 56160 + 2160 * 6) => (0-u16max <= 69120)'
      
      But really we probably shouldn't have been truncating the high bits
      away to begin with.
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      8442938c
    • Lorenzo Bianconi's avatar
      mac80211: fix an off-by-one issue in A-MSDU max_subframe computation · 66eb02d8
      Lorenzo Bianconi authored
      Initialize 'n' to 2 in order to take into account also the first
      packet in the estimation of max_subframe limit for a given A-MSDU
      since frag_tail pointer is NULL when ieee80211_amsdu_aggregate
      routine analyzes the second frame.
      
      Fixes: 6e0456b5 ("mac80211: add A-MSDU tx support")
      Signed-off-by: default avatarLorenzo Bianconi <lorenzo.bianconi@redhat.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      66eb02d8
  2. 30 Aug, 2018 3 commits
  3. 29 Aug, 2018 2 commits
  4. 28 Aug, 2018 7 commits
  5. 20 Aug, 2018 1 commit
  6. 15 Aug, 2018 1 commit
  7. 14 Aug, 2018 2 commits
  8. 11 Aug, 2018 9 commits
  9. 10 Aug, 2018 2 commits
  10. 09 Aug, 2018 9 commits
    • Daniel Borkmann's avatar
      Merge branch 'bpf-fix-cpu-and-devmap-teardown' · 9c954201
      Daniel Borkmann authored
      Jesper Dangaard Brouer says:
      
      ====================
      Removing entries from cpumap and devmap, goes through a number of
      syncronization steps to make sure no new xdp_frames can be enqueued.
      But there is a small chance, that xdp_frames remains which have not
      been flushed/processed yet.  Flushing these during teardown, happens
      from RCU context and not as usual under RX NAPI context.
      
      The optimization introduced in commt 389ab7f0 ("xdp: introduce
      xdp_return_frame_rx_napi"), missed that the flush operation can also
      be called from RCU context.  Thus, we cannot always use the
      xdp_return_frame_rx_napi call, which take advantage of the protection
      provided by XDP RX running under NAPI protection.
      
      The samples/bpf xdp_redirect_cpu have a --stress-mode, that is
      adjusted to easier reproduce (verified by Red Hat QA).
      ====================
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      9c954201
    • Jesper Dangaard Brouer's avatar
      xdp: fix bug in devmap teardown code path · 1bf9116d
      Jesper Dangaard Brouer authored
      Like cpumap teardown, the devmap teardown code also flush remaining
      xdp_frames, via bq_xmit_all() in case map entry is removed.  The code
      can call xdp_return_frame_rx_napi, from the the wrong context, in-case
      ndo_xdp_xmit() fails.
      
      Fixes: 389ab7f0 ("xdp: introduce xdp_return_frame_rx_napi")
      Fixes: 735fc405 ("xdp: change ndo_xdp_xmit API to support bulking")
      Signed-off-by: default avatarJesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      1bf9116d
    • Jesper Dangaard Brouer's avatar
      samples/bpf: xdp_redirect_cpu adjustment to reproduce teardown race easier · 37d7ff25
      Jesper Dangaard Brouer authored
      The teardown race in cpumap is really hard to reproduce.  These changes
      makes it easier to reproduce, for QA.
      
      The --stress-mode now have a case of a very small queue size of 8, that helps
      to trigger teardown flush to encounter a full queue, which results in calling
      xdp_return_frame API, in a non-NAPI protect context.
      
      Also increase MAX_CPUS, as my QA department have larger machines than me.
      Tested-by: default avatarJean-Tsung Hsiao <jhsiao@redhat.com>
      Signed-off-by: default avatarJesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      37d7ff25
    • Jesper Dangaard Brouer's avatar
      xdp: fix bug in cpumap teardown code path · ad0ab027
      Jesper Dangaard Brouer authored
      When removing a cpumap entry, a number of syncronization steps happen.
      Eventually the teardown code __cpu_map_entry_free is invoked from/via
      call_rcu.
      
      The teardown code __cpu_map_entry_free() flushes remaining xdp_frames,
      by invoking bq_flush_to_queue, which calls xdp_return_frame_rx_napi().
      The issues is that the teardown code is not running in the RX NAPI
      code path.  Thus, it is not allowed to invoke the NAPI variant of
      xdp_return_frame.
      
      This bug was found and triggered by using the --stress-mode option to
      the samples/bpf program xdp_redirect_cpu.  It is hard to trigger,
      because the ptr_ring have to be full and cpumap bulk queue max
      contains 8 packets, and a remote CPU is racing to empty the ptr_ring
      queue.
      
      Fixes: 389ab7f0 ("xdp: introduce xdp_return_frame_rx_napi")
      Tested-by: default avatarJean-Tsung Hsiao <jhsiao@redhat.com>
      Signed-off-by: default avatarJesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      ad0ab027
    • Linus Torvalds's avatar
      Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 · 112cbae2
      Linus Torvalds authored
      Pull crypto fix from Herbert Xu:
       "This fixes a performance regression in arm64 NEON crypto as well as a
        crash in x86 aegis/morus on unsupported CPUs"
      
      * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
        crypto: x86/aegis,morus - Fix and simplify CPUID checks
        crypto: arm64 - revert NEON yield for fast AEAD implementations
      112cbae2
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · 6395ad85
      Linus Torvalds authored
      Pull networking fixes from David Miller:
      
       1) The real fix for the ipv6 route metric leak Sabrina was seeing, from
          Cong Wang.
      
       2) Fix syzbot triggers AF_PACKET v3 ring buffer insufficient room
          conditions, from Willem de Bruijn.
      
       3) vsock can reinitialize active work struct, fix from Cong Wang.
      
       4) RXRPC keepalive generator can wedge a cpu, fix from David Howells.
      
       5) Fix locking in AF_SMC ioctl, from Ursula Braun.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
        dsa: slave: eee: Allow ports to use phylink
        net/smc: move sock lock in smc_ioctl()
        net/smc: allow sysctl rmem and wmem defaults for servers
        net/smc: no shutdown in state SMC_LISTEN
        net: aquantia: Fix IFF_ALLMULTI flag functionality
        rxrpc: Fix the keepalive generator [ver #2]
        net/mlx5e: Cleanup of dcbnl related fields
        net/mlx5e: Properly check if hairpin is possible between two functions
        vhost: reset metadata cache when initializing new IOTLB
        llc: use refcount_inc_not_zero() for llc_sap_find()
        dccp: fix undefined behavior with 'cwnd' shift in ccid2_cwnd_restart()
        tipc: fix an interrupt unsafe locking scenario
        vsock: split dwork to avoid reinitializations
        net: thunderx: check for failed allocation lmac->dmacs
        cxgb4: mk_act_open_req() buggers ->{local, peer}_ip on big-endian hosts
        packet: refine ring v3 block size test to hold one frame
        ip6_tunnel: use the right value for ipv4 min mtu check in ip6_tnl_xmit
        ipv6: fix double refcount of fib6_metrics
      6395ad85
    • George Cherian's avatar
      i2c: xlp9xx: Fix case where SSIF read transaction completes early · 5eb173f5
      George Cherian authored
      During ipmi stress tests we see occasional failure of transactions
      at the boot time. This happens in the case of a I2C_M_RECV_LEN
      transactions, when the read transfer completes (with the initial
      read length of 34) before the driver gets a chance to handle interrupts.
      
      The current driver code expects at least 2 interrupts for I2C_M_RECV_LEN
      transactions. The length is updated during the first interrupt, and  the
      buffer contents are only copied during subsequent interrupts. In case of
      just one interrupt, we will complete the transaction without copying
      out the bytes from RX fifo.
      
      Update the code to drain the RX fifo after the length update,
      so that the transaction completes correctly in all cases.
      Signed-off-by: default avatarGeorge Cherian <george.cherian@cavium.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Cc: stable@kernel.org
      5eb173f5
    • Andrew Lunn's avatar
      dsa: slave: eee: Allow ports to use phylink · 1be52e97
      Andrew Lunn authored
      For a port to be able to use EEE, both the MAC and the PHY must
      support EEE. A phy can be provided by both a phydev or phylink. Verify
      at least one of these exist, not just phydev.
      
      Fixes: aab9c406 ("net: dsa: Plug in PHYLINK support")
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1be52e97
    • David S. Miller's avatar
      Merge branch 'smc-fixes' · ef91b6f9
      David S. Miller authored
      Ursula Braun says:
      
      ====================
      net/smc: fixes 2018-08-08
      
      here are small fixes for SMC: The first patch makes sure, shutdown code
      is not executed for sockets in state SMC_LISTEN. The second patch resets
      send and receive buffer values for accepted sockets, since TCP buffer size
      optimizations for the internal CLC socket should not be forwarded to the
      outer SMC socket. The third patch solves a race between connect and ioctl
      reported by syzbot.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ef91b6f9