1. 30 8月, 2014 1 次提交
  2. 25 8月, 2014 1 次提交
  3. 09 7月, 2014 1 次提交
  4. 02 4月, 2014 1 次提交
  5. 30 3月, 2014 5 次提交
  6. 27 3月, 2014 1 次提交
  7. 25 3月, 2014 1 次提交
  8. 18 3月, 2014 10 次提交
  9. 07 2月, 2014 1 次提交
  10. 22 1月, 2014 1 次提交
  11. 11 1月, 2014 1 次提交
    • J
      net: core: explicitly select a txq before doing l2 forwarding · f663dd9a
      Jason Wang 提交于
      Currently, the tx queue were selected implicitly in ndo_dfwd_start_xmit(). The
      will cause several issues:
      
      - NETIF_F_LLTX were removed for macvlan, so txq lock were done for macvlan
        instead of lower device which misses the necessary txq synchronization for
        lower device such as txq stopping or frozen required by dev watchdog or
        control path.
      - dev_hard_start_xmit() was called with NULL txq which bypasses the net device
        watchdog.
      - dev_hard_start_xmit() does not check txq everywhere which will lead a crash
        when tso is disabled for lower device.
      
      Fix this by explicitly introducing a new param for .ndo_select_queue() for just
      selecting queues in the case of l2 forwarding offload. netdev_pick_tx() was also
      extended to accept this parameter and dev_queue_xmit_accel() was used to do l2
      forwarding transmission.
      
      With this fixes, NETIF_F_LLTX could be preserved for macvlan and there's no need
      to check txq against NULL in dev_hard_start_xmit(). Also there's no need to keep
      a dedicated ndo_dfwd_start_xmit() and we can just reuse the code of
      dev_queue_xmit() to do the transmission.
      
      In the future, it was also required for macvtap l2 forwarding support since it
      provides a necessary synchronization method.
      
      Cc: John Fastabend <john.r.fastabend@intel.com>
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Cc: e1000-devel@lists.sourceforge.net
      Signed-off-by: NJason Wang <jasowang@redhat.com>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Acked-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f663dd9a
  12. 03 1月, 2014 1 次提交
  13. 26 10月, 2013 1 次提交
  14. 20 9月, 2013 1 次提交
    • N
      netpoll: fix NULL pointer dereference in netpoll_cleanup · d0fe8c88
      Nikolay Aleksandrov 提交于
      I've been hitting a NULL ptr deref while using netconsole because the
      np->dev check and the pointer manipulation in netpoll_cleanup are done
      without rtnl and the following sequence happens when having a netconsole
      over a vlan and we remove the vlan while disabling the netconsole:
      	CPU 1					CPU2
      					removes vlan and calls the notifier
      enters store_enabled(), calls
      netdev_cleanup which checks np->dev
      and then waits for rtnl
      					executes the netconsole netdev
      					release notifier making np->dev
      					== NULL and releases rtnl
      continues to dereference a member of
      np->dev which at this point is == NULL
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d0fe8c88
  15. 13 9月, 2013 1 次提交
  16. 06 6月, 2013 1 次提交
  17. 05 6月, 2013 1 次提交
  18. 29 5月, 2013 1 次提交
  19. 28 5月, 2013 1 次提交
  20. 06 5月, 2013 1 次提交
  21. 02 5月, 2013 1 次提交
    • N
      netpoll: convert mutex into a semaphore · bd7c4b60
      Neil Horman 提交于
      Bart Van Assche recently reported a warning to me:
      
      <IRQ>  [<ffffffff8103d79f>] warn_slowpath_common+0x7f/0xc0
      [<ffffffff8103d7fa>] warn_slowpath_null+0x1a/0x20
      [<ffffffff814761dd>] mutex_trylock+0x16d/0x180
      [<ffffffff813968c9>] netpoll_poll_dev+0x49/0xc30
      [<ffffffff8136a2d2>] ? __alloc_skb+0x82/0x2a0
      [<ffffffff81397715>] netpoll_send_skb_on_dev+0x265/0x410
      [<ffffffff81397c5a>] netpoll_send_udp+0x28a/0x3a0
      [<ffffffffa0541843>] ? write_msg+0x53/0x110 [netconsole]
      [<ffffffffa05418bf>] write_msg+0xcf/0x110 [netconsole]
      [<ffffffff8103eba1>] call_console_drivers.constprop.17+0xa1/0x1c0
      [<ffffffff8103fb76>] console_unlock+0x2d6/0x450
      [<ffffffff8104011e>] vprintk_emit+0x1ee/0x510
      [<ffffffff8146f9f6>] printk+0x4d/0x4f
      [<ffffffffa0004f1d>] scsi_print_command+0x7d/0xe0 [scsi_mod]
      
      This resulted from my commit ca99ca14 which introduced a mutex_trylock
      operation in a path that could execute in interrupt context.  When mutex
      debugging is enabled, the above warns the user when we are in fact
      exectuting in interrupt context
      interrupt context.
      
      After some discussion, It seems that a semaphore is the proper mechanism to use
      here.  While mutexes are defined to be unusable in interrupt context, no such
      condition exists for semaphores (save for the fact that the non blocking api
      calls, like up and down_trylock must be used when in irq context).
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Reported-by: NBart Van Assche <bvanassche@acm.org>
      CC: Bart Van Assche <bvanassche@acm.org>
      CC: David Miller <davem@davemloft.net>
      CC: netdev@vger.kernel.org
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bd7c4b60
  22. 20 4月, 2013 2 次提交
  23. 18 3月, 2013 1 次提交
  24. 14 2月, 2013 1 次提交
    • N
      netpoll: fix smatch warnings in netpoll core code · 959d5fde
      Neil Horman 提交于
      Dan Carpenter contacted me with some notes regarding some smatch warnings in the
      netpoll code, some of which I introduced with my recent netpoll locking fixes,
      some which were there prior.   Specifically they were:
      
      net-next/net/core/netpoll.c:243 netpoll_poll_dev() warn: inconsistent
        returns mutex:&ni->dev_lock: locked (213,217) unlocked (210,243)
      net-next/net/core/netpoll.c:706 netpoll_neigh_reply() warn: potential
        pointer math issue ('skb_transport_header(send_skb)' is a 128 bit pointer)
      
      This patch corrects the locking imbalance (the first error), and adds some
      parenthesis to correct the second error.  Tested by myself. Applies to net-next
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      CC: Dan Carpenter <dan.carpenter@oracle.com>
      CC: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      959d5fde
  25. 12 2月, 2013 2 次提交
    • N
      netpoll: cleanup sparse warnings · 0790bbb6
      Neil Horman 提交于
      With my recent commit I introduced two sparse warnings.  Looking closer there
      were a few more in the same file, so I fixed them all up.  Basic rcu pointer
      dereferencing suff.
      
      I've validated these changes using CONFIG_PROVE_RCU while starting and stopping
      netconsole repeatedly in bonded and non-bonded configurations
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      CC: fengguang.wu@intel.com
      CC: David Miller <davem@davemloft.net>
      CC: eric.dumazet@gmail.com
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0790bbb6
    • N
      netpoll: Fix __netpoll_rcu_free so that it can hold the rtnl lock · 2cde6acd
      Neil Horman 提交于
      __netpoll_rcu_free is used to free netpoll structures when the rtnl_lock is
      already held.  The mechanism is used to asynchronously call __netpoll_cleanup
      outside of the holding of the rtnl_lock, so as to avoid deadlock.
      Unfortunately, __netpoll_cleanup modifies pointers (dev->np), which means the
      rtnl_lock must be held while calling it.  Further, it cannot be held, because
      rcu callbacks may be issued in softirq contexts, which cannot sleep.
      
      Fix this by converting the rcu callback to a work queue that is guaranteed to
      get scheduled in process context, so that we can hold the rtnl properly while
      calling __netpoll_cleanup
      
      Tested successfully by myself.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: Cong Wang <amwang@redhat.com>
      CC: Eric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2cde6acd