1. 17 Apr, 2013 11 commits
  2. 16 Apr, 2013 17 commits
  3. 15 Apr, 2013 10 commits
    • Pravin B Shelar's avatar
      openvswitch: Use generic struct pcpu_tstats. · e0f0ecf3
      Pravin B Shelar authored
      Rather than defining ovs specific stats struct (vport_percpu_stats),
      we can use existing pcpu_tstats to achieve exactly same functionality.
      Signed-off-by: default avatarPravin B Shelar <pshelar@nicira.com>
      Signed-off-by: default avatarJesse Gross <jesse@nicira.com>
      e0f0ecf3
    • Pravin B Shelar's avatar
      openvswitch: Simplify datapath locking. · 8e4e1713
      Pravin B Shelar authored
      Currently OVS uses combination of genl and rtnl lock to protect
      datapath state.  This was done due to networking stack locking.
      But this has complicated locking and there are few lock ordering
      issues with new tunneling protocols.
      Following patch simplifies locking by introducing new ovs mutex
      and now this lock is used to protect entire ovs state.
      Signed-off-by: default avatarPravin B Shelar <pshelar@nicira.com>
      Signed-off-by: default avatarJesse Gross <jesse@nicira.com>
      8e4e1713
    • David S. Miller's avatar
      Merge branch 'sync_multiple' · 61f47132
      David S. Miller authored
      Vlad Yasevich says:
      
      ====================
      Current dev_[uc|mc]_addr_sync() API currently correctly syncs the
      addresses to the first device.  Any subsequent calls to sync will
      not do anything since the synched variable will be set.  This
      variable is used as an optimization to skip over addresses that have
      been synched.
      
      There are some devices (ex: team) that attempt to do the above.  There
      is other work in progress that needs to above to work corretly.
      
      The short series introduces dev_[uc|mc]_addr_synch_multiple() that
      allows multiple calls to sync to multiple different devices.  Original
      API is left alone and still has the limitation.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      61f47132
    • Vlad Yasevich's avatar
      team: Use new sync_multiple api to sync devices adressess. · 72b27032
      Vlad Yasevich authored
      Team drivers attempts to sync addresses to each of the port
      devices; however, the current api doesn't really perform the sync
      for any device after the first one.  Switch to using the new api
      that will actually sync the addresses to all ports.
      
      CC: Jiri Pirko <jiri@resnulli.us>
      Signed-off-by: default avatarVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      72b27032
    • Vlad Yasevich's avatar
      net: add dev_uc_sync_multiple() and dev_mc_sync_multiple() api · 4cd729b0
      Vlad Yasevich authored
      The current implementation of dev_uc_sync/unsync() assumes that there is
      a strict 1-to-1 relationship between the source and destination of the sync.
      In other words, once an address has been synced to a destination device, it
      will not be synced to any other device through the sync API.
      However, there are some virtual devices that aggreate a number of lower
      devices and need to sync addresses to all of them.  The current
      API falls short there.
      
      This patch introduces a new dev_uc_sync_multiple() api that can be called
      in the above circumstances and allows sync to work for every invocation.
      
      CC: Jiri Pirko <jiri@resnulli.us>
      Signed-off-by: default avatarVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4cd729b0
    • Daniel Borkmann's avatar
      net: sctp: minor: make sctp_ep_common's member 'dead' a bool · 0022d2dd
      Daniel Borkmann authored
      Since dead only holds two states (0,1), make it a bool instead
      of a 'char', which is more appropriate for its purpose.
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Acked-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0022d2dd
    • Daniel Borkmann's avatar
      net: sctp: remove sctp_ep_common struct member 'malloced' · ff2266cd
      Daniel Borkmann authored
      There is actually no need to keep this member in the structure, because
      after init it's always 1 anyway, thus always kfree called. This seems to
      be an ancient leftover from the very initial implementation from 2.5
      times. Only in case the initialization of an association fails, we leave
      base.malloced as 0, but we nevertheless kfree it in the error path in
      sctp_association_new().
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Acked-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ff2266cd
    • Denis Kirjanov's avatar
      sis900: check for DMA map errors · 1e8edc2a
      Denis Kirjanov authored
      The first backtrace appears on tx path with DMA mapping operations debug
      enabled.
      
      [  345.637919] ------------[ cut here ]------------
      [  345.637971] WARNING: at lib/dma-debug.c:937 check_unmap+0x4df/0x910()
      [  345.637977] Hardware name: System Name
      [  345.637987] sis900 0000:00:01.1: DMA-API: device driver failed to check map error[device address=0x000000000d4aed02] [si
      ze=60 bytes] [mapped as single]
      [  345.637993] Modules linked in: bridge stp llc dmfe sundance 3c59x sis900
      [  345.638022] Pid: 0, comm: swapper Not tainted 3.9.0-rc6+ #4
      [  345.638028] Call Trace:
      [  345.638042]  [<c122097f>] ? check_unmap+0x4df/0x910
      [  345.638059]  [<c102b19c>] warn_slowpath_common+0x7c/0xa0
      [  345.638070]  [<c122097f>] ? check_unmap+0x4df/0x910
      [  345.638081]  [<c102b23e>] warn_slowpath_fmt+0x2e/0x30
      [  345.638092]  [<c122097f>] check_unmap+0x4df/0x910
      [  345.638107]  [<c100bfeb>] ? save_stack_trace+0x2b/0x50
      [  345.638120]  [<c107238e>] ? mark_lock+0x31e/0x5d0
      [  345.638132]  [<c1072b2c>] ? __lock_acquire+0x4ec/0x7d0
      [  345.638143]  [<c1220f6d>] debug_dma_unmap_page+0x6d/0x80
      [  345.638166]  [<cf834dec>] sis900_interrupt+0x49c/0x860 [sis900]
      [  345.638195]  [<c1094b73>] handle_irq_event_percpu+0x43/0x1c0
      [  345.638206]  [<c1094d1e>] ? handle_irq_event+0x2e/0x60
      [  345.638217]  [<c1094d27>] handle_irq_event+0x37/0x60
      [  345.638235]  [<c10973f0>] ? irq_set_chip_data+0x40/0x40
      [  345.638246]  [<c1097442>] handle_level_irq+0x52/0xa0
      [  345.638251]  <IRQ>  [<c1003629>] ? do_IRQ+0x39/0xa0
      [  345.638293]  [<c1484631>] ? common_interrupt+0x31/0x36
      [  345.638347]  [<d08c2c52>] ? br_flood_forward+0x12/0x20 [bridge]
      [  345.638364]  [<d08c2d40>] ? br_dev_queue_push_xmit+0x60/0x60 [bridge]
      [  345.638381]  [<d08c3b2b>] ? br_handle_frame_finish+0x25b/0x280 [bridge]
      [  345.638399]  [<d08c3ce3>] ? br_handle_frame+0x193/0x290 [bridge]
      [  345.638416]  [<d08c3b50>] ? br_handle_frame_finish+0x280/0x280 [bridge]
      [  345.638431]  [<c13b3c87>] ? __netif_receive_skb_core+0x1d7/0x710
      [  345.638442]  [<c13b3b19>] ? __netif_receive_skb_core+0x69/0x710
      [  345.638454]  [<c13b41e1>] ? __netif_receive_skb+0x21/0x70
      [  345.638464]  [<c13b42b5>] ? process_backlog+0x85/0x130
      [  345.638476]  [<c13b4bbb>] ? net_rx_action+0xfb/0x1d0
      [  345.638497]  [<c1032768>] ? __do_softirq+0xa8/0x1f0
      [  345.638527]  [<c147daad>] ? _raw_spin_unlock+0x1d/0x20
      [  345.638538]  [<c10038c0>] ? handle_irq+0x20/0xd0
      [  345.638550]  [<c1032f27>] ? irq_exit+0x97/0xa0
      [  345.638560]  [<c1003632>] ? do_IRQ+0x42/0xa0
      [  345.638580]  [<c104d003>] ? hrtimer_start+0x23/0x30
      [  345.638580]  [<c1484631>] ? common_interrupt+0x31/0x36
      [  345.638580]  [<c1008703>] ? default_idle+0x33/0xc0
      [  345.638580]  [<c10086ac>] ? cpu_idle+0x4c/0x70
      [  345.638580]  [<c14787e0>] ? rest_init+0xa0/0xb0
      [  345.638580]  [<c1478740>] ? reciprocal_value+0x50/0x50
      [  345.638580]  [<c16b5bcf>] ? start_kernel+0x28f/0x320
      [  345.638580]  [<c16b54e0>] ? repair_env_string+0x60/0x60
      [  345.638580]  [<c16b5269>] ? i386_start_kernel+0x39/0xa0
      [  345.638580] ---[ end trace a244264b69b8a7ae ]---
      [  345.638580] Mapped at:
      [  345.638580]  [<c1221c65>] debug_dma_map_page+0x65/0x110
      [  345.638580]  [<cf8355a9>] sis900_start_xmit+0x129/0x210 [sis900]
      [  345.638580]  [<c13b2527>] dev_hard_start_xmit+0x1b7/0x530
      [  345.638580]  [<c13cc32e>] sch_direct_xmit+0x8e/0x280
      [  345.638580]  [<c13b4e39>] dev_queue_xmit+0x1a9/0x5b0
      Signed-off-by: default avatarDenis Kirjanov <kda@linux-powerpc.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1e8edc2a
    • Nicolas Ferre's avatar
      net/macb: fix error return code in macb_probe() · 72ca820b
      Nicolas Ferre authored
      Fix to return a negative error code from the error handling
      case instead of 0, as returned elsewhere in this function.
      
      Original-idea-by: <yongjun_wei@trendmicro.com.cn>
      Signed-off-by: default avatarNicolas Ferre <nicolas.ferre@atmel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      72ca820b
    • Mike Rapoport's avatar
      vxlan: don't bypass encapsulation for multi- and broadcasts · ab09a6d0
      Mike Rapoport authored
      The multicast and broadcast packets may have RTCF_LOCAL set in rt_flags
      and therefore will be sent out bypassing encapsulation. This breaks
      delivery of packets sent to the vxlan multicast group.
      Disabling encapsulation bypass for multicasts and broadcasts fixes the
      issue.
      Signed-off-by: default avatarMike Rapoport <mike.rapoport@ravellosystems.com>
      Tested-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Acked-by: default avatarSridhar Samudrala <sri@us.ibm.com>
      Tested-by: default avatarSridhar Samudrala <sri@us.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ab09a6d0
  4. 14 Apr, 2013 2 commits