1. 01 11月, 2019 1 次提交
  2. 10 10月, 2019 2 次提交
  3. 25 8月, 2019 1 次提交
  4. 21 8月, 2019 4 次提交
  5. 10 8月, 2019 1 次提交
    • G
      s390/net: Mark expected switch fall-throughs · 7b733151
      Gustavo A. R. Silva 提交于
      Mark switch cases where we are expecting to fall through.
      
      This patch fixes the following warnings (Building: s390):
      
      drivers/s390/net/ctcm_fsms.c: In function ‘ctcmpc_chx_attnbusy’:
      drivers/s390/net/ctcm_fsms.c:1703:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
         if (grp->changed_side == 1) {
            ^
      drivers/s390/net/ctcm_fsms.c:1707:2: note: here
        case MPCG_STATE_XID0IOWAIX:
        ^~~~
      
      drivers/s390/net/ctcm_mpc.c: In function ‘ctc_mpc_alloc_channel’:
      drivers/s390/net/ctcm_mpc.c:358:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
         if (callback)
            ^
      drivers/s390/net/ctcm_mpc.c:360:2: note: here
        case MPCG_STATE_XID0IOWAIT:
        ^~~~
      
      drivers/s390/net/ctcm_mpc.c: In function ‘mpc_action_timeout’:
      drivers/s390/net/ctcm_mpc.c:1469:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
         if ((fsm_getstate(rch->fsm) == CH_XID0_PENDING) &&
            ^
      drivers/s390/net/ctcm_mpc.c:1472:2: note: here
        default:
        ^~~~~~~
      drivers/s390/net/ctcm_mpc.c: In function ‘mpc_send_qllc_discontact’:
      drivers/s390/net/ctcm_mpc.c:2087:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
         if (grp->estconnfunc) {
            ^
      drivers/s390/net/ctcm_mpc.c:2092:2: note: here
        case MPCG_STATE_FLOWC:
        ^~~~
      
      drivers/s390/net/qeth_l2_main.c: In function ‘qeth_l2_process_inbound_buffer’:
      drivers/s390/net/qeth_l2_main.c:328:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
          if (IS_OSN(card)) {
             ^
      drivers/s390/net/qeth_l2_main.c:337:3: note: here
         default:
         ^~~~~~~
      Reviewed-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
      7b733151
  6. 28 6月, 2019 6 次提交
  7. 14 6月, 2019 6 次提交
  8. 06 6月, 2019 1 次提交
    • A
      s390/qeth: fix VLAN attribute in bridge_hostnotify udev event · 33572619
      Alexandra Winter 提交于
      Enabling sysfs attribute bridge_hostnotify triggers a series of udev events
      for the MAC addresses of all currently connected peers. In case no VLAN is
      set for a peer, the device reports the corresponding MAC addresses with
      VLAN ID 4096. This currently results in attribute VLAN=4096 for all
      non-VLAN interfaces in the initial series of events after host-notify is
      enabled.
      
      Instead, no VLAN attribute should be reported in the udev event for
      non-VLAN interfaces.
      
      Only the initial events face this issue. For dynamic changes that are
      reported later, the device uses a validity flag.
      
      This also changes the code so that it now sets the VLAN attribute for
      MAC addresses with VID 0. On Linux, no qeth interface will ever be
      registered with VID 0: Linux kernel registers VID 0 on all network
      interfaces initially, but qeth will drop .ndo_vlan_rx_add_vid for VID 0.
      Peers with other OSs could register MACs with VID 0.
      
      Fixes: 9f48b9db ("qeth: bridgeport support - address notifications")
      Signed-off-by: NAlexandra Winter <wintera@linux.ibm.com>
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      33572619
  9. 26 4月, 2019 4 次提交
  10. 18 4月, 2019 4 次提交
    • J
      s390/qeth: stop/wake TX queues based on their fill level · 54a50941
      Julian Wiedmann 提交于
      Current xmit code only stops the txq after attempting to fill an
      IO buffer that hasn't been TX-completed yet. In many-connection
      scenarios, this can result in frequent rejected TX attempts, requeuing
      of skbs with NETDEV_TX_BUSY and extra overhead.
      
      Now that we have a proper 1-to-1 relation between stack-side txqs and
      our HW Queues, overhaul the stop/wake logic so that the xmit code
      stops the txq as needed.
      Given that we might map multiple skbs into a single buffer, it's crucial
      to ensure that the queue always provides an _entirely_ empty IO buffer.
      Otherwise large skbs (eg TSO) might not fit into the last available
      buffer. So whenever qeth_do_send_packet() first utilizes an _empty_
      buffer, it updates & checks the used_buffers count.
      
      This now ensures that an skb passed to qeth_xmit() can always be mapped
      into an IO buffer, so remove all of the -EBUSY roll-back handling in the
      TX path. We preserve the minimal safety-checks ("Is this IO buffer
      really available?"), just in case some nasty future bug ever attempts to
      corrupt an in-use buffer.
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      54a50941
    • J
      s390/qeth: add TX multiqueue support for OSA devices · 73dc2daf
      Julian Wiedmann 提交于
      This adds trivial support for multiple TX queues on OSA-style devices
      (both real HW and z/VM NICs). For now we expose the driver's existing
      QoS mechanism via .ndo_select_queue, and adjust the number of available
      TX queues when qeth_update_from_chp_desc() detects that the
      HW configuration has changed.
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      73dc2daf
    • J
      s390/qeth: add TX multiqueue support for IQD devices · 3a18d754
      Julian Wiedmann 提交于
      qeth has been supporting multiple HW Output Queues for a long time. But
      rather than exposing those queues to the stack, it uses its own queue
      selection logic in .ndo_start_xmit... with all the drawbacks that
      entails.
      Start off by switching IQD devices over to a proper mqs net_device,
      and converting all the netdev_queue management code.
      
      One oddity with IQD devices is the requirement to place all mcast
      traffic on the _highest_ established HW queue. Doing so via
      .ndo_select_queue seems straight-forward - but that won't work if only
      some of the HW queues are active
      (ie. when dev->real_num_tx_queues < dev->num_tx_queues), since
      netdev_cap_txqueue() will not allow us to put skbs on the higher queues.
      
      To make this work, we
      1. let .ndo_select_queue() map all mcast traffic to netdev_queue 0, and
      2. later re-map the netdev_queue and HW queue indices in
         .ndo_start_xmit and the TX completion handler.
      
      With this patch we default to a fixed set of 1 ucast and 1 mcast queue.
      Support for dynamic reconfiguration is added at a later time.
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3a18d754
    • J
      s390/qeth: clarify naming for some QDIO helpers · 41c47da3
      Julian Wiedmann 提交于
      The naming of several QDIO helpers doesn't match their actual
      functionality, or the structures they operate on. Clean this up.
      
      s/qeth_alloc_qdio_buffers/qeth_alloc_qdio_queues
      s/qeth_free_qdio_buffers/qeth_free_qdio_queues
      s/qeth_alloc_qdio_out_buf/qeth_alloc_output_queue
      s/qeth_clear_outq_buffers/qeth_drain_output_queue
      s/qeth_clear_qdio_buffers/qeth_drain_output_queues
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      41c47da3
  11. 29 3月, 2019 4 次提交
  12. 19 3月, 2019 2 次提交
  13. 01 3月, 2019 4 次提交
    • J
      s390/qeth: drop redundant state checking · 0f7aedbd
      Julian Wiedmann 提交于
      Now that qeth always uses dev_close() to shutdown the interface, we can
      trust the locking and remove some custom state checks.
      qeth_l?_stop_card() is no longer called for a card in UP state, so remove
      the checks there too. This basically makes the UP state obsolete, so rip
      out the whole thing (except for the sysfs-visible string).
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0f7aedbd
    • J
      s390/qeth: don't special-case HW trap during suspend · 62ca98d4
      Julian Wiedmann 提交于
      It makes no difference whether we
      1. manually disarm the HW trap and call the offline code with
         recovery_mode == 1, or
      2. call the offline code with recovery_mode == 0, and let it disarm the
         HW trap for us.
      
      So consolidate the two code paths in the suspend callback.
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      62ca98d4
    • J
      s390/qeth: don't defer close_dev work during recovery · bf42d40b
      Julian Wiedmann 提交于
      The recovery code already runs in a kthread, we don't have to defer the
      offlining further.
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bf42d40b
    • J
      s390/qeth: call dev_close() during recovery · d4560150
      Julian Wiedmann 提交于
      When resetting an interface ("recovery"), qeth currently attempts to
      elide the call to dev_close(). We initially only call .ndo_close to
      quiesce the data path, and then offline & online the ccwgroup device.
      If the reset succeeded, a call to .ndo_open then resumes the data path
      along with some internal setup (dev_addr validation, RX modeset) that
      dev_open() would have usually triggered.
      dev_close() only gets called (via the close_dev worker) if the reset
      action fails.
      
      It's unclear whether this was initially done due to locking concerns, or
      rather to execute the reset transparently. Either way, temporarily
      closing the interface without dev_close() is fragile, and means we're
      susceptible to various races and unexpected behaviour. For instance:
      
      - Bypassing dev_deactivate_many() means that the qdiscs are not set to
      __QDISC_STATE_DEACTIVATED. Consequently any intermittent TX completion
      can wake up the txq, resulting in calls to .ndo_start_xmit while the
      data path is down. We have custom state checking to detect this case
      and drop such packets.
      
      - Because the IFF_UP flag doesn't reflect the interface's actual state
      during a reset, we have custom state checking in .ndo_open and
      .ndo_close to guard against invalid calls.
      
      - Considering that the reset might take a considerable amount of time
      (in particular if an IO fails and we end up waiting for its timeout), we
      _do_ want NETDEV_GOING_DOWN and NETDEV_DOWN events so that components
      like bonding, team, bridge, macvlan, vlan, ... can take appropriate
      action.
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d4560150