1. 12 5月, 2017 1 次提交
  2. 12 4月, 2017 7 次提交
  3. 07 4月, 2017 1 次提交
  4. 25 3月, 2017 1 次提交
    • J
      s390/qeth: size calculation outbound buffers · 7d969d2e
      Julian Wiedmann 提交于
      Depending on the device type, hard_start_xmit() builds different output
      buffer formats. For instance with HiperSockets, on both L2 and L3 we
      strip the ETH header from the skb - L3 doesn't need it, and L2 carries
      it in the buffer's header element.
      For this, we pass data_offset = ETH_HLEN all the way down to
      __qeth_fill_buffer(), where skb->data is then adjusted accordingly.
      But the initial size calculation still considers the *full* skb length
      (including the ETH header). So qeth_get_elements_no() can erroneously
      reject a skb as too big, even though it would actually fit into an
      output buffer once the ETH header has been trimmed off later.
      
      Fix this by passing an additional offset to qeth_get_elements_no(),
      that indicates where in the skb the on-wire data actually begins.
      Since the current code uses data_offset=-1 for some special handling
      on OSA, we need to clamp data_offset to 0...
      
      On HiperSockets this helps when sending ~MTU-size skbs with weird page
      alignment. No change for OSA or AF_IUCV.
      Signed-off-by: NJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Signed-off-by: NUrsula Braun <ubraun@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7d969d2e
  5. 12 1月, 2017 6 次提交
  6. 21 10月, 2016 1 次提交
  7. 16 9月, 2016 3 次提交
  8. 05 7月, 2016 1 次提交
  9. 17 6月, 2016 7 次提交
  10. 15 12月, 2015 1 次提交
  11. 07 10月, 2015 2 次提交
  12. 22 9月, 2015 2 次提交
  13. 07 8月, 2015 1 次提交
  14. 19 5月, 2015 4 次提交
  15. 26 1月, 2015 2 次提交
    • T
      390/qeth: Fix locking warning during qeth device setup · 1aec42bc
      Thomas Richter 提交于
      Do not wait for channel command buffers in IPA commands.
      The potential wait could be done while holding a spin lock and causes
      in recent kernels such a bug if kernel lock debugging is enabled:
      
      kernel: BUG: sleeping function called from invalid context at drivers/s390/net/qeth_core_main.c:
      794
      kernel: in_atomic(): 1, irqs_disabled(): 0, pid: 2031, name: NetworkManager
      kernel: 2 locks held by NetworkManager/2031:
      kernel:  #0:  (rtnl_mutex){+.+.+.}, at: [<00000000006e0d7a>] rtnetlink_rcv+0x32/0x50
      kernel:  #1:  (_xmit_ETHER){+.....}, at: [<00000000006cfe90>] dev_set_rx_mode+0x30/0x50
      kernel: CPU: 0 PID: 2031 Comm: NetworkManager Not tainted 3.18.0-rc5-next-20141124 #1
      kernel:        00000000275fb1f0 00000000275fb280 0000000000000002 0000000000000000
                     00000000275fb320 00000000275fb298 00000000275fb298 00000000007e326a
                     0000000000000000 000000000099ce2c 00000000009b4988 000000000000000b
                     00000000275fb2e0 00000000275fb280 0000000000000000 0000000000000000
                     0000000000000000 00000000001129c8 00000000275fb280 00000000275fb2e0
      kernel: Call Trace:
      kernel: ([<00000000001128b0>] show_trace+0xf8/0x158)
      kernel:  [<000000000011297a>] show_stack+0x6a/0xe8
      kernel:  [<00000000007e995a>] dump_stack+0x82/0xb0
      kernel:  [<000000000017d668>] ___might_sleep+0x170/0x228
      kernel:  [<000003ff80026f0e>] qeth_wait_for_buffer+0x36/0xd0 [qeth]
      kernel:  [<000003ff80026fe2>] qeth_get_ipacmd_buffer+0x3a/0xc0 [qeth]
      kernel:  [<000003ff80105078>] qeth_l3_send_setdelmc+0x58/0xf8 [qeth_l3]
      kernel:  [<000003ff8010b1fe>] qeth_l3_set_ip_addr_list+0x2c6/0x848 [qeth_l3]
      kernel:  [<000003ff8010bbb4>] qeth_l3_set_multicast_list+0x434/0xc48 [qeth_l3]
      kernel:  [<00000000006cfe9a>] dev_set_rx_mode+0x3a/0x50
      kernel:  [<00000000006cff90>] __dev_open+0xe0/0x140
      kernel:  [<00000000006d02a0>] __dev_change_flags+0xa0/0x178
      kernel:  [<00000000006d03a8>] dev_change_flags+0x30/0x70
      kernel:  [<00000000006e14ee>] do_setlink+0x346/0x9a0
      ...
      
      The device driver has plenty of command buffers available
      per channel for channel command communication.
      In the extremely rare case when there is no command buffer
      available, return a NULL pointer and issue a warning
      in the kernel log. The caller handles the case when
      a NULL pointer is encountered and returns an error.
      
      In the case the wait for command buffer is possible
      (because no lock is held as in the OSN case), still wait
      until a channel command buffer is available.
      Signed-off-by: NThomas Richter <tmricht@linux.vnet.ibm.com>
      Signed-off-by: NUrsula Braun <ursula.braun@de.ibm.com>
      Reviewed-by: NEugene Crosser <Eugene.Crosser@ru.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1aec42bc
    • E
      qeth: clean up error handling · efbbc1d5
      Eugene Crosser 提交于
      In the functions that are registering and unregistering MAC
      addresses in the qeth-handled hardware, remove callback functions
      that are unnesessary, as only the return code is analyzed.
      Translate hardware response codes to semi-standard 'errno'-like
      codes for readability.
      
      Add kernel-doc description to the internal API function
      qeth_send_control_data().
      Signed-off-by: NEugene Crosser <Eugene.Crosser@ru.ibm.com>
      Signed-off-by: NUrsula Braun <ursula.braun@de.ibm.com>
      Reviewed-by: NThomas-Mich Richter <tmricht@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      efbbc1d5