1. 30 3月, 2014 1 次提交
  2. 27 3月, 2014 1 次提交
  3. 25 3月, 2014 1 次提交
  4. 18 3月, 2014 10 次提交
  5. 07 2月, 2014 1 次提交
  6. 22 1月, 2014 1 次提交
  7. 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
  8. 03 1月, 2014 1 次提交
  9. 26 10月, 2013 1 次提交
  10. 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
  11. 13 9月, 2013 1 次提交
  12. 06 6月, 2013 1 次提交
  13. 05 6月, 2013 1 次提交
  14. 29 5月, 2013 1 次提交
  15. 28 5月, 2013 1 次提交
  16. 06 5月, 2013 1 次提交
  17. 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
  18. 20 4月, 2013 2 次提交
  19. 18 3月, 2013 1 次提交
  20. 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
  21. 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
  22. 07 2月, 2013 1 次提交
    • N
      netpoll: protect napi_poll and poll_controller during dev_[open|close] · ca99ca14
      Neil Horman 提交于
      Ivan Vercera was recently backporting commit
      9c13cb8b to a RHEL kernel, and I noticed that,
      while this patch protects the tg3 driver from having its ndo_poll_controller
      routine called during device initalization, it does nothing for the driver
      during shutdown. I.e. it would be entirely possible to have the
      ndo_poll_controller method (or subsequently the ndo_poll) routine called for a
      driver in the netpoll path on CPU A while in parallel on CPU B, the ndo_close or
      ndo_open routine could be called.  Given that the two latter routines tend to
      initizlize and free many data structures that the former two rely on, the result
      can easily be data corruption or various other crashes.  Furthermore, it seems
      that this is potentially a problem with all net drivers that support netpoll,
      and so this should ideally be fixed in a common path.
      
      As Ben H Pointed out to me, we can't preform dev_open/dev_close in atomic
      context, so I've come up with this solution.  We can use a mutex to sleep in
      open/close paths and just do a mutex_trylock in the napi poll path and abandon
      the poll attempt if we're locked, as we'll just retry the poll on the next send
      anyway.
      
      I've tested this here by flooding netconsole with messages on a system whos nic
      driver I modfied to periodically return NETDEV_TX_BUSY, so that the netpoll tx
      workqueue would be forced to send frames and poll the device.  While this was
      going on I rapidly ifdown/up'ed the interface and watched for any problems.
      I've not found any.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      CC: Ivan Vecera <ivecera@redhat.com>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: Ben Hutchings <bhutchings@solarflare.com>
      CC: Francois Romieu <romieu@fr.zoreil.com>
      CC: Eric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ca99ca14
  23. 29 1月, 2013 2 次提交
  24. 23 1月, 2013 1 次提交
  25. 17 1月, 2013 2 次提交
    • C
      netpoll: fix a missing dev refcounting · 5bd30d39
      Cong Wang 提交于
      __dev_get_by_name() doesn't refcount the network device,
      so we have to do this by ourselves. Noticed by Eric.
      
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Jiri Pirko <jiri@resnulli.us>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: NCong Wang <amwang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5bd30d39
    • C
      netpoll: fix a rtnl lock assertion failure · f92d3180
      Cong Wang 提交于
      v4: hold rtnl lock for the whole netpoll_setup()
      v3: remove the comment
      v2: use RCU read lock
      
      This patch fixes the following warning:
      
      [   72.013864] RTNL: assertion failed at net/core/dev.c (4955)
      [   72.017758] Pid: 668, comm: netpoll-prep-v6 Not tainted 3.8.0-rc1+ #474
      [   72.019582] Call Trace:
      [   72.020295]  [<ffffffff8176653d>] netdev_master_upper_dev_get+0x35/0x58
      [   72.022545]  [<ffffffff81784edd>] netpoll_setup+0x61/0x340
      [   72.024846]  [<ffffffff815d837e>] store_enabled+0x82/0xc3
      [   72.027466]  [<ffffffff815d7e51>] netconsole_target_attr_store+0x35/0x37
      [   72.029348]  [<ffffffff811c3479>] configfs_write_file+0xe2/0x10c
      [   72.030959]  [<ffffffff8115d239>] vfs_write+0xaf/0xf6
      [   72.032359]  [<ffffffff81978a05>] ? sysret_check+0x22/0x5d
      [   72.033824]  [<ffffffff8115d453>] sys_write+0x5c/0x84
      [   72.035328]  [<ffffffff819789d9>] system_call_fastpath+0x16/0x1b
      
      In case of other races, hold rtnl lock for the entire netpoll_setup() function.
      
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Jiri Pirko <jiri@resnulli.us>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: NCong Wang <amwang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f92d3180
  26. 09 1月, 2013 2 次提交