1. 06 11月, 2009 1 次提交
  2. 29 10月, 2009 1 次提交
  3. 13 10月, 2009 1 次提交
    • N
      net: Generalize socket rx gap / receive queue overflow cmsg · 3b885787
      Neil Horman 提交于
      Create a new socket level option to report number of queue overflows
      
      Recently I augmented the AF_PACKET protocol to report the number of frames lost
      on the socket receive queue between any two enqueued frames.  This value was
      exported via a SOL_PACKET level cmsg.  AFter I completed that work it was
      requested that this feature be generalized so that any datagram oriented socket
      could make use of this option.  As such I've created this patch, It creates a
      new SOL_SOCKET level option called SO_RXQ_OVFL, which when enabled exports a
      SOL_SOCKET level cmsg that reports the nubmer of times the sk_receive_queue
      overflowed between any two given frames.  It also augments the AF_PACKET
      protocol to take advantage of this new feature (as it previously did not touch
      sk->sk_drops, which this patch uses to record the overflow count).  Tested
      successfully by me.
      
      Notes:
      
      1) Unlike my previous patch, this patch simply records the sk_drops value, which
      is not a number of drops between packets, but rather a total number of drops.
      Deltas must be computed in user space.
      
      2) While this patch currently works with datagram oriented protocols, it will
      also be accepted by non-datagram oriented protocols. I'm not sure if thats
      agreeable to everyone, but my argument in favor of doing so is that, for those
      protocols which aren't applicable to this option, sk_drops will always be zero,
      and reporting no drops on a receive queue that isn't used for those
      non-participating protocols seems reasonable to me.  This also saves us having
      to code in a per-protocol opt in mechanism.
      
      3) This applies cleanly to net-next assuming that commit
      97775007 (my af packet cmsg patch) is reverted
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3b885787
  4. 07 10月, 2009 1 次提交
  5. 01 10月, 2009 1 次提交
  6. 15 9月, 2009 1 次提交
  7. 31 8月, 2009 1 次提交
  8. 29 8月, 2009 1 次提交
  9. 15 8月, 2009 1 次提交
  10. 10 8月, 2009 1 次提交
  11. 16 7月, 2009 2 次提交
  12. 10 6月, 2009 1 次提交
  13. 17 4月, 2009 1 次提交
  14. 31 3月, 2009 1 次提交
    • A
      proc 2/2: remove struct proc_dir_entry::owner · 99b76233
      Alexey Dobriyan 提交于
      Setting ->owner as done currently (pde->owner = THIS_MODULE) is racy
      as correctly noted at bug #12454. Someone can lookup entry with NULL
      ->owner, thus not pinning enything, and release it later resulting
      in module refcount underflow.
      
      We can keep ->owner and supply it at registration time like ->proc_fops
      and ->data.
      
      But this leaves ->owner as easy-manipulative field (just one C assignment)
      and somebody will forget to unpin previous/pin current module when
      switching ->owner. ->proc_fops is declared as "const" which should give
      some thoughts.
      
      ->read_proc/->write_proc were just fixed to not require ->owner for
      protection.
      
      rmmod'ed directories will be empty and return "." and ".." -- no harm.
      And directories with tricky enough readdir and lookup shouldn't be modular.
      We definitely don't want such modular code.
      
      Removing ->owner will also make PDE smaller.
      
      So, let's nuke it.
      
      Kudos to Jeff Layton for reminding about this, let's say, oversight.
      
      http://bugzilla.kernel.org/show_bug.cgi?id=12454Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      99b76233
  15. 27 2月, 2009 1 次提交
  16. 16 2月, 2009 1 次提交
  17. 01 2月, 2009 1 次提交
  18. 15 1月, 2009 1 次提交
    • O
      can: fix slowpath issue in hrtimer callback function · c53a6ee8
      Oliver Hartkopp 提交于
      Due to the loopback functionality in can_send() we can not invoke it
      from hardirq context which was done inside the
      bcm_tx_timeout_handler() hrtimer callback:
      
      [  700.361154]  [<c012228c>] warn_slowpath+0x80/0xb6
      [  700.361163]  [<c013d559>] valid_state+0x125/0x136
      [  700.361171]  [<c013d858>] mark_lock+0x18e/0x332
      [  700.361180]  [<c013e300>] __lock_acquire+0x12e/0xb1e
      [  700.361189]  [<f8ab5915>] bcm_tx_timeout_handler+0x0/0xbc [can_bcm]
      [  700.361198]  [<c031e20a>] dev_queue_xmit+0x191/0x479
      [  700.361206]  [<c01262a7>] __local_bh_disable+0x2b/0x64
      [  700.361213]  [<c031e20a>] dev_queue_xmit+0x191/0x479
      [  700.361225]  [<f8aa69a1>] can_send+0xd7/0x11a [can]
      [  700.361235]  [<f8ab522b>] bcm_can_tx+0x9d/0xd9 [can_bcm]
      [  700.361245]  [<f8ab597f>] bcm_tx_timeout_handler+0x6a/0xbc [can_bcm]
      [  700.361255]  [<f8ab5915>] bcm_tx_timeout_handler+0x0/0xbc [can_bcm]
      [  700.361263]  [<c0134143>] __run_hrtimer+0x5a/0x86
      [  700.361273]  [<f8ab5915>] bcm_tx_timeout_handler+0x0/0xbc [can_bcm]
      [  700.361282]  [<c0134a50>] hrtimer_interrupt+0xb9/0x110
      
      This patch moves the rest of the functionality from the hrtimer
      callback to the already existing tasklet to fix this slowpath problem.
      Signed-off-by: NOliver Hartkopp <oliver@hartkopp.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c53a6ee8
  19. 07 1月, 2009 1 次提交
  20. 05 1月, 2009 1 次提交
  21. 15 12月, 2008 1 次提交
  22. 05 12月, 2008 1 次提交
  23. 04 12月, 2008 1 次提交
    • O
      can: Fix CAN_(EFF|RTR)_FLAG handling in can_filter · d253eee2
      Oliver Hartkopp 提交于
      Due to a wrong safety check in af_can.c it was not possible to filter
      for SFF frames with a specific CAN identifier without getting the
      same selected CAN identifier from a received EFF frame also.
      
      This fix has a minimum (but user visible) impact on the CAN filter
      API and therefore the CAN version is set to a new date.
      
      Indeed the 'old' API is still working as-is. But when now setting
      CAN_(EFF|RTR)_FLAG in can_filter.can_mask you might get less traffic
      than before - but still the stuff that you expected to get for your
      defined filter ...
      
      Thanks to Kurt Van Dijck for pointing at this issue and for the review.
      Signed-off-by: NOliver Hartkopp <oliver@hartkopp.net>
      Acked-by: NKurt Van Dijck <kurt.van.dijck@eia.be>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d253eee2
  24. 17 10月, 2008 1 次提交
  25. 20 7月, 2008 1 次提交
  26. 06 7月, 2008 1 次提交
  27. 08 5月, 2008 1 次提交
  28. 04 5月, 2008 1 次提交
  29. 28 4月, 2008 1 次提交
  30. 25 4月, 2008 1 次提交
  31. 16 4月, 2008 1 次提交
  32. 26 3月, 2008 1 次提交
  33. 08 2月, 2008 3 次提交
  34. 29 1月, 2008 4 次提交