1. 05 Jun, 2013 1 commit
  2. 06 May, 2013 1 commit
  3. 01 May, 2013 1 commit
    • Neil Horman's avatar
      netpoll: convert mutex into a semaphore · bd7c4b60
      Neil Horman authored
      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: default avatarNeil Horman <nhorman@tuxdriver.com>
      Reported-by: default avatarBart 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: default avatarDavid S. Miller <davem@davemloft.net>
      bd7c4b60
  4. 19 Apr, 2013 2 commits
  5. 17 Mar, 2013 1 commit
  6. 13 Feb, 2013 1 commit
    • Neil Horman's avatar
      netpoll: fix smatch warnings in netpoll core code · 959d5fde
      Neil Horman authored
      
      
      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: default avatarNeil Horman <nhorman@tuxdriver.com>
      CC: Dan Carpenter <dan.carpenter@oracle.com>
      CC: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      959d5fde
  7. 12 Feb, 2013 2 commits
    • Neil Horman's avatar
      netpoll: cleanup sparse warnings · 0790bbb6
      Neil Horman authored
      
      
      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: default avatarNeil Horman <nhorman@tuxdriver.com>
      CC: fengguang.wu@intel.com
      CC: David Miller <davem@davemloft.net>
      CC: eric.dumazet@gmail.com
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0790bbb6
    • Neil Horman's avatar
      netpoll: Fix __netpoll_rcu_free so that it can hold the rtnl lock · 2cde6acd
      Neil Horman authored
      
      
      __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: default avatarNeil 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: default avatarDavid S. Miller <davem@davemloft.net>
      2cde6acd
  8. 06 Feb, 2013 1 commit
    • Neil Horman's avatar
      netpoll: protect napi_poll and poll_controller during dev_[open|close] · ca99ca14
      Neil Horman authored
      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: default avatarNeil 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: default avatarDavid S. Miller <davem@davemloft.net>
      ca99ca14
  9. 28 Jan, 2013 2 commits
  10. 23 Jan, 2013 1 commit
  11. 17 Jan, 2013 1 commit
  12. 16 Jan, 2013 1 commit
    • Cong Wang's avatar
      netpoll: fix a rtnl lock assertion failure · f92d3180
      Cong Wang authored
      
      
      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: default avatarCong Wang <amwang@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f92d3180
  13. 09 Jan, 2013 2 commits
  14. 04 Jan, 2013 1 commit
  15. 11 Dec, 2012 1 commit
  16. 10 Dec, 2012 1 commit
  17. 19 Sep, 2012 1 commit
  18. 30 Aug, 2012 1 commit
  19. 29 Aug, 2012 1 commit
    • Amerigo Wang's avatar
      netpoll: revert 6bdb7fe3 and fix be_poll() instead · 072a9c48
      Amerigo Wang authored
      Against -net.
      
      In the patch "netpoll: re-enable irq in poll_napi()", I tried to
      fix the following warning:
      
      [100718.051041] ------------[ cut here ]------------
      [100718.051048] WARNING: at kernel/softirq.c:159 local_bh_enable_ip+0x7d/0xb0()
      (Not tainted)
      [100718.051049] Hardware name: ProLiant BL460c G7
      ...
      [100718.051068] Call Trace:
      [100718.051073]  [<ffffffff8106b747>] ? warn_slowpath_common+0x87/0xc0
      [100718.051075]  [<ffffffff8106b79a>] ? warn_slowpath_null+0x1a/0x20
      [100718.051077]  [<ffffffff810747ed>] ? local_bh_enable_ip+0x7d/0xb0
      [100718.051080]  [<ffffffff8150041b>] ? _spin_unlock_bh+0x1b/0x20
      [100718.051085]  [<ffffffffa00ee974>] ? be_process_mcc+0x74/0x230 [be2net]
      [100718.051088]  [<ffffffffa00ea68c>] ? be_poll_tx_mcc+0x16c/0x290 [be2net]
      [100718.051090]  [<ffffffff8144fe76>] ? netpoll_poll_dev+0xd6/0x490
      [100718.051095]  [<ffffffffa01d24a5>] ? bond_poll_controller+0x75/0x80 [bonding]
      [100718.051097]  [<ffffffff8144fde5>] ? netpoll_poll_dev+0x45/0x490
      [100718.051100]  [<ffffffff81161b19>] ? ksize+0x19/0x80
      [100718.051102]  [<ffffffff81450437>] ? netpoll_send_skb_on_dev+0x157/0x240
      
      by reenabling IRQ before calling ->poll, but it seems more
      problems are introduced after that patch:
      
      http://ozlabs.org/~akpm/stuff/IMG_20120824_122054.jpg
      http://marc.info/?l=linux-netdev&m=134563282530588&w=2
      
      
      
      So it is safe to fix be2net driver code directly.
      
      This patch reverts the offending commit and fixes be_poll() by
      avoid disabling BH there, this is okay because be_poll()
      can be called either by poll_napi() which already disables
      IRQ, or by net_rx_action() which already disables BH.
      Reported-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Reported-by: default avatarSylvain Munaut <s.munaut@whatever-company.com>
      Cc: Sylvain Munaut <s.munaut@whatever-company.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: David Miller <davem@davemloft.net>
      Cc: Sathya Perla <sathya.perla@emulex.com>
      Cc: Subbu Seetharaman <subbu.seetharaman@emulex.com>
      Cc: Ajit Khaparde <ajit.khaparde@emulex.com>
      Signed-off-by: default avatarCong Wang <amwang@redhat.com>
      Tested-by: default avatarSylvain Munaut <s.munaut@whatever-company.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      072a9c48
  20. 14 Aug, 2012 6 commits
  21. 17 Jul, 2012 1 commit
  22. 13 Jun, 2012 1 commit
  23. 14 Feb, 2012 1 commit
  24. 01 Feb, 2012 2 commits
  25. 12 Jan, 2012 1 commit
  26. 29 Nov, 2011 1 commit
  27. 18 Nov, 2011 1 commit
    • Herbert Xu's avatar
      net: Remove all uses of LL_ALLOCATED_SPACE · ae641949
      Herbert Xu authored
      
      
      net: Remove all uses of LL_ALLOCATED_SPACE
      
      The macro LL_ALLOCATED_SPACE was ill-conceived.  It applies the
      alignment to the sum of needed_headroom and needed_tailroom.  As
      the amount that is then reserved for head room is needed_headroom
      with alignment, this means that the tail room left may be too small.
      
      This patch replaces all uses of LL_ALLOCATED_SPACE with the macro
      LL_RESERVED_SPACE and direct reference to needed_tailroom.
      
      This also fixes the problem with needed_headroom changing between
      allocating the skb and reserving the head room.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ae641949
  28. 31 Oct, 2011 1 commit
  29. 26 Aug, 2011 1 commit
  30. 02 Aug, 2011 1 commit